[00:41]  * maxb gets very confused that some _*_pyx.h are autogenerated and some are not
[00:50] <poolie> really?
[00:50] <poolie> i thought they all should be
[00:51] <poolie> if some are versioned that's probably a mistake
[01:08] <maxb> Turns out there are some _*_pyx.h that are human-authored
[01:11] <lifeless> we were going to commit them as well, for folk without pyrex.
[01:11] <lifeless> I don't think that that has happened.
[01:20] <poolie> i'm not convinced that is worthwhile (any more)
[01:20] <poolie> it seems mostly useful for people on unix but without an apt/port like system through which they can install it
[01:20] <poolie> which is a pretty thin slice
[01:20] <poolie> s/it/pyrex
[07:12] <vila> hi all !
[07:13] <fullermd> You're way too chipper for mornings.  You're obviously on powerful drugs.  I want to know where you got them, and how much they cost.
[07:14] <vila> first dose free, as usual, as to where I got them... I wish I knew :D  I lack them for the last two days and couldn't find any substitute...
[07:25] <spm> vila: but isn't coffee freely available over your part of the world? with croissant even? ;-)
[07:26] <vila> spm: ha right, morning expressossss are a pre-requisite (keep forgetting to mention them) but croissants... hmm, I've lost ~10kg in the last months, part of it is certainly because I *avoided* croissants ;D
[07:27] <spm> heh
[07:27] <lifeless> vila: congrats!
[07:27] <lifeless> vila: but did you have to ship it to me?!
[07:28] <vila> lifeless: thanks, very appreciated, so sorry for the side-effects :-/
[07:29] <vila> lifeless: still, my main effort was to eat fruits instead of junk between meals, surprisingly effective... Not the only effort but apparently the most important one...
[07:34] <fullermd> Wait, vila's shipping croissants around?
[07:38] <vila> bah, no, croissants are not anymore what they used to be in the goold ol' times at 5AM on Sundays...
[07:41] <poolie> hello vila!
[07:41] <vila> poolie: hey !
[07:42] <poolie> hi there
[09:02] <hrw> hi
[09:07] <hrw> hi jelmer
[09:07] <jelmer> hi hrw
[09:08] <hrw> jelmer: I think that I found a bug in bzr git-apply
[09:08] <hrw> jelmer: if patch creates new file then it is not created on bzr side after 'bzr git-apply'
[09:09] <hrw> jelmer: will retest it first
[09:12] <jelmer> hrw: No need, I can confirm it doesn't do that.
[09:12] <hrw> ok, good to know
[09:13] <hrw> jelmer: should I open lp bug for it?
[09:15]  * hrw -> finding other way to import git -> bzr
[09:17] <jelmer> hrw: Please do
[09:18] <jelmer> hrw: importing from git -> bzr should also be possible using bzr-git's pull, that's the same mechanism Launchpad uses for imports.
[09:20] <hrw> jelmer: this gave me parallel import with r2 as common one. result was really hard to merge
[09:22] <jelmer> hrw: hmm, it shouldn't do that (if you use bzr-git for other stuff too)
[09:22] <hrw> bug 680833
[09:22] <jelmer> hrw: thanks
[09:22] <hrw> np
[09:54] <jelmer> hrw: can I ask about your use case? Are you trying to contribute to a bzr-maintained project?
[09:55] <hrw> jelmer: I have 4 packages in ubuntu and they are kept in bzr repo on LP. I started developing them in local git repo and keeps it that way (rebase etc). when I think that changes are ready for review I am migrating changes to bzr and push for review.
[09:56] <jelmer> hrw: ah
[09:56] <hrw> jelmer: as git user I have problems with switching to bzr
[09:57] <zyga> lifeless, around?
[09:58] <jelmer> hrw: bzr push should give you a way to do that once it's finished (it'll store bzr metadata it can't represent in git in a git note)
[12:09] <Tarantulafudge> I forget, what should I do when I have differing revisions?
[12:10] <Tarantulafudge> merge?
[12:11] <jelmer> Tarantulafudge: if you have diverged branches, yes
[12:15] <Tarantulafudge> any tips?
[12:15] <Tarantulafudge> do I pull the tree first?
[12:22] <hmeland> You don't pull "a tree", you pull "a branch"... but to merge, first make your tree into one of the revisions you want to merge (e.g. by using pull or update), then merge the other revision, resolve any conflicts, and finally commit the merge.
[15:07] <vila> maxb: around ? I'm confused about 'python-docutils does not seem to be a particularly heavy-weight dep', I don't want to add this package to the ppa, why should I care whether it's heavy-weight or not ?
[15:07] <maxb> vila: You suggested creating an additional metapackage which was bzr-pqm-dependencies-minus-python-docutils. I didn't understand why that would be useful
[15:08] <vila> haaa
[15:09] <vila> oh, it was because I thought all the deps except python-docutils may be in the bzr Build-Deps, and I wanted to avoid duplication but I may not fully understand Build-Deps ::-/
[15:09] <maxb> I'm not sure we're both talking about the same thing when we say Build-Deps
[15:09] <vila> indeed :)
[15:09] <vila> *you* know what it means, big difference :D
[15:09] <vila> so nvm
[15:10] <vila> as long as we agree on the package name, I'm happy to put it in the ppa as a first step
[15:10] <maxb> I mean the Build-Depends: field found in Debian source packages
[15:11] <vila> right
[15:11] <vila> and I thought those deps should be fulfilled for a package to be built, which we need (I think) before running make check
[15:12] <vila> since we build the extensions as part of 'make check'
[15:12] <vila> pff, I'm not even sure pycurl should be there... yet we want it for selftest (so far)
[15:13] <vila> ok, still a grey area indeed
[15:13] <vila> so let's keep them separate to start with
[15:13] <vila> maxb: thanks for your feedback
[15:13] <vila> maxb: (and the teddybear'ing ;)
[15:59] <chx> hi. if i have something like 17233.1.24 in bzr blame, how can i find the revision it was merged in...? it does not look it's 17233
[16:12] <vila> chx: no, 17233 is the revision it was forked from, you want -rmainline:17233.1.24
[16:13] <vila> chx: 'bzr qblame' may be easier in this case though
[16:14] <chx> bzr: ERROR: Unsupported protocol for url "mainline:17233.1.24"
[16:14] <chx> i tried bzr log -r mainline:17233.1.24  with and without the space after -r
[16:15] <chx>  bzr help revisionspec does not list mainline either
[16:15] <vila> chx: damn, too recent addition :(
[16:16] <chx> I have bzr 2.2.1
[16:16] <vila> chx: it's in trunk, you're using ... right
[16:16] <chx> even that's not recent enough????
[16:16] <vila> chx: try 'bzr qblame' from the qbzr plugin then
[16:17] <vila> chx: what can I answer ? No, if it's not in 2.2.1 but in trunk, 2.2.1 is not recent enough :) Sorry :-/
[16:17] <chx> bah, i just ran bzr log -n0 and searched it out
[16:18] <chx> my sysadmin will kill me if i ask qt to be deployed
[16:18] <vila> ha
[16:18] <chx> that's a bit too much.
[16:18] <vila> hmm, there is a bzr log incantation that will be faster than log -n0 but it escapes me at the moment
[16:39] <mgz> hey vila.
[16:39] <vila> mgz: hey !
[16:40] <vila> mgz: is there something you need before landing the python-testtools-0.9.5 related mps ?
[16:40] <mgz> just approval I think.
[16:42] <vila> mgz: done !
[16:42] <mgz> debian can catch up on test tools before the next beta is released if I understand maxb correctly.
[16:44] <mgz> thanks vila, will land now then.
[16:44] <vila> mgz: they will have an additional incentive otherwise :D
[16:44] <vila> mgz: that's too bad I misunderstood you there, I was convinced they were only waiting for the pqm update :-/
[16:45] <mgz> that was the blocker.
[16:46] <mgz> as I'm inconvieniencing other people, wanted to double check before hitting the go button though.
[16:47] <vila> maxb: bzr-landing-dependencies is now in the bzr/proposed ppa, when copying to bzr/ppa, should I use 'Rebuild the copied sources' or 'Copy existing binaries' ?
[16:47] <vila> maxb: (I would do the former but I don't want to change the existing practices either)
[16:48] <vila> mgz: shouldn't that *unblock* some failing babune tests instead ?
[16:48] <mgz> yeah, it will mean I can finish and land my fix for the exception encoding issue
[16:49] <mgz> then I think we're down to three failing tests on windows, and a few on mac
[16:50] <vila> ha right, I should have a look at those highly suspicious  lp_api failures...
[16:56] <mgz> hm, great review by poolie on zearin's capitalisation branch
[17:00] <jelmer> 'evening Martin, Vincent
[17:00] <vila> jelmer: hello
[17:14] <maxb> mgz: lifeless has indicated he will take care of getting a new testtools into Debian in time
[17:15] <maxb> vila: If you wanted to do it in the web ui, it's "Copy existing binaries", however, if you have hydrazine to hand, I'd just run 'lp-promote-ppa -s bzr-landing-dependencies bzr/proposed bzr/ppa'
[17:16] <vila> maxb: cool, thanks !
[17:16] <vila> maxb: and done
[17:24] <jam> have a good week, vila, I'm off for Thanksgiving. I might poke my head in, but probably not when you're around
[17:24] <vila> jam: happy Thanksgiving !
[18:30] <mgz> hm I thought bug 681005 was a dupe of a fixed bug, but then noticed it's reported on 1.0.4 so perhaps bzr-svn still has something that needs fixing Jelmer?
[18:42] <jelmer> mgz: hmm
[18:42] <jelmer> mgz: I'll have a look, thanks
[20:20] <poolie> mgz, thanks for saying os
[20:20] <poolie> *so
[21:54] <peitschie> mornin all :)
[22:08] <poolie> hi spiv, jam
[22:15] <peitschie> hi poolie
[22:15] <spiv> Hi poolie.
[22:15] <spiv> Looks like jam is off for Thanksgiving.
[22:21] <poolie> oh of course he is
[22:23] <zyga> boo
[22:23] <zyga> bzr rebase just ate my commits
[22:23] <zyga> there was a conflict which I resolved
[22:24] <zyga> but afterwards the whole next revision (after bzr rebase-continue
[22:24] <zyga> ) just disappeared
[22:24] <zyga> is there any way to find it in the repositiory?
[22:24] <zyga> the previous head
[22:25] <zyga> jelmer, ^^
[22:39] <spiv> "bzr heads", from the bzrtools plugin
[23:06] <zyga> spiv, spits out just the rebased head
[23:06] <zyga> spiv, I remade the changes (differently though, too much effort last time, too late)
[23:13] <spiv> heads --all, perhaps.
[23:13] <zyga> spiv, that's it
[23:15] <poolie> spiv, so you're piloting this week?
[23:15] <poolie> try to do a better job than i did :)
[23:16] <zyga> spiv, you saved an hour of hacking, thanks :)
[23:17] <spiv> poolie: :)
[23:35] <poolie> spiv does bug 636930 require upgrading the client, or also the server?
[23:36] <spiv> poolie: whichever side is actually performing the conversion; in the case of fetching from a smart server, that's the server side.
[23:38] <spiv> poolie: so there's a couple of things in that bug:
[23:38] <spiv> poolie: the original reported traceback is client side
[23:38] <spiv> poolie: but Launchpad performs upgrades on behalf of users when they click the link on Launchpad, so that's Launchpad-side
[23:39] <spiv> And cross-format fetches that aren't upgrades are also affected.
[23:40] <spiv> So to cover all cases server and client need to be upgraded.
[23:41] <poolie> k
[23:41] <poolie> i'll just paste that if you don't mind
[23:44] <spiv> Sure!