[00:08] <GungaDin> hi
[00:09] <GungaDin> if a parent branch has been moved, does anything have to be configured or rebound in the child branch?
[00:12] <jelmer> GungaDin: yes, you can use "bzr bind" to do so
[00:25] <poolie> spiv, hi
[00:26] <poolie> what's next with bmp expanders?
[00:26] <poolie> i think the prerequisite has now merged
[00:27] <quotemstr> Where can I find the "bzr branches" command? It's not present in my bzr 2.3.1
[00:27] <quotemstr> Was it introduced in 2.4?
[00:27] <bob2> bzrtools
[00:31] <quotemstr> Thanks.
[00:49] <spiv> poolie: the next step is me finishing it I think!
[00:49] <spiv> poolie: danilo did a really good review
[00:56] <poolie> great
[04:51] <fullermd> Why does `bzr check --repo .` wander off down into branches in the dir instead of just checking the repo?
[04:54] <poolie> i don't know fullermd, that sounds like a bug
[04:54] <mwhudson> which reminds me, meld trunk no longer tries to run bzr check on your branch before opening it...
[04:55] <fullermd> It's already kinda irritating how the obstinate the searching is on check anyway, when it finds the branch's repo, then walks all the branches inside it in what seems like the slowest possible fashion...
[04:55] <fullermd> But it's double terrible this time, since there's an [unversioned and ignored] symlink in one of the branches, which leads to a dir, under which is a self-referential symlink...  which means the check blows up and never checks anything.
[04:58] <poolie> :/
[04:58] <poolie> so spiv, do you need a hand landing that branch?
[04:59] <poolie> should i just send it or do you need any further tweaks?
[04:59] <poolie> i refer to the bmp expander branch
[05:00] <spiv> poolie: I'm working on the review points atm
[05:01] <poolie> oh thanks
[05:01] <poolie> i can feed it up when you're done
[06:48] <vila> hi all !
[06:50] <poolie> hi there vila
[06:50] <vila> _o/
[07:04] <jam> morning all
[07:04] <vila> jam: \o_
[07:04] <vila> jam: did it ring ? ;)
[07:04] <jam> yep
[07:04] <vila> \o/
[07:07] <poolie> hi there jam
[07:07] <poolie> so much semaphore today
[07:09] <jam> -o \o  |o  \o  o/  o
[07:09] <jam> /  /     \ /  /   / |
[07:09] <jam> yeah, flag semaphore doesn't work very well on IRC
[07:09] <jam> (that was hi vila, according to http://en.wikipedia.org/wiki/Flag_semaphore)
[07:09] <jam> but you need a fixed-width font
[07:10] <vila> lol
[07:11] <jam> poolie: It turns out I can't be invited to google+ on my standard email, because it is a google-app-for-custom-domain, and it isn't supported. :(
[07:11] <poolie> huh
[07:11] <poolie> well, if you have an alternative address i could invite you there
[07:21]  * fullermd . o O ( using semaphore in IRC is kinda a red flag... )
=== jam1 is now known as jam
[08:24] <maxb> OK, I'm confused..... why would a launchpadlib api call be happening during 'bzr ci' ?
[08:24] <maxb> (I can see an HTTP error in my ~/.bzr.log)
[08:25] <jam> morning Riddell, we're on mumble
[08:25] <jelmer> maxb: maybe a hook?
[08:27] <jam> maxb: do you happen to have bzr.dev 6033 ?
[08:28] <jam> I just added a hook when looking at lp:ubuntu/* branches
[08:28] <jam> to see if they are up to date
[08:28] <jam> (bug #609187)
[08:28] <ubot5> Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] https://launchpad.net/bugs/609187
[08:28] <jam> but it shouldn't trigger for things that don't look like "ubuntu" or "debian" branches hosted on Launchpad.
[08:31] <maxb> jam: hmmm...
[08:31] <maxb> yes, I do
[08:32] <jam> maxb: I'm working with the lp guys to figure out why the query dropped from 150ms last week to 900ms this week. Seems to be an SSL handshake issue.
[08:34] <maxb> jam: I've just noticed you've got an assumption about the ubuntu-branches team in that code - that's not valid, not all package branches are ~ubuntu-branche
[08:34] <maxb> s
[08:39] <maxb> Hmm, nope, that mysterious http exception can't be from the new stuff, because that uses urllib2, and the exception was a httplib2 one
[08:39]  * maxb shrugs and heads afk
[08:45] <jam> maxb: you could pastebin the traceback if you have one
[08:51] <poolie> jelmer: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[09:27] <Riddell> vila: ready when you are
[09:28] <vila> Riddell: ok
[09:39] <vila> poolie: just checked pending reviews for udd, bzr-builddeb and bzr-builder, all empty, did you have another one in mind ?
[09:40] <poolie> nup, if that's all clear that's fine
[09:40] <poolie> i reviewed some from max and saw some others, but i didn't check the page during the call
[09:40] <poolie> could someone help https://answers.launchpad.net/launchpad/+question/165193 ?
[09:47] <Riddell> poolie: looking
[09:50] <poolie> thanks
[09:51] <poolie> Riddell: the user experiencing it is in #launchpad
[09:58] <jelmer> Riddell: I think I know what the problem is, please let me know if I should follow up
[09:58] <poolie> ok, good night
[09:58] <jelmer> have a nice evening poolie
[09:58] <poolie> thanks
[09:58] <poolie> i think the udd identity switch is now complete\
[09:59] <poolie> we'll see
[09:59] <Riddell> jelmer: go ahead if you want, I'm doing patch pilot now with vila
[09:59] <jelmer> Riddell: will do, thanks
[09:59] <vila> poolie: \o/
[09:59] <vila> poolie: good evening
[10:03] <maxb> jam: No traceback, just a HTTP 400 response. It's quite annoying. I get the same in UDD importer local tests - yet everything still seems to work!
[10:03] <poolie> hi maxb
[10:04] <maxb> Hello
[10:04] <maxb> I guess I need to get httplib2 to log all requests or something
[10:04] <poolie> httplib2.debug=1 or something like that
[10:06] <poolie> woo
[10:06] <poolie> https://tbe.taleo.net/NA3/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=308
[11:34] <marvin2> Hi, I have a local version of the branch lp:original-code; I need the some specific changes made to a fork of that branch located at bzr branch lp:forked-code. What is the most efficient way for me to incorporate those specific changes to my local bzr repo?
[11:48] <jelmer> hi marvin2
[11:48] <jelmer> marvin2: "bzr merge lp:forked-code"
[11:50] <jelmer> Riddell: thanks for the review
[12:02] <marvin2> jelmer: I need only specific changes from lp:forked-code
[12:02] <jelmer> marvin2: after the merge you should be able to revert the changes you don't need
[12:03] <marvin2> jelmer: OK, was looking for a more efficient way.
[12:03] <jelmer> marvin2: alternatively, you can generate the diff between the two branches and edit that to contain the changes you need
[12:04] <marvin2> jelmer: Exactly -> to generate a diff between the two branches, I'd have to have two separate repos on my local system - one for lp:original-code and one for lp:forked-code - is that correct?
[12:05] <jelmer> marvin2: not necessarily, you can diff against a remote branch
[12:05] <jelmer> bzr diff --new=lp:forked-code I think
[12:06] <marvin2> jelmer: That becomes painful when lp:original-code is several revisions ahead of lp:forked-code
[12:06] <jelmer> marvin2: why does that become painful?
[12:07] <marvin2> jelmer: lp:forked-code is a fork to fix a bug, but hasn't been merged into lp:original-code yet. I'd like to manually bring it in to my local fork of lp:original-code.
[12:07] <jelmer> marvin2: That's what "bzr merge" does; maybe I don't understand the full use case?
[12:08] <marvin2> lp:original-code is at revno 10; lp:forked-code forks and adds bugfixes to it, and stagnates. Meanwhile lp:original-code keeps updating without incorporating lp:forked-code's fix.
[12:09] <marvin2> jelmer: I'd like to keep up to date with lp:original-code, while manually merging in the fix from lp:forked-code
[12:09] <marvin2> jelmer: Keep in mind original-code is "huge".
[12:10] <jelmer> marvin2: I don't see how merge is inappropriate here
[12:11] <marvin2> jelmer: lp:forked-code still contains code that has been updated by lp:original-code.
[12:11] <marvin2> jelmer: I don't want to lose the changes made in lp:original-code.
[12:12] <marvin2> jelmer: I hope I make sense.
[12:13] <jelmer> marvin2: Sorry, I don't think I follow
[12:13] <jelmer> marvin2: a merge of lp:forked-code won't overwrite changes made in lp:original-code
[12:14] <jelmer> it'll try to merge the changes and create conflicts if there were any
[12:15] <marvin2> jelmer: There'd be a lot of conflicts as lp:forked-code stays at revno 11, while lp:original-code move ahead to, let's say, 25...
[12:16] <marvin2> jelmer: I'd like to figure out the most efficient way of dealing with this. I don't want to go around resolving 100s of conflicts I expect would show up. I just need the diff for a specific subset of files.
[12:16] <jelmer> marvin2: why would there be a lot of conflicts? Is lp:forked-code changing the same chunks of code
[12:16] <jelmer> ?
[12:16] <jelmer> marvin2: generating a diff for forked-code and applying that would generate the same number of conflicts as merge, if not more AFAIU
[12:17] <marvin2> jelmer: I think I'm wasting your time here. Let me get back to you with a proper example. Thanks for the help!
[12:17] <marvin2> jelmer: I won't be generating a diff for the whole tree - just a subset of the files.
[12:18] <jelmer> marvin2: but have you changed any of the other files in lp:forked-code?
[12:18] <marvin2> jelmer: No...
[12:18] <jelmer> marvin2: then there shouldn't be any risk of getting conflicts in them
[12:19] <marvin2> jelmer: Oh...
[12:19] <jelmer> marvin2: perhaps it's worth giving merge a try? As long as you don't commit, you can revert it without it ending up in your history.
[12:20] <marvin2> jelmer: Yeah, I'll try that. Thanks!
[12:34] <marvin2> jelmer: Given lp:original-code and lp:forked-code, how do I figure out the revno in which forked-code was forked from original-code?
[12:39] <jam> marvin2: bzr log -r ancestor:lp:original-code -d lp:forked-code
[12:39] <jam> though that may give a different answer if forked-code has then merged original-code again
[12:40] <marvin2> jam: Great, thanks!
[12:40] <jelmer> marvin2: there shouldn't be a need to specify a revision(if I understand your use case)
[12:40] <marvin2> jelmer: Pure for academic purposes.
[12:40] <marvin2> *Purely
[12:53] <marvin2> jam: Complains about "-d"
[13:00] <jelmer> marvin2: the -d isn't necessary
[13:03] <vila> marvin2: 'bzr qlog original forked' (qlog is provided by the qbzr plugin) is another way to look at it
[13:08] <marvin2> jelmer, vila: Thanks again.
=== zyga is now known as zyga-food
=== mbarnett` is now known as mbarnett
[13:48] <vila> jam: ping, did you get my pm ?
[14:09] <jam> vila: just got back to my desk
=== zyga-food is now known as zyga
=== mnepton is now known as mneptok
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
=== med_out is now known as medberry
=== yofel_ is now known as yofel
[21:12] <lifeless> jam: bug 813017 looks fun
[21:12] <ubot5> Launchpad bug 813017 in loggerhead "DatabaseError: database disk image is malformed" [Critical,Triaged] https://launchpad.net/bugs/813017
[21:13] <mwhudson> sqlite aiming for feature compatibility with bsddb?
=== zyga is now known as zyga-afk
[23:05] <poolie> hi all
[23:08] <jelmer> g'morning poolie
[23:08] <poolie> hi there
=== quotemst1 is now known as quotemstr