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