[00:01] Does Robert Collins hang out here? [00:01] * abadger1999 not sure which time zone he'd be in either. [00:02] yes, and gmt+12 or something equally ridiculous [00:03] lifeless, ^ [00:06] abadger1999: ola [00:06] ola [00:06] toshio ? [00:06] I'm Toshio [00:06] Yep [00:06] cool :) [00:07] Do you release loggerhead with python setup.py sdist? [00:07] If so, I've got some additions to MANIFEST.in and some questions :-) [00:09] abadger1999: I think I do; sure - shoot [00:11] lifeless: Cool. Do you want the loggerhead/tests directory in the installed plugin? [00:11] don't really care [00:11] lifeless: Okay. [00:11] if it works without it there is no particular reason to include it [00:11] [00:11] I think the sdist should include it [00:11] bzr selftests can access it [00:11] So I wasn't sure whether to install it or not [00:12] I think the sdist needs to include it so that folk doing their own installs can validate etc [00:12] but for an installed package, that sort of variation is eliminated [00:13] if that makes sense? [00:13] Yeah. just a choice of whrether to put it in MANIFEST.in or in setup.py's packages=[] [00:13] Sounds good. I'll put it in MANIFEST.in then [00:13] Other two directories I wasn't sure of were loggerhead/middleware and load_test_scripts [00:14] hmm, lets see [00:14] middleware has a profile middlewware in it that loggerhead seems to use if a config option is set to do profiling. [00:15] yeah, that should be included [00:15] we should break that out to a separate package, let other folk reuse it [00:15] [00:15] and then depend on it, but that is for later [00:18] The stuff in load_test_scripts not sure if that needs to be included at all? [00:18] yeah [00:18] leave it out I suspect [00:18] bbs, baby needs me [00:19] actually still here [00:19] but in 10 I may not be :P [00:20] Okay :-) [00:20] I'll push a branch for this and propose for merging. [00:20] thanks! [00:20] de nada :-) [00:22] oh, cool, a yet another wsgi profiler middleware? [00:23] of course [01:14] hi all [02:22] hi [02:22] when I run a script which perfoms several bzr commands, and then I press ^C, the full script doesn't stop, just the current bzr command being run. [02:23] Is there a way to tell bzr not to handle by itself ^C and let it die? Would that be transaction safe? === r0bby is now known as robbyoconnor [02:28] lifeless: Just letting you know, with the changes in the lp:~toshio/loggerhead/sdist-post-1.8.1 branch, I have a working loggerhead package. (tested with bzr-2.4.2) [02:28] abadger1999: cool [02:28] abadger1999: I won't get to your branch today, but will soon [02:28] jvargas: 'set -e' in your shell script [02:28] Cool [02:29] jvargas: its not a bzr issue, its your script [02:30] thank lifeless! just wondered if that behaviour was parametrized. [02:33] jvargas: its totally outside bzr's control [02:34] the ctrl-c is received by the shell running the script, and passed onto the current subcommand (bzr in this case) and then it decides based on the subcommand exit code, and the setting of -e (or +e which is the default) whether to continue or not [02:37] okay [02:46] <3 set -e [07:17] hi all ! [07:18] hi there vila [08:37] http://www.youtube.com/watch?v=BbuXK1pWD-M LOOOOOOOOOOOOOOOOOOOOL [09:25] morning [09:31] hi mgz, jelmer [09:31] hey poolie [09:31] morning mgz, poolie [09:31] hmm, how do I link an upstream bug again? [09:33] LarstiQ: two ways, one do "Also affects project" then do the project name, then add the upstream bug url [09:34] hi there larstiq [09:34] that should be what you want for pypy [09:35] mgz: cheers! [09:35] heya mgz [09:35] hey LarstiQ, it's good to see you around ;) [09:35] hey vila :) [09:36] vila: anything to avoid spackling more walls ;) [09:36] ha ha ha [09:39] mgz: I must admit that I didn't quite grasp what the problem on win32 was, so haven't filed a bugg about that yet [09:40] LarstiQ: the bug you filed sort of covers it anyway, except the implementation in pypy would need to be different [09:40] right [10:43] jelmer: just seeing bug mail on a loom change, are there any other plugins I need to double check I have the latest version of when I do the installer? [10:56] mgz: I'm not sure [10:57] we should have a more structural way of testing the plugins [10:57] jelmer: that was as in, "ones you remember touching to fix colo things" rather than please give me an exhastive list [10:57] mgz: ah [10:57] mgz: the foreign ones, but I'd guess you already have those [10:58] but yeah, just running the plugin tests and being confident that means they're okay would be nice [10:58] for loom at least, the tests broke because of the bzr core change [10:59] have subvertpy 0.8.9; bzr-svn 1.1.2; dulwich 0.8.2; bzr-git 0.6.6 [11:01] more things are just tip than I remembered, so should generally be fine [11:04] cool [11:55] bzr pull forkbomb! it spawned ~400 children when pulling from svn [11:56] ccxCZ: huh? It shouldn't create any child processes at all [11:56] ccxCZ: what kind of processes were they? [11:59] bzr pull ... [11:59] seemed it just forked zillion times, but not exec'd [12:01] http://wpr.cz/ccx/bzrpull.png [12:02] is that actual processes, or could it also be threads? [12:02] you can see the PIDs [12:03] ccxCZ: sorry, I would have no idea what's going on - we don't fork as far as I know [12:03] ah sorry they *might* be threads [12:04] ccxCZ: ah, ok - that could be the case if you have 'use-cache = False' set [12:04] they probably are, didn't know threads use up PIDs too [12:06] ccxCZ: do you have 'use-cache = False' set? [12:07] doesn't seem so [12:08] load >200 :D [12:09] no such setting in ~/.bazaar [12:09] I just grepped [12:52] ccxCZ: hmm, that's odd [12:52] mgz: are you looking at bug 921484 ? [12:52] Launchpad bug 921484 in Bazaar "bzr: ERROR: exceptions.AttributeError: 'InventoryLink' object has no attribute 'children'" [Undecided,Incomplete] https://launchpad.net/bugs/921484 [13:22] mgz: ping [13:24] pong [13:24] what's the status for 2.5b6 windows installers ? [13:25] unstarted. [13:25] :-/ [13:26] I probably have some time this evening [13:26] but really want to release with some bzr-explorer changes [13:28] jelmer: see the update to that bug in my mail now [13:28] *I have just seen [13:32] jelmer: did you upload 2.5b6 to debian ? [13:32] vila: yep [13:32] not to precise yet [13:32] ok, cool, thanks ! [13:38] vila: ubuntu done too [13:54] okay, that bzr bug is a little fun, I'll update so current state is clear [14:27] hello, I have seen people using "init-repo --no-trees" to create repository within existing treeless repositories (see http://paste.pocoo.org/show/547792/ ). Is it legit? [14:30] pmezard: yes, that should be valid [14:30] How does it compare to regular branching? Do you know documentation about this? [14:31] pmezard: compare in what sense? the innermost repository gets used, the outer one isn't involved at all [14:32] what puzzles me is calling .find_branches() on outer seems to return the inner branch as well, while I would have expected it to be ignored somehow [14:32] and calling .get_revision() on outer fails with this revision [14:33] so it is not clear to me how bother repositories/branches(?) interact [14:33] pmezard: find_branches() just recurses to find branches. You have to specify using=True as argument to only get those branches that actually use the repository you call it on. [14:34] oh that's what "using" means [14:34] jelmer: excellent, thank you [14:37] np :) [16:22] ho hum hum [16:24] mr gz, sir! [16:25] ...that makes me sound a little more noble than I deserve [16:27] mumble mumble? [16:27] mumble gz sir ? [16:29] feel free to jump on as well vila [16:34] oooh I thought you mean mumble as in... well, mumbling :) [16:34] * vila try to focus again :) [16:45] hey everyone! fabuluous morning over here and I hope everyone is feeling the same. [rub rub] [16:46] quick question on bzr and any pointers to docs etc i would appreciate [16:46] I have a branch which i've been working on and piling on a few changes which have gone beyond the scope of the ticket i was working on [16:47] i'm coming from a git background ... would usually start a new branch and then cherry pick changes up to a related point etc. [16:47] what's the best workflow for this in bzr [16:49] djfroofy: have you commited them? [17:13] LarstiQ: yep [17:14] all of the changes are in neat (or neat enough) little commits ... so cherry-picking should be a simple task [17:14] i'm going through the bzr docs right now [17:15] djfroofy: mirroring the git workflow, you could use `bzr merge -c path/to/original/branch` per revision you want to have [17:16] perhaps the rewrite plugin has support for it too, but I don't know it well [17:54] What does backspace do at the 'bzr shelve' "shelve? [yNfq?]" prompt? [17:57] nothing currently. [17:58] a whoopsie go back button would be nice. [17:58] +1 to having a "back" button [17:58] I hate having to quit and restart because I answered one thing wrong [17:58] I don't think it does nothing [17:59] The process advances to the next hunk after I hit it [18:00] what I tend to do most is ynnnnn and hit n one too many times and cancel out at the final "no really?" prompt [18:01] exarkun: possibly a bug with the getchar thing on your platform? what's the bzr version and system? [18:02] Ubuntu 11.10, bzr 2.4.1 [18:02] running in screen in gnome-terminal [18:03] can you do this in a prompt? [18:03] >>> from bzrlib.osutils import getchar [18:03] >>> getchar() [18:03] '\x7f' [18:04] that's hitting backspace after enter on the getchar line [18:04] I'll double check 2.4.1 too [18:06] Same [18:06] Some experiments suggest it's equivalent to n [18:07] ah, I got repo [18:07] how did I just do that [18:08] was trying different num/caps lock keys and the nth backspace hit moved me to the next hunk [18:08] but I now can't get it to do that again [18:09] maybe I just hit the wrong key [18:15] nope, can't get 2.4 to do it for me. best guess is some weirdness with screen or term emu [18:17] Hm, can do it in gnome-terminal w/o screen [18:17] And in xterm w/o screen [18:17] ah, I'll try xterm here [18:18] and uxterm [18:20] okay, happens in xterm with 2.4 [18:20] but not on 2.5 so the new shelve ui fixed whatever the issue was [18:23] wacky. [18:23] thanks. [18:23] ah... er... any char will do? [18:24] seems 2.4 defaults to 'n' for any unrecognised imput [18:24] *input [18:25] and I clearly suck at testing given I must have done something wrong when switching to the older branch first time around [19:01] hello, i can't figure out how to specify a merge base revision, when there are no common ancestors [19:01] staring at the bzr merge man page doesn't enlighten me, sadly [19:03] "If this fails, you may need to give an explicit base." [19:03] ok, but how? [19:04] Umm.. /can/ you merge with no common ancestors? [19:04] LeoNerd: one can [19:04] Sounds an unlikely thing to want, or that could possibly work [19:04] Oh.. hrmm.. OK [19:04] achiang: can you provide some more context to what you're trying to do? [19:07] LarstiQ: i wish i could explain [19:07] LarstiQ: https://bugs.launchpad.net/ubuntu/+source/appmenu-gtk/+bug/655241 [19:07] Launchpad bug 655241 in AppMenu GTK+ "the pidgin accounts menus are not displayed" [High,Fix released] [19:07] LarstiQ: at some point, i branched what i *thought* was lp:ubuntu/maverick/appmenu-gtk [19:07] LarstiQ: i made some changes... [19:08] LarstiQ: today, i want to merge lp:~om26er/ubuntu/maverick/appmenu-gtk/appmenu-gtk-fix-655241 [19:08] but i guess my original branch came from somewhere else [19:08] so looking in my bzr log, i see that, e.g., r56 of my copy == r27 of the source [19:09] i don't know how i got in this state [19:10] achiang: can you do bzr log -r 1 --show-ids in both branches? [19:10] anyway, all i really want to do is cherry-pick r28 from source into my dest [19:10] i have been known to do (cd ../other-branch ; bzr diff ) | patch -p0 [19:10] achiang: when I run missing from your branch wrt the maverick one, you have one extra revision [19:10] achiang: so it seems they are perfectly related? [19:11] LarstiQ: ah, no. i am not ~om26er, my branch isn't pushed anywhere [19:11] achiang: ah, ok [19:11] achiang: can you push it somewhere so we can have a look? [19:11] one sec, getting info requested by mwhudson [19:11] sure [19:13] LarstiQ: mwhudson: http://pastebin.ubuntu.com/834324/ [19:13] mwhudson: yeah, i know how to generate a manual patch. i guess i'm yak-shaving to try to learn a bit more about bzr right now. :) [19:13] achiang: aah [19:14] the first one looks like a native bzr branch, the second is from the ubuntu package importer [19:16] so, given that i have confidence the branches are pretty darn close, can i force bzr to merge from the source somehow? [19:16] (again, i know how to generate a manual patch ;) [19:17] achiang: you can with `bzr merge -r 0..-1` [19:18] achiang: but the result is not something that I personally would submit [19:18] why not? [19:18] the file ids will be different too won't they? [19:18] achiang: merging unrelated branches is a hefty thing to do, you have to live with the complete history from both forever on [19:19] so i think you'll have a pretty hard time getting bzr to do something useful [19:19] mwhudson: oh right, conflicts galore [19:19] hummmmm..... [19:20] achiang: so while it is possible, it will not be as clean as supplanting your revision on the other branch [19:20] what does "supplanting your revision" mean? [19:20] * LarstiQ wonders if rebase minds that the branches share no history [19:21] achiang: doing what mwhudson suggested with diff and patch [19:21] achiang: or rebase, or by hand [19:21] achiang: I may have abused the meaning of the English word :) [19:22] LarstiQ: mwhudson: ok, thanks. i think, since my local branch doesn't really contain useful stuff anyway, i will just adopt the source branch wholesale. this probably means a push with a forced overwrite for where i plan on pushing. [19:23] LarstiQ: mwhudson: thanks for the help [19:23] np [19:24] * achiang wonders where mwhudson is. isn't it night time in upside-down-landia? [19:24] achiang: i'm in the bay area with linaro people [19:24] but it's 8:30 or so at home, so i _could_ be up by now [19:24] mwhudson: ah cool! i'll try and say hi tonight. i'm going to crash the computer history museum thingy. :) [19:25] cool [19:25] (and now i realize that's quite overloading the word 'crash') [19:27] LeoNerd: so the trick is that secretly all branches are related through the null revision [19:27] Ahhhh [19:27] achiang: let's hope you won't get kicked out of the us now for that ;) [19:29] LarstiQ: heh. would the us deport its own citizens? i guess i shouldn't speculate. :-/ [19:29] * fullermd carefully steps away from achiang... [19:30] ;) [19:39] hiya, just to make sure: the new multibranch format is compatible with bzr-colo, right? [21:06] LarstiQ: sorry i was away. thanks for the tip using 'bzr merge ...' [21:14] go back one space? [21:15] woah ... sorry had my screen way scrolled up ... no context to that comment. nm. move along now. [21:22] hmm, is it safe to install a newer bzr windows standalone on top of an older one? [21:22] mathrick: probably not a good plan [21:23] so uninstall, then install the new one? [21:23] oh, if it's an actual full installer it's probably fine [21:23] that just sounded suspiciously like "unpack new archive in existing tree" ... [21:25] doesn't it upgrade? [21:25] the windows installer one [21:25] yeah [21:25] pretty sure it does [21:27] some installers (like vlc) just remove the old one [21:27] then reinstall [22:16] i'm trying to merge in a branch i made and push to trunk on a project on lp and getting ... [22:16] Transport operation not possible: readonly transport [22:17] the command was: bzr push lp:~djfroofy/someproject/trunk [22:17] any ideas? [22:18] more specifically ... bzr: ERROR: Cannot lock LockDir(chroot-76185552:///~djfroofy/someproject/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport [22:18] hi [22:19] this means you don't have write access to that branch [22:19] hm [22:19] poolie: odd ... this is a project i created ... yada yada [22:19] if it's your own user id that's a bit strange [22:19] yep [22:19] try 'bzr launchpad-login djfroofy' [22:22] poolie: ok just tried that and: http://paste.pocoo.org/show/548011/ [22:22] interesting [22:22] does that file exist? [22:23] no it doesn't [22:24] "Use ssl.cert_reqs=none to disable certificate verification." [22:25] poolie: do you know if that's something i add to a bzr config file or sth? [22:25] or install ca-certs [22:25] *ca-certificates [22:25] on ubuntu/debian [22:25] or whatever it is on your os [22:25] on mac os x [22:25] yeah ... [22:27] i also do not have that directory [22:29] but launchpad-login (username) works fo rme [22:29] great ... jinxed [22:29] where is bzr looking for ssl certificates? [22:29] or python rather [22:30] when the singularity comes i'll be the first to be wiped out by evil machines [22:30] heh [22:30] AuroraBorealis: so i don't know where it's looking. i'm new to bzr mostly [22:30] AuroraBorealis: you're using a slightly older bzr I guess [22:30] 2.5b6 [22:30] i'm using the latest stable [22:31] not that old... [22:31] djfroofy: the ssl certificate business here is being hammered out for 2.5 [22:31] AuroraBorealis: so the latest stable version is ... ? [22:31] 2.4.2 i think [22:31] AuroraBorealis: awesome. thx. [22:31] vila: ^^ [22:32] i should afaik acutally by logged in to lp. been pushing to branches owned by myself, etc [22:33] djfroofy: what does `bzr info` or `bzr config` say is the push location? [22:34] djfroofy, you can put 'ssl.cert_reqs=none' into ~/.bazaar/bazaar.conf [22:34] * LarstiQ has a feeling the ssl certificate warning may be a red herring [22:35] probably [22:35] i would like to work out if he's connecting by ssh or not [22:36] * LarstiQ nods [22:36] thanks poolie. i'm reinstalling stable version (2.4.2) now and will try some other things if that doesn't work. [22:37] LarstiQ: i'll let you know when i've finished reinstalling [22:37] djfroofy, can you tell me the actual project name, or is it private? [22:37] djfroofy: sure thing [22:38] djfroofy: I will fall asleep at some point, but I can check the logs tomorrow [22:40] the .bzr.log may tel you [22:40] o/ lifeless [22:40] lifeless \o/ [22:42] lifeless: re bug 927581, I understand not wanting to change local path handling now, but initially I had expected bzr to be passing bytestrings to begin with [22:42] Launchpad bug 927581 in Bazaar "pypy raises UnicodeDecoderError on os.listdir(unicode) in a C locale" [Low,Confirmed] https://launchpad.net/bugs/927581 [22:42] * LarstiQ was a bit slow in discovering it was a unicode argument [22:42] LarstiQ: :) no worries [22:42] lifeless: anyway, the point is moot. Pypy has been fixed to behave in the same way, will be in 1.8 which is due out rsn [22:43] so maybe we'll get to a 0 failure run this month [22:43] * LarstiQ babbles [22:44] LarstiQ: no you're not allowed to fall asleep. you must stay up all night until my problem is resolved. [22:45] ah ... good times: 2.5b6 [22:45] woops [22:46] bzr: WARNING: bzrlib version doesn't match the bzr program. [22:46] is what i meant to paste [22:46] sorry for the play-by-play ... i'm reinstalling bzrlib now [22:46] djfroofy, i really don't think going back to 2.4 is necessary [22:46] you can just disable ssl validation and you'll get past that warning [22:48] poolie: yeah ... i'm going to try that ... except now i've already gone back ... sort of. the bzrlib dep mismatch is ugh ... a problem. [22:51] LarstiQ: cool [22:51] djfroofy, how did you install it? [23:04] poolie: pip install bzr==2.4.2 [23:06] poolie: and i'm reinstalling now just the regular ol' way that always works. downloaded the package ... [23:12] when I commit, I'm given a commit message to edit... [23:13] But how do I submit that message? [23:13] the only way I've found so far is to save a message to disk and specify it with -F / --file= [23:14] both the default behavior and -m / --message= leave me hanging and I just end up using Ctrl+C [23:15] poolie: the project name is bafload btw ... sorry i missed that [23:17] bzr commit -m "something" should work [23:18] Jesdisciple, when you interrupt it, there should be a traceback in ~/.bzr.log saying what it was doing [23:19] checking [23:20] in which directory? pwd as of the call to commit? [23:20] I'm not seeing anything unless it's deep within .bzr [23:21] ah woops [23:21] missed the ~ [23:22] poolie: tried everything ... wuh wuh [23:22] (bafload)quaternion:trunk dsmathers$ bzr launchpad-login djfroofy [23:22] (bafload)quaternion:trunk dsmathers$ bzr push [23:22] Using saved push location: bzr+ssh://bazaar.launchpad.net/~djfroofy/bafload/trunk/ [23:22] bzr: ERROR: Cannot lock LockDir(chroot-85139408:///~djfroofy/bafload/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport [23:23] sorry for the spam ... [23:23] np, ok [23:23] oh ok [23:23] it's an import of a bitbucket branch [23:23] that's why you can't push to it [23:24] BzrError: Must end write group before releasing write lock on CHKInventoryRepository('') [23:24] (the single-quotes had a long path) [23:24] poolie: righto [23:24] the idea was to ditch the bitbucket one and just start using lp [23:25] since it related to some other projects on lp, namely txaws [23:25] big dat red herring [23:25] s/dat/fat/ [23:26] djfroofy, ok, i see [23:26] so then i suggest you rename this branch to, say, 'import' [23:26] then you can push your local copy to that url [23:26] and then you'll have made a new writable branch [23:26] sorry the error message is so confusing [23:26] poolie: rename or branch to another branch? [23:26] it is confusing. life is full of confusing error messages. [23:27] i'm suggesting you rename this one, so that the name 'trunk' is freed up [23:27] okay [23:27] also, you might like to make a 'bafload' team to own it [23:27] not just you [23:27] in case you expect more contributors later [23:27] thanks for moving it [23:27] i'm using txaws a bit myself [23:28] poolie: yeah, i'll probably make a team later. thanks. [23:29] i'm more just trying to get versed in lp [23:31] https://bugs.launchpad.net/launchpad/+bug/543797 :-( [23:31] Launchpad bug 543797 in Launchpad itself "poor "readonly transport" message when trying to write to an import branch" [Low,Triaged] [23:31] that's what bit you [23:31] poolie: ok, so i renamed to import, made a branch off this named trunk and then push to that ... or sth. https://code.launchpad.net/bafload [23:32] awesome [23:32] you might like to mark that as the trunk branch in https://launchpad.net/bafload/trunk [23:33] will that all for "bzr branch lp:bafload" for example? [23:33] s/all/allow/ [23:33] yes [23:33] hotness [23:35] poolie: and ... no idea how to "makr that as the trunk branch" after some clicking around [23:36] configure project branch? [23:36] yep ... that did the trick [23:36] poolie: thanks for all your help [23:37]