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