[00:24] <poolie> i wonder how that person went with the retry-lock thing
[01:00] <spiv> Good morning
[03:00] <spiv> Gar, unity or compiz or something has lost my mouse buttons again.
[03:01] <spiv> Hmm, closing a bunch of firefox and gnome-terminal windows at random got it back :/
[03:19] <poolie> hi spiv
[03:19] <poolie> -> fixreleased :)
[04:02] <spiv> poolie: oh wow, that little categorise_failures.py patch has changed it from taking most of a minute to about 3 seconds.
[04:03] <spiv> I thought it must be broken because the process was only visible for one refresh of top(1) :)
[04:13] <poolie> way to go :)
[05:08] <gour> morning
[05:09] <gour> jelmer: attempt to update git repo, has given me: http://pastebin.com/8nVnUNmn
[05:23] <poolie> hi gour
[05:24] <gour> morning poolie
[05:29] <leo2007> how to view the commit with id b97184973?
[05:31] <lifeless> bzr diff -c revid:b97184973
[05:32] <spiv> In general you can just do "bzr log -r REVID" (or "bzr diff -c" as lifeless says), but that doesn't look like a revid from bzr.
[05:32] <leo2007> lifeless: thanks.
[05:32] <leo2007> spiv: not if it is a sha1.
[05:33] <spiv> Well, bzr revids aren't sha1 hashes, or truncations of them.
[07:33] <poolie> spiv, still here?
[07:35] <poolie> i might do bug 794631
[07:35] <spiv> I am
[07:35] <poolie> by requeing that package
[07:36] <poolie> just wondered if you had touched the importer recently
[07:36] <poolie> to deploy max's fix
[07:36] <spiv> poolie: you mean https://bugs.launchpad.net/udd/+bug/793393 ?
[07:36] <poolie> yes, though the specific relevant change is https://code.launchpad.net/~maxb/udd/import-ordering-fix-take-2/+merge/63335 i think
[07:36] <spiv> I'd been hoping the thousands of spurious failures would clear up a little faster :(
[07:37] <poolie> due to the lp outage?
[07:37] <spiv> Right
[07:37] <poolie> francis suggested perhaps we should ask the losas to shut it off during an lp downtime deploy
[07:37] <spiv> Yes, I think that's probably a good idea
[07:37] <poolie> generally speaking automation is better than additional manual steps, but...
[07:37] <poolie> ok
[07:37] <spiv> It's not going to give wrong results, it just avoids effectively DoSing the import queue for a day
[07:37] <lifeless> mmm
[07:38] <lifeless> so
[07:38] <lifeless> I'd like it if we don't give the losas -more- things to do during the downtime.
[07:38] <spiv> The importer ought to be able to clear that backlog faster, of course.
[07:38] <spiv> I'm not sure why it's so slow
[07:38] <lifeless> can you probe LP and see if its showing the readonly warning ?
[07:38] <spiv> If there's an API for that, then that's probably fairly easy
[07:39] <lifeless> Well
[07:39] <lifeless> the API doesn't work during downtime.
[07:40] <lifeless> The OAuthToken table can't be written to
[07:40] <poolie> :/
[07:40] <lifeless> it *may* work for readonly requests.
[07:40] <poolie> so we can see if the error you get is comprehensible
[07:40] <poolie> astr at least some errors are socket.error
[07:40] <poolie> *istr
[07:40] <spiv> Yeah.
[07:40] <lifeless> (Another reason why I want to go to plain old 'its down down down' but make that fast.
[07:41] <poolie> phut
[07:42] <poolie> so, there's no clear "are you down" api?
[07:42] <lifeless> search for readonly mode in the html of https://launchpad.net/
[07:42] <poolie> ok
[07:43] <poolie> or a socket error reading that page could also indicate we should make a cup of tea instead
[07:43] <lifeless> indeed
[07:43] <lifeless> also a 500 or 400 on that page
[07:43] <lifeless> all signs that Something Is Wrong Fred
[07:43] <poolie> maybe it should return a float :-)
[07:43] <poolie> ok
[07:43] <lifeless> the other thing you might like to do
[07:44] <lifeless> is to keep a track of the overall failure rate
[07:44] <lifeless> and if it shoots up for any reason, stop and wait for an admin
[07:44] <poolie> hm
[07:44] <lifeless> this will help you if e.g. a bad bzr build gets on the machine
[07:44] <poolie> i see what you mean but that would be exactly wrong in the current situation
[07:44] <poolie> where things will suck immensely for 1-2 hours, then get better
[07:45] <lifeless> there is a integration pattern around this whose name I temporarily forget
[07:45] <poolie> i know
[07:45] <poolie> ok
[07:45] <lifeless> sure
[07:45] <lifeless> anyhow
[07:45] <poolie> i wonder if an "is lp up" function would be accepted into lplib?
[07:45] <poolie> istm it's the sort of thing that should be there, rather than having crappy implementations everywhere
[07:46] <lifeless> my key constraint is: we are taking things-losas-need-to-do-during-rollout and throwing them out. So as long as you don't add to that load, I have no particular interest in how you solve it ;)
[07:46] <lifeless> poolie: yes, putting it in lplib makes sense to me
[07:46] <poolie> well
[07:46] <poolie> i thought you would say that
[07:46] <poolie> was interesting francis said the opposite :-P
[07:46] <lifeless> he did ?
[07:47] <lifeless> I shall have to have words with that boy :)
[07:47] <poolie> that's what i said
[07:47] <poolie> just pragmatism vs long term view i think
[07:47] <lifeless> stuart is automating the inner loop of the deploy and working out
[07:54] <spiv> poolie: ok, bzr-builddeb and udd are now current on jubany, and the sysvinit import requeued as requested by maxb
[07:54] <poolie> ah
[07:54] <poolie> i already requeued it, but that should be harmless
[07:54] <poolie> thanks anyhow
[07:54] <spiv> Ah :)
[07:55] <vila> poolie, spiv: There was a discussion about adding some canaries to mass_import so that we stop adding imports if either lp or another mirror went offline
[07:56] <poolie> yes
[07:56] <poolie> let's do it
[07:56] <poolie> bonjour
[07:57] <vila> helllo :)
[07:58] <vila> I can't remember if there was a bug for it though
[08:08] <spiv> *Ah*
[08:08] <spiv> I think I've figured out this fetch problem.
[08:10] <spiv> Just because inventory X is present and parent of the set being streamed doesn't mean we can safely assume X's CHK pages will be streamed from a fallback
[08:11] <spiv> Because the fallback may have an inventory Y that is a present parent that has a same CHK root node as X
[08:11] <spiv> So it will also think it doesn't need to send those CHK records, leaving the client sad.
[08:12] <spiv> And this is happening with lp:debian/experimental/libffi + fallbacks.
[08:15] <vila> jelmer: http://webnumbr.com/imported-branches-on-launchpad is the summary of your recent mail storm regarding imports right ? If so, keep going ! :D
[08:20] <jam> morning all
[08:21] <jam> spiv: I should also note one clarification from your stacking invariant post
[08:21] <jam> we currently *exclude* both parents
[08:21] <jam> not keep the set relative to P1 *and* the set relative to P2
[08:22] <jam> it is R - (P1 + P2), not (R - P1) + (R - p2)
[08:22] <jam> since both parents are in the stacked-on-location
[08:23] <jam> I can see an argument for doing it the way you said, but that is not how we do it today.
[08:24] <spiv> jam: Hmm, I'm having trouble relating what you just said to what I wrote.  Is this referring to the paragraph beginning "What about revisions at the stacking boundary with more than one parent?"?
[08:24] <jam> yes
[08:25] <jam> let me see if I can quote it
[08:26] <jam> "All of their parent revisions must be present" is not accurate
[08:27] <jam> all of the inventories for their parent revisions
[08:27] <jam> I think the confusion was just "revision" vs "inventory"
[08:28] <jam> we do hold both parent inventories, because it makes it easier to determine the minimum file texts to hold for the child revision.
[08:28] <jam> I don't think it is because you may get a fetch from one vs the other parent, more that it means fewer file texts
[08:28] <spiv> Ah, yes, I think it should say "inventories" rather than "revisions" there.
[08:46] <vila> jam: still ok to pair ?
[08:47] <jam> vila: in just a little bit, yes
[08:47] <jam> mumble?
[08:47] <vila> jam: ok, find me on mumble ... hehe yeah
[08:49] <spiv> Oh good, I think I see a spurious failure that manifested in get_testament_sha1 (due to a LP timeout) that is reported better now that I fixed that code to use add_cleanup
[08:49] <spiv> Nice to see fixes have a visible effect.
[08:50] <spiv> Ok, time to pick up V etc.  Have a good day folks!
[08:53] <fritz[]> hi
[08:53] <fritz[]> poolie, u there?
[08:54] <fritz[]> I've updated https://bugs.launchpad.net/bzr/+bug/680529?comments=all
[09:00] <jam> fritz[]: poolie is probably done for the day, but you might see him around
[09:01] <fritz[]> :(
[09:01] <fritz[]> can you help?
[09:12] <Riddell> good morning bazaar
[09:19] <vila> Riddell: _o/
[09:22] <jelmer> hi Riddell, vila, jam
[09:22] <jam> morning vila
[09:22] <vila> jelmer: heya
[09:22] <jam> hi Riddell
[09:22] <vila> jelmer: seem my previous comment about imported branches ?
[09:22] <vila> s/seem/seen/
[09:22] <jelmer> vila: yes, thanks :) That should indeed be the result of my work
[09:22] <jam> fritz[]: are you seeing the warning everytime with your patched version of bzr + qbzr, or only with stock bzr or ?
[09:26] <fritz[]> jam: everytime
[09:26] <fritz[]> with stock bzr
[09:26] <fritz[]> qbzr isn't part of bzr?
[09:28] <jelmer> fritz[], no, it's a separate plugin (https://launchpad.net/qbzr) although it's bundled with the windows bzr installer
[10:31] <poolie> hi fritz[], all
[10:35] <poolie> vila, jam, are you going to work on bug 721211? i'd be happy if you did
[10:36] <jam> poolie: we're working on it now. So far it looks like a genuine conflict
[10:36] <vila> poolie: we *are* digging right now
[10:38] <maxb> Urgh, the silly package-import queue from the downtime is going to take all day to clear :-/
[10:39] <bialix> hi, I have question about revision specifiers
[10:39] <poolie> we were talking before about either making it detect lp is down and back off; or asking the losas to turn it off when lp is upgraded
[10:39] <bialix> I want to have `bzr log -r after:$REVISION..-r-1`
[10:39] <poolie> hi bialix, maxb
[10:39] <bialix> hi poolie!
[10:39] <poolie> i should go and cook though
[10:39] <bialix> there is -r before:XXX
[10:40] <bialix> how can I do -r after:?
[10:40] <maxb> The problem with after is which parent do you choose if there are multiple ones?
[10:41] <bialix> left hand parent revision is $REVISION
[10:42] <bialix> so basically I want `bzr log` excluding $REVSION
[10:43] <poolie> night all
[10:45] <jelmer> enjoy your evening poolie
[10:53] <Riddell> bialix: what version of bzr does bzr-explorer depend on?  for https://code.launchpad.net/~jr/bzr-explorer/781204-fix-deprecated-usage/+merge/63398
[10:57] <jam> vila: https://bugs.launchpad.net/bzr/+bug/530584
[10:57] <vila> https://bugs.launchpad.net/bzr/+bug/364336
[11:05] <bialix> hi Riddell
[11:06] <bialix> Riddell: we don't have a strict policy
[11:06] <bialix> but new release will definitely be targeted to at least 2.3 or 2.4
[11:06] <Riddell> hmm, python programming, I should have known :)
[11:07] <Riddell> bialix: so that change should be ok?
[11:09] <bialix> guys, with bzr 2.3.3 I have C:\work\Bazaar\plugins\scmproj\tests\test_project.py:1077: DeprecationWarning: bzrlib.plugins.scmproj.tests.test_project.TestSub
[11:09] <bialix> projects_v1.failUnlessExists was deprecated in version 2.4.
[11:09] <bialix> why bzr 2.3 told me about Deprecations in 2.4?
[11:09] <Riddell> it's a warning from the future, very sci fi
[11:10] <bialix> spiv around?
[11:12] <spiv> bialix: only slightly
[11:13] <bialix> spiv: https://bugs.launchpad.net/bzr/+bug/794954
[11:13] <bialix> just yesterday I've upgraded my server
[11:13] <bialix> any thoughts?
[11:13] <bialix> or I should just rollback to older version
[11:14] <spiv> bialix: what does the server's bzr.log say?
[11:14]  * bialix looking
[11:14] <spiv> bialix: there's no obvious unguarded import of pwd in bzrlib, perhaps a plugin added one?
[11:15] <spiv> Unexpected errors from servers log tracebacks to the server's log
[11:15] <spiv> (I suppose you could try bzr serve --no-plugins to confirm)
[11:17] <bialix> spiv: my server usually runs as windows service
[11:17] <bialix> there is nothing in .bzr.log
[11:18] <bialix> spiv: it seems I've hit https://bugs.launchpad.net/bzr/+bug/660174
[11:18] <spiv> bialix: huh, odd
[11:18] <bialix> spiv: it works ok if I run bzr serve as regular user
[11:18] <bialix> so that's indeed that bug
[11:19] <spiv> That bug does look likely
[11:19] <spiv> Separately it would be good to have 'bzr serve' keep a log file when run as a windows service
[11:20] <spiv> My memories of configuring windows services are a decade old though so I'm not quite sure what that would involve.
[11:20] <spiv> You could explicitly set BZR_LOG in the environment of the service I guess
[11:22] <bialix> not only BZR_LOG but everything else as well, like BZR_EMAIL
[11:24] <bialix> the only problem here is that I have no way to set env variables, and I have to use some batch wrapper
[11:24] <bialix> Riddell: sorry for the delay with review, I should be able to review and land your changes this weekend
[11:25] <vila> ha, was commenting on the bug...
[11:25] <vila> bialix: yup, wrapper sounds the most reliable way to work around the issues there
[11:26] <bialix> vila: but wrappers have their own cons
[11:26] <vila> bialix: try to reach some point where you at least get some feedback about the failures
[11:26] <bigjools> is there any reason why a "bzr pull" would update loads of files and then finish with "bzr: ERROR: [Errno 13] Permission denied" ?
[11:27] <vila> bialix: *then*, once the bugs are identified, we can address them
[11:27] <vila> bialix: does windows logs give you at least some traceback *now* ?
[11:27] <bialix> vila: of course, I just need to write a patch, but not right now
[11:28] <bialix> spiv: thanks for your help, I know what to try next
[11:29] <vila> bialix: no, that's not what I'm saying, I think you'd better write a wrapper to get useful feedback as I suspect there are several cases where the server will fail for different reasons (log and locks being my first suspects)
[11:29] <vila> bialix: so it will probably be easier to work around the issues by setting env variables in a wrapper
[11:29] <vila> bialix: as they may be several ones needed
[11:29] <bialix> or provide fake pwd module
[11:29] <vila> bialix: and then we could work on making the wrapper useless
[11:30] <vila> bialix: I think this one is needed to prompt the user so that won't help
[11:31] <vila> bialix: hmm, may be not, the bug report traceback points to locks indeed to we're trying to get a valid user
[11:32] <vila> s/to/so/ grr
[11:32] <vila> s/indeed to/indeed so/ I meant
[11:34] <bialix> vila: lol: https://bugs.launchpad.net/bzr/+bug/660174/comments/9
[11:36] <vila> hehe, did the execption explained "why" in your case ? :D
[11:36] <bialix> rotfl
[11:38] <spiv> bialix: not that I know of, sounds like a bug report including traceback is warranted
[11:39] <bialix> spiv: bug report to python itself?
[11:39] <spiv> bialix: oh, sorry!  I meant bigjools!
[11:40] <spiv> Time to eat dinner.
[11:40] <bigjools> spiv: no traceback :(
[11:40] <bialix> bon appetit
[11:40] <bialix> jam?
[11:40] <vila> bigjools: nothing in .bzr.log either ? At least a path ?
[11:40] <bialix> jam has suggested to set username for SYSTEM user, I don't know how
[11:40] <bigjools> checking
 or provide fake pwd module <- you're already on the wrong codepath by that point
[11:41] <bialix> mgz: yep, I see it now
[11:41] <vila> bigjools: is your .bzr.log owned by you ? Nah, would have failed earlier :-/
[11:41] <bialix> mgz: os.getuid does not exist either
[11:41] <mgz> really, bzr shouldn't be relying on having a user for server-like operations
[11:41] <bialix> mgz: right
[11:42] <bialix> how can I fix that?
[11:42] <vila> bigjools: I vaguely remember bugs related to file/dir owner but... What kind of branch is that ?
[11:42] <bigjools> ah here we go
[11:42] <mgz> but making getuser_unicode return something bogus like "service" for windows when there's no local user might be the easiest workaround
[11:43] <mgz> `if sys.platform == "win32" and not "USER" in os.environ` or something
[11:43] <bigjools> vila: here's the error: http://pastebin.ubuntu.com/622469/
[11:43] <vila> mgz: in the lock code you mean or in get_user_unicode (hi by the way ;)
[11:43] <mgz> *USERNAME
[11:44] <mgz> I mean osutils.getuser_unicode
[11:44] <vila> bigjools: grr, rename not telling us which one, I hate that
[11:44] <mgz> which is what uses the python getpass module, which is where the issue is.
[11:44] <bigjools> vila: yeah :/
[11:45] <vila> the vagueness clarifies a bit, I'm pretty sure we ran into this recently
[11:45] <vila> mgz: does this ring a bell ?
[11:45] <mgz> seems a little familar...
[11:45] <vila> bigjools: bzr version ? 2.3 ?
[11:46] <bigjools> vila: 2.1.4
[11:46] <vila> ouch
[11:46] <mgz> hm, yeah, probably a fix not backported then
[11:46] <bigjools> it's what's on lucid I guess, this is a machine in the Canonical DC
[11:46] <vila> ha, that's why
[11:46] <vila> crap
[11:47] <bigjools> vila: I'll see about getting it upgraded
[11:47] <bigjools> in the meantime, fingers crossed that most of the files got pulled :)
[11:48] <vila> bigjools: it's a bit hard to predict what can happen there, but if I had local access, I'd try a 'bzr st' and a 'bzr revert'
[11:48] <vila> to at least get some reasonable confidence the tree is in sync with the branch
[11:49] <bigjools> vila: ah yes it says "working tree is out of date"#
[11:49] <bigjools> and just hanging now ...
[11:49] <vila> lp tree ?
[11:49] <bigjools> yeah :)
[11:49] <bigjools> it's returned
[11:50] <vila> bzr revert [--no-backup] (unless you fear there was some uncommitted changes there)
[11:51] <bigjools> they can be blown out anyway
[11:51] <bigjools> ok same error
[11:51] <bigjools> darn
[11:51] <jam> bialix: set an env variable for the system user. I'm not 100% sure how. Though you could set it globally, I guess
[11:52] <vila> two ideas: search for files with "incorrect" owner, inspect .bzr/checkout for left over (pending deletion and limbo)
[11:53] <vila> bigjools: and while the clock is tickiling, consider re-creating the tree from scratch (modulo shared repo etc)
[11:56] <bigjools> ARFH
[11:57] <bigjools> vila: found the problem, files owned by other people.  Thanks for the help.
[11:57] <bigjools> is bzr more helpful with the error in more recent versions?
[11:58] <vila> https://bugs.launchpad.net/bzr/+bug/491763
[11:59] <vila> bigjools: it should, this bug is part of 2.2
[11:59] <vila> well, this *fix* is part of :)
[11:59] <bialix> jam: after I finally translate that to Russian I found the way to set System env variable, it was easy actually. I was puzzled by Russian Windows
[11:59] <bialix> I think I need to set BZR_LOG as well there
[12:01] <bigjools> vila: cool :)
[12:56] <maxb> Grr, what?! sysvinit import failed
[12:56] <fullermd> 's why you use bsdinit instead   :p
[12:57] <maxb> wtf, there are sysvinit branches on launchpad
[13:07] <Riddell> https://code.launchpad.net/~jr/bzr-builddeb/changelog-closes-bugs/+merge/63248 is ready to merge in for anyone who has permissions
[13:09] <jelmer> Riddell, more than happy to :)
[13:10] <jelmer> Riddell, I think you should join the team too, though
[13:14] <jelmer> Riddell: done, with minor tweak to mention the bug # in the changelog
[14:04] <Riddell> jelmer: needs james_w to accept me into the team
[14:04] <james_w> Riddell, which team?
[14:04] <james_w> ah
[14:05] <Riddell> ~bzr-builddeb-hackers
[14:05] <james_w> done
[14:05] <Riddell> thanks
[14:10] <maxb> james_w: Can I ask you to rename all the existing ~ubuntu-branches branches at https://code.launchpad.net/ubuntu/+source/sysvinit/+branches to something that the importer will not collide with, and requeue --full sysvinit? It's already been tried once today, but it failed - and I think it failed because it got confused by those remnants from the past
[14:12] <james_w> maxb, I have 6 meetings in the next 2 hours, so if someone else can do it it would be quicker
[14:12] <james_w> maxb, I'll certainly get to it after that if no-one else has
[14:13] <maxb> sure, no problem
[14:51] <maxb> Hrm. We are getting new UDD import failures that say "debian woody is marked but not imported"
[14:51] <maxb> Has anyone been deleting woody branches?
[14:52] <james_w> maxb, maybe the ordering change?
[14:52] <james_w> I don't see why though
[14:52] <james_w> I don't think woody branches are on LP are they?
[14:53] <maxb> Hmm
[14:53] <maxb> interesting
[14:54] <james_w> one of the import_package.py functions does a "if it's a debian series that isn't on LP and there are any debian branches at all then we don't have to import it"
[14:54] <james_w> that might be what is breaking
[17:13] <jblue> hey all, i'm curious what others are doing regarding tags and releases.  I'm looking for a way to do a 'bzr export' which also somehow dumps the revision or tag information as part of the export, in order to identify what revision that export came from.  I'm not very fond of having to update a hard-coded revision in the sources or readme docs.. but is this what is generally done?  Any other elegant ways to manage revision information in an export?
[17:39] <gour> jblue: like CVS $id?
[17:39] <jblue> gour: yeah I was thinking of that as well.. it was pretty useful for it's time
[17:40] <gour> frankly speaking, i do not see need for it, but i understand it may be useful for you
[17:41] <jblue> normally I wouldn't do an export, and just create a branch, whould would contain the lastest revision info
[17:42] <jblue> but often times we're deploying to systems which don't have bzr, and making a full branch seems wasteful
[17:42] <jblue> s/whould/which/
[17:46] <gour> what do you mean 'deploying to.." ?
[17:47] <jblue> gour: making a program/application available for use
[17:47] <gour> jblue: hmm..so where would you like to see revision? e.g. in 'about dialog' or so?
[17:49] <jblue> not necessarily, it could simply be dumped into a "VERSION.txt" file or something off the root of the export.. but would be automated when the export is created.  But making it part of the sources via 'CVS $id' type functionality would also be useful, on an export.
[17:50] <gour> jblue: see this http://www.mail-archive.com/ella-animation@lists.launchpad.net/msg00050.html (if it helps)
[17:51] <fullermd> The way I do such a thing is 'make light checkout ; run script to stuck info somewhere ; rm -rf .bzr'
[17:54] <jblue> fullermd: would you be able to post that script somewhere that I can take a look?
[17:56] <fullermd> It's not a specific script, just $DO_WHATEVER.  'bzr revno > foo.txt', or whatever.
[17:56] <jblue> ah ok
[17:58] <jblue> right, I guess I could just roll my own
[17:58] <jblue> echo $(bzr tags -r `bzr revno`) > VERSION.txt
[17:58] <jblue> for example
[17:59] <jblue> was just curious if there was a more common way of doing it
[17:59] <abentley> vila: around?
[18:00] <vila> abentley: I'm EODing at this minute :-/
[18:01] <vila> I may pass around later but probably not for long
[18:01] <abentley> vila: I'll email you.
[18:01] <fullermd> jblue: Frex, in the first place that came to mind, I do some sed'ery to get the revid into a .h file.
[18:03] <fullermd> Just another thing to do as part of the "make tarball" script that already does things like build the docs (hardly anybody will have the necessary toolchain), etc.
[18:04]  * gour is researching about bento
[18:04] <gour> ..as build & packaging tool
[19:19] <maxb> Gah
[19:19] <maxb> I've failed at getting the udd import ordering to do precisely what I want, again
[19:20] <jblue> /win 4
[19:24] <maxb> james_w: Please don't requeue sysvinit after all. I'm going to go and work on take 3 of the import ordering code
[19:24] <james_w> maxb, ok
[21:10] <jblue> is is possible to pull a specific change from one branch into another?
[21:15] <jblue> for example, I have a branch with 5 revisions.  I make another branch off that one, at revision 2, and I want to merge in the changes from revision 4 off the original branch
[21:15] <jblue> without including revision 3 or 5
[21:18] <jblue> think I found it.. --change
[21:50] <maxb> jblue: You can't *pull* in such a scenario, but you can merge. bzr merge -c revspec ../otherbranch
[22:00] <jblue> thanks maxb, also found that I can something like: bzr merge -r 43..44 .. which has the same effect
[22:00] <maxb> Yes, -c X is just shorthand for -r before:X..X
[22:00] <jblue> nice
[22:30] <mhall119> is there a way to pass bzr builddeb a specific gpg key to use for signing?