[00:11] <Noldorin> anyone here use bzr on Mac OS X??
[00:16] <SamB_MacG5> yeah
[00:16] <bob2> as always, better to just ask your question!
[00:17]  * SamB_MacG5 is actually working on an updated OS X 10.5 installer for Bazaar 2.3
[00:19] <SamB_MacG5> well, *these* plugin versions are clearly too new ...
[00:26] <bjp> can i use bzr update or bzr pull in a way that discards any local workingtree changes?
[00:27] <bjp> instead of creating conflicts
[00:27] <LeoNerd> revert first
[00:27] <LeoNerd> Or afterwards
[00:27] <bjp> i thought thats what pull --overwrite did,
[00:27] <bjp> can't do it in one command?
[00:28] <lifeless> pull --overwrite discards conflicting history
[00:28] <bjp> oh
[00:28] <lifeless> there isn't a reset --hard, you need two commands - sorry.
[00:29] <bjp> i wish there was a way to batch commands or something, the majority of the time for my script is ssh login/auth for bzr commands :(
[00:29] <LeoNerd> Use an ssh key
[00:30] <LeoNerd> Or maintain a persistent connection using ControlMaster
[00:30] <bjp> i am using an ssh key, and ControlMaster doesn't work on windows :(
[00:30] <bjp> i've looked into it a few times, could never find a good way to do it
[00:30] <LeoNerd> Ahhh
[00:35] <bjp> i do a revno + update on ~50 projects in a script
[00:35] <lifeless> you can drive it through python
[00:36] <bjp> so the connection/auths take a while
[00:36] <bjp> that might be worthwhile
[00:37] <bjp> the script is in python... i'm just using subprocess to launch bzr
[00:40] <bjp> bzrlib.workingtree.WorkingTree opens and maintains a connection?
[00:50] <SamB_MacG5> huh? Nobody tagged bzr-loom 2.1?
[00:50] <fullermd> That's pretty warped.
[00:50] <mwhudson> fullermd: you're a bad man
[00:51] <fullermd> Yeah, but I look so good doing it.
[00:52] <SamB_MacG5> http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/revision/109 appears to be the revision that should have been tagged ...
[01:00]  * SamB_MacG5 wonders what the point of having internet drafts expire is
[03:27] <lifeless> jam: is https://bugs.launchpad.net/bzr/2.0/+bug/433779 now Fix Released ?
[04:07] <jam> lifeless: from what I can see, the patch was *not* backported to 2.0.* it only landed in the 2.1 series.
[04:08] <jam> so Won'tFix may be more appropriate
[04:12] <lifeless> jam: I just want it off of my 'fix committed' related bugs list :)
[04:12] <lifeless> jam: call me selfish if you like :)
[04:12] <jam> yeah, i'll clear it up
[04:12] <lifeless> thanks!
[04:14]  * SamB_MacG5 wonders what version of bzr-svn works with subvertpy 0.8.1
[05:08] <dardevelin> hi everyone, I need some help regarding bzr+launchpad , i seem to be getting ConnectionReset reading response for 'BzrDir.open_2.1', retrying Permission denied (publickey). And I don't quite understand why since i generated a ssh key and already added to my launchpad account
[05:09] <dardevelin> bzr lp-login nickname works fine (i think since no warnings errors or any kind of messages is sent)
[05:09] <dardevelin> i'm on debian sid system btw
[05:10] <dardevelin> i do know that the package python-paramiko has a bug on using non-default ssh ports
[05:10] <dardevelin> would this be a reason ?
[05:13] <lifeless> bzr+ssh runs on port 22, the default
[05:13] <lifeless> so it shouldn't be
[05:13] <lifeless> is there anything useful in ~/.bzr.log
[05:13] <dardevelin> lifeless, humm let me check
[05:13]  * dardevelin now remembers that he might have been stupid and used .bzr.log from another install
[05:14] <dardevelin> lifeless, it does have quite a lot of stuff in here, seems like python errors
[05:14] <lifeless> well, you could empty the file, try again, and anything thats in there would be relevant
[05:15] <dardevelin> ok let me try login again
[05:15] <lifeless> do you have your ssh agent running, with the key added ?
[05:15] <lifeless> the possible causes are:
[05:15] <dardevelin> ssh agent ? what do you mean
[05:16] <dardevelin> the reason i ask is because i'm able to use git ::/
[05:17] <dardevelin> i do get a warning though when using i3-wm that i don't get when using gnome wm... never really associated since all worked fine
[05:19] <dardevelin> sorry i'm newb with vc systesm :/
[05:20] <dardevelin> lifeless, i do have ssh-agent running at least that's what htop tells me
[05:20] <lifeless> ok
[05:20] <lifeless> so the possible causes for the error you get are:
[05:20] <lifeless>  - wrong userid
[05:20] <lifeless>  - key not available to the ssh-agent
[05:20] <lifeless>  - wrong host
[05:21] <dardevelin> host like machine name  that matches the public key ?
[05:21] <dardevelin> if that's the case i'm pretty sure is correct, i just generate it
[05:21] <SamB_MacG5> that doesn't actually do anything
[05:21] <SamB_MacG5> you can put whatever you want there
[05:22] <dardevelin> but it does match
[05:22] <dardevelin> dardevelin@ycradnileved
[05:22] <dardevelin> user id is darcy-develin (it's exactly what i used on my other install )
[05:23] <dardevelin> so i'm left with ssh-agent not knowing the key
[05:23] <dardevelin> i do have the ssh key with a different name specific for bzr
[05:25]  * dardevelin goes look on how he can see what ssh-agent knows and how to make it know 
[05:26] <lifeless> ssh-add path-to-key-secret-file might wrok
[05:27] <dardevelin> i did it, let me try
[05:27] <dardevelin> :O working now
[05:27] <dardevelin> sweet
[05:27] <dardevelin> lifeless, Thank you so much...
[05:28]  * dardevelin feels happy to finally be able to fix some bugs on his debian machine 
[06:57] <jam> mgz: since you seem to be in the bzr-code-review mindset... https://code.launchpad.net/~jameinel/bzr/2.1-all-reconnect-819604/+merge/123901 :)
[07:27] <mgz> er, morning all!
[07:27] <jam> mgz :)
[07:28] <mgz> how are you jam sir?
[07:28] <jam> mgz: just trying to clean and finish up my reconnect patch
[07:34] <jam> mgz: a slightly cleaner version of the patch for bzr-2.2 is at: https://code.launchpad.net/~jameinel/bzr/2.2-all-reconnect-819604/+merge/124346
[07:34] <jam> mgz: how was your day?
[07:38] <mgz> jam: yeah, the 2.1 version seemed rather scary...
[07:39] <jam> well, 2.2 may not be that much better overall :)
[07:39] <jam> however, if you just do a 'vim -d MY_PATCH/file.py 2.5/file.py' things may be less scary.
[07:39] <jam> As it is mostly the same code.
[07:39] <jam> just missing some features/bug fixes from the years inbetween
[08:08] <jam> mgz: i'm happy to work through it with you over mumble or something, as it would be nice to get it landed, because the 'merge up' is a bit of work that I don't want to drag out for a long time.
[08:08] <jam> mgz, also standup in 20min or so
[08:09] <mgz> jam, that sounds good (to both)
[08:10] <jam> mgz: I'm there
[08:17] <mgz> I am coffee'd
[08:19] <jelmer> coffeefication ftw
[08:19] <mgz> jelmer: reviewed your ping branch before I got the bus this morning
[08:23] <jelmer> mgz: \o/
[08:35] <mgz> over warningness: <http://pastebin.ubuntu.com/1204324/>
[18:01]  * SamB_MacG5 hopes this next installer build gives him a working bzr-svn; he's getting tired of putting BZR_DISABLED_PLUGINS=svn before every other command
[18:03]  * SamB_MacG5 also wishes again that distutils had a standard "test" command, even if it were just a stub by default ...
[18:03] <jelmer> SamB_MacG5: why does it not work?
[18:04] <SamB_MacG5> jelmer: well, it says subvertpy 0.8.1 is too old, but then goes and sticks its hooks into things anyway for some reason...
[18:04] <SamB_MacG5> which works out badly
[18:05] <jelmer> SamB_MacG5: it won't magically fix itself
[18:05] <jelmer> SamB_MacG5: you can update the version of subvertpy?
[18:05] <SamB_MacG5> no, I'm downgrading bzr-svn
[18:06] <SamB_MacG5> stupid SVN 1.4 and all ...
[18:08] <jelmer> ah, that's why you filed that bug
[18:37] <delinquentme> Ok soo in git I can choose to " git push origin master "    IE  git push <repo> <branch>
[18:37] <delinquentme> in bzr I've got a local ... "trunk" ?
[18:37] <delinquentme> and I've got an origin trunk / repo ... as well as a development server
[18:38] <delinquentme> where origin would be the name of a repo in git
[18:38] <delinquentme> is a "trunk" the same as a repo?
[18:38] <delinquentme> or is a bzr trunk more like a branch in git?
[18:41] <LeoNerd> git allows you to store multiple branches in one filesystem location
[18:41] <LeoNerd> bzr does not
[18:41] <LeoNerd> So the "branch" is always implicit as there's only one
[18:42] <LeoNerd> bzr push $REMOTE_URL   just pushes /the/ local branch to /the/ remote branch
[18:42] <LeoNerd> Usually for branches I put  .SOMENAME  on the end of the URL
[18:43] <LeoNerd> $ bzr branch my-project my-project.HACKERY; cd my-project.HACKERY; bzr push bzr+ssh://my.server/var/bzr/leo/my-project.HACKERY
[18:46] <delinquentme> LeoNerd, Ok so different branches reside in different folders?
[18:46] <LeoNerd> Yah
[18:48] <delinquentme> Ok so heres a test case for you
[18:49] <delinquentme> wait!  actually what is a repo in bzr?
[18:49] <delinquentme> is it a trunk?
[18:49] <LeoNerd> A repo is a shared storage location for lots of branches
[18:49] <LeoNerd> bzr doesn't have a notion of a "trunk".. there are just branches.
[18:49] <LeoNerd> Sometimes, branches may share a common history
[18:49] <delinquentme> Hmmmm
[18:50] <delinquentme> ok so in bzr its called a repo as well
[18:50] <delinquentme> check!
[18:50] <LeoNerd> If you call one of them a trunk, that's purely an end-user concept; one branch that you just consider as the canonical source
[18:50] <delinquentme> ok so I've got the remote primary repo
[18:50] <LeoNerd> A repo allows multiple branches that do share history, to share on-disk storage, basically.
[18:50] <delinquentme> ok I think i follow.
[18:50] <delinquentme> but on the term "trunk" while its just an end user concept
[18:51] <LeoNerd> A repo is a storage of revisions; a branch gives a name to some particular revision; the branch stores its history of revisions in its repo
[18:51] <delinquentme> it is *semantically* tied into bazaar right?
[18:51] <LeoNerd> Not really
[18:51] <delinquentme> so then I could call a trunk ... a suitcase
[18:51] <delinquentme> and it would be just as bazaar related?
[18:51] <LeoNerd> If you have two branches that have, say, 10 common revisions, then each diverge for the final 2 each, bzr doesn't know or care which if either you consider a "trunk"
[18:51] <delinquentme> IDK the devs who I'm working with say trunk alot
[18:52] <LeoNerd> E.g. I keep my .vimrc in a bzr branch across all my machines; none of these could be considered any more a "trunk".. they're all just peers that I merge between
[18:52] <delinquentme> like is "trunk" a term they came up with or is it something that other bzr users use as well?
[18:53] <LeoNerd> It's standard VCS terminology
[18:53] <LeoNerd> It goes back many decades, mostly to the non-DVCSes like CVS and SVN
[18:54] <LeoNerd> The non-branch in a CVS directory is usually called the trunk; a SVN project usually has  /trunk  /branches  /tags
[18:54] <delinquentme> ok cool
[18:54] <delinquentme> next question
[18:54] <delinquentme> I pull from a primary repository to my local machine
[18:55] <delinquentme> so local machine is a direct copy of what is up on the repo
[18:55] <delinquentme> now.. someone else copied the same code onto a development server... and I'm about to push my local code ... up to THAT dev server
[18:55] <delinquentme> this will create something akin to a " fast forward " right?
[18:56] <LeoNerd> "fast forward" IIRC is what git calls a strictly non-divergent update, where one side is an ancestor of the other
[18:56] <LeoNerd> This is what bzr pull or push wants to do
[18:57] <delinquentme> correct it is a non-divergent
[18:58] <delinquentme> ... i guess it would also be non-convergent
[18:58] <delinquentme> both code sets have the exact same history .. ending on the same commit
[18:58] <delinquentme> and 1 branch has more
[18:59] <delinquentme> the branch with fewer commits ... get a fast forward on merge
[18:59] <LeoNerd> Yah, that's a push or pull operation
[18:59] <LeoNerd> A "merge" in bzr specifically joins back together two divergent histories, where neither is a strict ancestor of the other
[18:59] <delinquentme> LeoNerd, Is there a way to do something like a --dry-run?
[18:59] <delinquentme> where it tells you what it would do in a push operation ... without actually doing it?
[19:00] <LeoNerd> Probably -n ?
[19:00] <LeoNerd> Hrm.. well,  bzr missing  will explain what's missing
[19:01] <LeoNerd> And ofcourse things like  bzr diff
[19:01] <delinquentme> and -n denotes what option?
[19:02] <delinquentme> this is an option on "bzr push" right?
[19:02] <LeoNerd> Pure guess, but from the help I'm not sure it has one.. :/
[19:02] <delinquentme> hmmm
[19:02] <delinquentme> and what about aliases?
[19:02] <delinquentme> like instead of typing out a whole server IP and local directory path
[19:02] <LeoNerd> ?
[19:03] <delinquentme> can I declare say "development"
[19:03] <delinquentme> bzr push development
[19:03] <LeoNerd> Ah, pass. Possibly..
[19:03] <delinquentme> to push to sftp://nachocheeze@109.1.2.111:3000/usr/local/
[19:03] <LeoNerd> Someone else might know
[19:05] <fullermd> bookmarks plugin
[19:07] <LeoNerd> Also /me => lunch
[19:08] <delinquentme> tanks :D
[19:13] <delinquentme> I know its a bad idea ... but can a server be running a trunk
[19:14] <delinquentme> by running I mean displaying the contents of a trunk to the public who happen to be accessing that server?
[19:15] <delinquentme> or is it a bad idea?
[19:29] <smoser> jelmer, you around?
[19:30] <smoser> you've helped me with bzr recipes before
[19:30] <smoser> https://launchpadlibrarian.net/115990138/buildlog.txt.gz
[19:30] <smoser> failed from https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds/+recipebuild/307084
[19:30] <jelmer> hi smoser
[19:31] <smoser> hey.
[19:31] <jelmer> smoser: ah, that looks like a known bug in the bzr builder
[19:31] <smoser> i'm good at finding stuff like that.
[19:34] <smoser> jelmer, were you just going to hold me in suspense?
[19:34] <smoser> http://paste.ubuntu.com/1205495/ is all i could come up with
[19:35] <jelmer> sorry, got distracted by something.. back now
[19:35] <smoser> but i can't reproduce the failure here with bzr builddeb
[19:35] <jelmer> smoser: it's bzr builder that's the problem
[19:36] <jelmer> smoser: it tries to apply all patches and convert the package to a native package
[19:36] <smoser> but it worked before.
[19:36] <smoser> ie, not long ago
[19:36] <smoser> https://code.launchpad.net/~julian-edwards/+recipe/maas-daily
[19:36] <SamB_MacG5> jelmer: that sounds kind of evil ...
[19:36] <smoser> recipe not changed.
[19:37] <smoser> the complaining file *did* change
[19:37] <jelmer> smoser: you didn't have those patches previously I think?
[19:37] <jelmer> or at least not patches that introduced new files?
[19:37] <smoser> i didnt hvae that one specifically.
[19:37] <smoser> you're probably correct
[19:37] <smoser> none that introduced new files probably.
[19:38] <smoser> previously in that branch the file actually lived in tests/ (ie, not patched in)
[19:38] <smoser> but i intended to fix the warning/error of --source-option=--abort-on-upstream-changes
[19:38] <smoser> (branch above == packaging branch)
[19:43]  * SamB_MacG5 tries the installer
[19:43] <jelmer> SamB_MacG5: What's evil about it? Without that behaviour building would fail.
[19:44] <SamB_MacG5> jelmer: the "convert to native package" part
[19:44] <jelmer> SamB_MacG5: Yes, without that behaviour the build would fail.
[19:44] <SamB_MacG5> buy maybe you meant that differently than I read it
[19:44] <jelmer> SamB_MacG5: as there is no orig tarball
[19:44] <jelmer> SamB_MacG5: note that this is for daily builds
[19:44] <smoser> jelmer, you have a suggestion for how to fix this ?
[19:44] <SamB_MacG5> sure, sure, it just strikes me as a *little* evil
[19:45] <smoser> if i have to at the moment i can just drop the patch (or comment it out)
[19:45] <jelmer> SamB_MacG5: If you don't like it, you could always just have a recipe that is native from the start.
[19:45] <jelmer> smoser: The easiest way to work around it is to have your recipe build a native package.
[19:45] <jelmer> smoser: and/or somehow get rid of debian/patches
[19:46] <smoser> hm.
[19:46]  * jelmer looks for the relevant bug
[19:47] <SamB_MacG5> man, it really seems like some of the stuff in this installer project ought to be built by the scripts rather than baked in...
[19:47] <smoser> maybe for now i'll just not apply that patch.
[19:48] <SamB_MacG5> jelmer: I guess I can't help but think that the "right" thing would be to build an orig tarball from the source tree ...
[19:49] <smoser> well, thats what the recipe says to do.
[19:49] <jelmer> SamB_MacG5: which source tree? there is only one tree, and that has the debian source
[19:50] <SamB_MacG5> isn't there some code somewhere?
[19:50] <jelmer> SamB_MacG5: yes, but it's not clear which code is from upstream and which code is from the debian package
[19:51] <smoser> jelmer, for stop gap, do you think i can just not apply that patch ?
[19:51] <SamB_MacG5> hmm, oh, right
[19:51] <smoser> (just comment out in debian/patches/series )
[19:51] <SamB_MacG5> native packages can still have patches...
[19:52] <jelmer> smoser: yes - the easiest way to do that is to merge in an extra branch that has a change to remove that line
[19:53] <smoser> as i need something "right now" to move on something else, and that patch i think can be delayed a bit.  and, then there is the fact that it actually works if i dont have it as a patch, but the file lives in test/ in the packaging branch.
[19:53] <smoser> but that i didn't like becasue of --source-option=--abort-on-upstream-changes
[19:54] <smoser> i guess i'll just put it back the way it was as that built on the dailybuild server at least.
[19:54] <SamB_MacG5> darn, bzr-svn 1.1.0's test suite doesn't seem to like bzr 2.3 :-(
[20:07]  * SamB_MacG5 wonders why the quick reference card is sideways
[22:07] <SamB_MacG5> is there a way to skip asking a plugin for tests, but still load that plugin?
[22:08] <jelmer> SamB_MacG5: not really
[22:08] <SamB_MacG5> darn
[22:11] <SamB_MacG5> so not only can I not run bzr-svn's tests, but I can't have it loaded when I run the other tests :-(
[22:42] <jelmer> SamB_MacG5: really, if you have a version of bzr-svn that's incompatible you should just uninstall it.
[23:38] <SamB_MacG5> jelmer: this one is supposed to be compatible, though
[23:38] <SamB_MacG5> just the tests code doesn't seem to be