[00:15] Hey, anyone knows, what's up with bzr-2.5.0-2-setup.exe ? I can't find it on launchpad, the link on the bzr download page is leading to a non-existant file. [00:20] my bad, changed -2- to -1- [00:20] -d [00:21] I fixed the page now, as some kind soul sent an email about it. [00:27] okay, bed for me. [00:31] hehe ^^ good night [00:31] thx for fixing [04:38] Hey btw the link to the homepage from this IRC is broken. It guides you to: http://bazaar.canonical.com> [04:40] > is recognized as part of the hyperlink [04:51] nah [08:55] hi vila [08:55] wow i should go [08:56] hey poolie, yeah you should ;) [08:56] I think I've found the issue with the docs: lp:bzr-alldocs [08:57] that's where the templates are defined, the cron job should run in a couple of minutes, we'll see if I got it right [09:06] ha crap, I can never read cron entries correctly (mins then hours, not the opposite of course) [09:12] morning all [09:12] _o/ [14:04] yak yak yak :-/ [14:10] vila is having fun with the razor? [14:10] kind of ;) [14:10] trying to reproduce a nth issue with generating the docs I'm back to bug #940164 [14:10] Launchpad bug 940164 in Bazaar "texinfo is supported by sphinx under precise leading to test failures" [High,Confirmed] https://launchpad.net/bugs/940164 [14:11] ah :-/ [14:11] which means it's more problematic than I hoped [14:17] whoever was RM for 2.4 and didn't document the *full* list of naughty details to get the doc right will... err, never mind [14:25] jelmer: by the way, did you notice the bug about ssl cert checking the wrong site for the proxy ? [14:30] vila: yeah, I did see that :-/ [14:30] I'm reasonably sure it's xmlrpc specific [14:33] the launchpad plugin has its own transport stuff that probably just needs fixing [14:33] not sure about that, I suspect a mismatch in the urllib implementation, I bet because the connection to the proxy is seen as https when it's http [14:34] and I did make no typo there \o/ [14:35] as usual, I'd be happy to be proved wrong ;) [14:35] there was no error when doing an operation through the proxy just on any old https url [14:35] only for the lp: resolving step [14:45] hm, need a proxy that supports CONNECT and passthrough to test it, annoyingly twisted [14:45] does not [14:46] http://twistedmatrix.com/trac/ticket/237 [14:49] I guess writing that wouldn't be hard, but then I'd not sure if the bugs were in that or bzr [15:36] \o/ look 'ma, http://doc.bazaar.canonical.com/bzr.dev/en/ says what's new in 2.6 \o/ [15:37] and http://doc.bazaar.canonical.com/en/ is not broken anymore [15:37] and we can generate .info files too [15:40] good job vila [15:40] just posted some extra info in the https bug [15:40] good job mgz ;) [15:40] bug # again ? [15:40] bug 944696 [15:40] Launchpad bug 944696 in Bazaar "Certificate error on launchpad xmlrpc server with HTTPS_PROXY set" [Critical,Confirmed] https://launchpad.net/bugs/944696 [15:42] right, reinforce my suspicion that we verify the wrong host, could as simple to fix as s/host/orig_host/ somewhere [15:43] unless the check is not in the right place which will require more harm twisting [15:44] err, arm twisting ? [15:44] whatever, more work :) [16:05] yeah, there's a proxied_host attribute one stack level up that probably does the right thing [16:06] right, this one (not orig_host) [16:06] apart from writing a test case ;_; that's probably all that's needed [16:06] funny how I remembered a name I replaced... [16:07] yeah, I never found the steam to write a proxy test server === zyga is now known as zyga-afk [16:54] what type of an object is a push_result/ === deryck is now known as deryck[lunch] [17:00] mgz: https://code.launchpad.net/~vila/bzr/940164-native-texinfo/+merge/96796 while you're still PP :-D [17:03] heh [17:04] lamalex: it's documented in bzrlib/push.py but roughly you can think about it at collecting various infos about the push operation [17:04] Can you believe my keyboard batteries died exactly when I was typing 'Enter' after the msg above... [17:06] haha [17:06] ccing doxxx on that review just so he can glance at it, given he had to dive into tex stuff a little when doing the 2.5.0 mac installers [17:09] mgz: texinfo can *generate* both tex and info but for us it doesn't matter as we generate latex with sphinx with a different builder [17:09] mgz: but I should have a look at how Gordon avoid the issue (thanks for the reminder) [17:09] he renamed our texinfo builder for sphinx to something else, [17:10] so it didn't class with their new one :) [17:11] right, so he will encounter a trivial to resolve conflict :) [17:11] hmm, trivial with 'bzr resolve --take-other' probably ;) [17:12] yup, one-line patch to be deleted, thanks for ccing him if only for the heads-up [17:13] so, apart from that conf.py stuff being a duplicative mess, which isn't the fault of this branch, the change looks good [17:14] what about parsing the push location, i guess branches like ~user/project/branch are specific to launchpad? maybe launchpadlib would have parsing bits for that [17:15] lamalex: it does [17:15] mgz, hint as to where? [17:16] mgz: yeah, and don't mention that the Makefiles in the doc/xx dirs are copied from doc/en ... === zyga-afk is now known as zyga [17:17] lamalex: see bzrlib/plugins/launchpad/lp_directory.py [17:17] I was shocked when trying to propagate my change in doc/ru to find it there already :) [17:18] it has a few local bits, and talks to an xmlrpc server if it needs to [17:18] mgz: the whole sphinx setup is a mess being the result of stuff generated by sphinx itself + duplicated afterwards... [17:18] mgz, can i import this into another plugin? [17:18] import bzr.plugins.launchpad? [17:18] +lib but yes... you probably just want to resolve lp: automatically though? [17:19] lamalex: *parsing* the push location ? What are you after ? [17:20] which happens in _register_directory on import [17:20] vila, getting the project name out of the push [17:20] risky [17:20] when when pushed to lp:~alexlauni/unity/mydumbfeature getting unity [17:20] push_location can be lp:bzr [17:20] i realize i could just string parse [17:21] but yah, there's also lp:bzr but bzr is a project- so i was hoping that lp lib had this already figured out and i could just piggy back [17:21] stepping back further, why do you need the project name ? [17:23] lamalex: 'cause there is also ubuntu:bzr and ubuntu:~vila/ubuntu/precise/bzr/my-feature or something (can't never remember the order) [17:23] err, lp:~vila/ubuntu/precise/bzr/my-feature [17:23] well those are sort of outside our specific use [17:23] k [17:23] vila, we want a push hook that creates a jenkins job for continuous integration on our projects [17:24] when a dev pushes his/her branch to LP we want a jenkins job created to start running the test suite during the development life of the branch [17:24] then our merge bot will have a hook to delete the job when the branch gets merged [17:24] nice [17:24] yah [17:24] very slick ;) [17:25] so we want the project name for naming the job [17:25] i guess i can just use the branch name though [17:25] it's not that important and just sounds a lot simpler [17:25] will avoid conflicts [17:25] ill just do that [17:26] * vila nods [17:28] lamalex: I'd be very interested in a such a plugin myself ;) [17:29] vila, are you a canonical employee by chance? [17:30] exactly, by chance 8-) [17:50] * jelmer waves [17:51] vila: should we get rid of the curl backend in 2.6 or 2.7 ? [17:56] well, for peace of mind, I would target a removal at the *end* of 2.6 to make sure we "got them all" (those pesky little forgotten details turning into bugs ;) [17:56] hmm [17:56] end of 2.6 == release 2.6.0 [17:57] a test failing at this point should be easy to write no ? [17:57] what sort of failing test? [17:58] until then, "install pycurl" is an easy workaround to davise [17:58] advise [17:58] one asserting that we had removed the pycurl backend [17:59] now that urllib is the default backend nobody should be using it right ? [18:00] jelmer: did you work out what the bzr-builddeb issue on precise was? I didn't get the same issue here, and the ppa dailies also seem to be different issues [18:00] speaking of ppas, any news from maxb lately ? [18:00] (and today I don't know where to find the error) [18:00] vila: hm, nope, and various of our advertised ones are pretty out of date [18:02] yup, maybe he'll be willing to pass the torch... I know he had some handy scripts which would be good to use [18:07] * maxb is around.... ish [18:07] maxb: \o/ [18:08] maxb: can we help each other to bring our ppas up to date in a "let's do it one step at a time" mode ? [18:09] mgz: yeah, that's on my todo list [18:09] can you paste/forward/something me the build output? [18:10] mgz: was directed at me? [18:12] jelmer: yes, telling me where to look would also work if it's recorded somewhere [18:12] mgz: the build failure is on the launchpad package page for bzr-builddeb [18:13] maxb: starting by finding a time when we can talk briefly :-D [18:14] jelmer: thanks, so it is... looked at that page and didn't manage to navigate to the right place === deryck[lunch] is now known as deryck [18:22] I heard about a plugin to handle ChangeLog merge conflicts. Any idea what is it called? [18:23] hi leo2007 [18:23] hi [18:23] see 'bzr help changelog_merge' [18:26] where is location.conf? [18:27] leo2007: ~/.bazaar [18:27] locations.conf [18:28] bzr help changelog_merge says location.conf [18:28] typo? [18:28] it says locations.conf here - perhaps that was fixed recently [18:29] ok, I am running 2.4.2 [18:58] bajoing [19:13] hiii === cody-somerville_ is now known as cody-somerville === zyga is now known as zyga-weekend [21:25] hi, why would get_push_location be returning none when i'm pushing somewhere?? [21:25] and there's a push location in bzr info [21:29] not sure :< [21:29] ha [21:29] nice [21:29] it /should/ be working though? [21:30] push_result.target_branch.get_push_location() should be giving push_location [21:30] right/ [21:30] im not too familiar with the source code (yet), but itprobably should [21:31] does it only return it if its remembered? [21:31] I can only get it to return None [21:33] see what it does if you do bzr push --remember [21:33] same [21:33] None [21:34] lamalex, you are looking for the place that the target branch would push to by default? [21:35] james_w, I'm writing a post-push hook and im looking for the place it was pushed to [21:36] ah, hmm [21:37] lamalex, you want to know the URL for reporting? [21:37] no im going to parse the launchpad project out of it [21:38] which will be used to create a jenkins job [21:39] maybe one of the bzr developers can chime in if they are here [21:39] lamalex, push_result.target_branch.user_url is what you want I think [21:41] still seems like a bug that get_push_location() returns None pretty much exclusively [21:41] but yeah- that works [21:41] thanks [21:41] :) [21:42] lamalex, get_push_location() is looking at where the target branch would push to if you ran "bzr push" in it [21:42] lamalex, and if it's on Launchpad it probably doesn't have that set [21:42] that's my guess at least [21:42] james_w bzr info shows a push a brnach though [21:42] lamalex, "bzr info lp:whatever" ? [21:43] im doing bzr push lp:whatever from a working branch [21:43] right [21:43] and "bzr info" will return lp:whatver [21:44] does whatever you are calling get_push_location on the branch you have locally or the branch you pushed to? [21:44] but push_result.target_branch.get_push_location() is like running "bzr info lp:whatever" [21:44] if that returns a push branch then I'm clearly talking nonsense [21:44] AH [21:44] got it [21:44] right [21:44] tricky [21:46] so push_result is referring to the branch you just pushed to? [21:48] mgrandi, it's an object that is passed to a post_push hook, and has references to the source_branch and target_branch that were involved in the push [21:48] ah [21:48] so target_branch is launchpad or something, gotcha === yofel_ is now known as yofel