[00:00] right that makes sense; the behavior i describe above is what's confusing to me [00:00] oh right [00:00] so the reason that happens is this: [00:00] our entire testsuite spits out to stdout [00:00] if i'm not making any silly mistakes [00:00] bzr+ssh invokes bzr on the server by doing 'ssh host bzr' [00:00] sure [00:01] so the bzr on the server, when it writes to stdout, the local bzr gets that on the socket read fd [00:01] right that makes sense [00:01] when something on the server writes to stderr, ssh cpatures that and sends it back to the client, where it goes to the ssh's std err [00:01] which bzr hasn't redirected [00:01] ahh so it must be stderr that is making it through [00:02] so i might be able to exploit that behavior to get my testsuite output shown to the user? :) [00:03] phinze: yes, as long as you don't start serving bzr+hhtp ;) [00:03] so basically add 2>&1 on the end of my commands and i'm right as rain [00:04] err [00:04] other way around [00:05] hah, beautiful [00:05] phinze: I'm going to file a bug to capture this requirement [00:05] lifeless: you've been incredibly helpful, great explanations [00:06] its one we deferred in getting streaming up [00:06] and it would be lovely to have some sort of answer for bzr+http [00:06] phinze: anytime [00:06] yeah an official way of handling this would be better [00:07] awesome; based off james_w's code i now have a 30 line "poor man's PQM" [00:08] phinze: perhaps the plugin should do that [00:08] james_w: where 'that' == the output redirection? [00:09] yeah [00:10] well it doesn't look like subprocess.Popen has a clear way of doing that [00:10] can't just set stdout=subprocess.STDERR (STDERR not defined) [00:11] stdout can be set to an int though [00:11] bazaar is down ? [00:11] elif isinstance(stderr, int): errwrite = msvcrt.get_osfhandle(stderr) [00:12] can download ? bzr branch lp:wiithon i have timeout [00:14] makiolo: i branched that with no problems [00:14] ok ... [00:14] thx [00:14] sure [00:16] james_w: this works, but there must be a cleaner way? subprocess.call(command, cwd=export_dir, shell=True, stdout=2) [00:16] phinze: you can set stdout=suprocess.STDIN though [00:16] err [00:16] nonsense [00:16] you can set stderr=subprocess.STDOUT [00:16] which is what we want isn't it? [00:17] oh, no, I see now [00:17] james_w: no, re above discussion w/ lifeless... stdout is interpreted as server communication, but stderr makes it all the way through [00:17] james_w: there isn't a way to send the data via bzr+ssh atm [00:17] phinze: [00:18] so stdout=STDERR is what i want... but is STDERR=2 set somewhere in python for me to reference? [00:18] so we want to write nothing on stdout? [00:18] and everything on stdin [00:18] as everything is working beautifully now with stdout=2... test suite runs; i see output; and if it passes, my push is accepted [00:18] that's possible, but it's a pain [00:18] s/stdin/sterr yes [00:19] sigh: STDERR [00:19] err, yeah, I don't know what's wrong with me tonight :-) [00:19] typing plague [00:19] redirect stderr -> stdout by calling with stderr=subprocess.STDOUT [00:19] so that both streams are interleaved as you want [00:19] then capture stdout [00:20] with stdout=subprocess.PIPE [00:20] right, but stdout is not sent across the wire currently; bzr+ssh offers no way of getting it though [00:20] so that stdout isn't sent and you don't get the failure [00:20] yeah i tried that but then i get no output on the terminal [00:20] then manually output stdout on stderr [00:20] i have no way of accessing subprocess.PIPE from my remote bzr client... so i get no output [00:21] by reading from proc.stdout and using "info" on each line [00:21] well then it would be all in one chunk wouldn't it? [00:21] or "warning" perhaps [00:21] both from bzrlib.trace [00:21] nope, you can read per-line [00:21] i like how it's working now because as the testsuite runs i see the output [00:21] for line in subprocess.stdout: [00:21] trace.warning(line) [00:21] but i have to wait for subprocess.call to complete [00:21] retcode = subprocess.wait() [00:22] the other way would be to redirect both to a pipe, and then select on the two filehandles, and "info" the stdout, and "warning" the stderr, so that "commit -q" suppresses the normal output [00:23] ahh then use subprocess.Popen() rather than subprocess.call() ..? [00:23] your stdout=2 might be a simple way to do it, but I don't know if that would work on windows [00:23] yeah Popen [00:23] perhaps sys.stderr would be more robust than "2" [00:23] yeah you're thinking in terms of doing it the right way rather than my hacking things together :) [00:24] will sys.stderr be coerced into an integer? === ja1 is now known as jam [00:25] suppose i can check [00:25] yes, yes it will [00:26] phinze: sys.stderr.fileno() if you need it [00:26] But Popen() already knows about fileno() for file objects [00:26] hi jam [00:26] hi james_w [00:27] jam look what james_w gifted me: http://paste.ubuntu.com/155612/ [00:28] phinze: poor mans PQM, looks good [00:29] we're just cleaning up the input redirection [00:29] works with no redirection on local machine, but over bzr+ssh stdout of testsuite iinterpreted as smart server output over wire and barfs [00:30] can take advantage of the fact that stderr makes it all the way through because of ssh [00:30] james_w: info on the server won't do the right thing [00:30] oh, of course not [00:30] I thought there was a way to suppress stdin, etc [00:30] but I don't see it specifically [00:32] phinze: well, stdout *is* being redirected via ssh [00:32] it just happens that we listed to the ssh stdout locally as bzr+ssh return values :) [00:32] and don't directly listen to stderr [00:32] exactly, so it's a bit of a hack that pushing output through stderr happens to work :() [00:32] using stderr today is your best bet [00:32] I've filed a bug to enhance things to improve on that [00:33] lifeless: can you link? [00:33] phinze: I would say that you could use 'close_fds' to force stdin to be closed [00:33] however, that raises exceptions on windows (if you care) [00:33] jam: why do i care about stdin in this case? [00:34] phinze: I would set it to "/dev/null" so that anything that wants input aborts immediately [00:34] rather than hanging indefinitely [00:34] I also see stuff like: http://paste.ubuntu.com/155618/ [00:35] so you may not really care about windows [00:35] ahh gotchya, because we're executing an arbitrarily specified command [00:37] * phinze indeed does not care about windows... but wouldn't mind supporting them if it's easy :) [00:37] jam: stdin=PIPE; process.stdin.close() is better [00:37] lifeless: sure [00:37] I thought there was a way to do 'stdin=NULL' [00:37] but I think stdin.close() is the best you can get [00:38] phinze: for your case, it would mean using Popen() rather than .call() [00:38] the other odd thing [00:38] you can pass "stderr=subprocess.STDOUT" [00:39] but there doesn't seem to be a "stdout=subprocess.STDERR" [00:39] weird [00:39] yeah i know isn't it? [00:39] as that is probably what you would want over sys.stderr [00:39] yeah i went down that same path [00:39] jam: was my index building thoughts mail useful to you? [00:40] lifeless: so I'm not sure that it is N log N, I have the feeling it is N*C where C is the number of entries in a single page [00:41] I did like the info about how many keys we read, etc. [00:41] as for checking 'late' [00:41] I think we need to check as we go in at least the local dict [00:42] and then we could check during the recombine step [00:42] we currently check the local dict [00:42] lifeless: right, we currently check both the local dict and the spilled [00:42] jam: actually we don't [00:42] jam: add_node checks self._keys, not the spilled indices [00:43] jam: its definitely superlinear, N*C would be linear with a high constant [00:43] lifeless: _insert_record_stream calls add_records() which calls _get_entries(keys) [00:43] which goes through iter_entries(keys) [00:43] I am quite sure its NlogN with a large down-scale factor [00:43] Which *definitely* checks everything [00:43] jam: better? http://paste.ubuntu.com/155622/ [00:44] jam: yes, thats in how we use the index though, I'm talking specifically about the contract the index offers [00:44] phinze: looks good to me [00:44] jam: I think it would be ok if it *either* errors in add_node on dupes, *or* errors in finish on dupes [00:44] jam: danke :) [00:45] jam: erroring *sometimes* in add_node and *sometimes* in finish, depending on whether the dupe has been paged out would be odd to work with and surprising for users of the index layer [00:45] well, if you wanted to error always during finish [00:46] you would have to check during add, and queue it for a later error [00:46] since otherwise you are just doing dict[key] = value [00:46] and it just overwrites the previous value [00:50] jam: thats true. Ok, scratch that, erroring in both add_node and finish, depending on when the collision is found [00:52] jelmer: thanks for the help, btw [00:53] thanks all [01:00] * SamB wishes someone would bother to vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/ -- it just adds a sentence to an error message! [01:10] jelmer: sorry that I pinged you and then dropped off the face of the earth. I've been debugging a kernel panic all day :p [01:10] jfroy: on real hardware? [01:11] SamB: yeah, graphics drivers [01:11] (my day job, etc. etc.) [01:11] not fun :-( [01:11] loads of fun :p [01:11] well ... I don't find it fun to have to debug stuff like that running on real hardware ... [01:11] Eh, it's OK with 2 computers [01:11] maybe if you have an ICE [01:12] or, okay, a kernel debugger [01:12] yeah, using our kernel debugging facilities [01:12] I haven't been able to resurrect a kernel yet though :p [01:12] It's a feat only the masters know the secrets of :p [01:18] I can't even do that for DOS [01:18] DOS can't even do it for DOS :p [01:18] (not that it's worth bothering ;-) [01:18] (rebooting gives better results anyway ;-) [01:19] * SamB wonders if there are any kernel debuggers of the sort jfroy uses for DOS ... [01:21] You don't need a kernel debugger for DOS. It's, what, like 20 lines of code? You find bugs by inspection. [01:21] fullermd: you can get a lot in 20 lines of forth :) [01:21] fullermd: er, not the one I looked at! [01:22] of course, that one was written in C [01:22] Well, maybe later versions are longer, after they added all those decadent extra features like directories... [01:22] jam: is phinx @ the drizzle con? [01:23] fullermd: what's the point of using a DOS if it doesn't give you directories ... okay, sure, I suppose file names are nice ... [01:23] Well, that was sorta my meta-point ;) [01:23] but really, I have never in my life used DOS 1! [01:23] original disks were too small to bother with directories [01:23] waste of disk space [01:24] * SamB is still bothered by the fixed-size root dir in FAT [01:25] Yeah. Only so much room in 360k to put stuff. Heck, I've got directories bigger than that now... [01:28] fullermd: you mean just the directory entries occupy more space than that, I assume ? [01:31] I've got a 1,024,000k directory entry from when a program spammed my /tmp dir. :D [01:32] Err, byte, not kilobyte, I suppose. :P [01:33] jelmer: shouldnsvn-set-revprops [01:33] er. [01:33] jelmer: shouldn't svn-set-revprops be in "bzr help svn"? [01:55] SamB: Only FAT1[26] have a fixed root dir size. [02:02] wgrant: okay, sure. I was reading a book that didn't talk about any version of DOS more recent than 3.x, so ... [02:03] SamB: Ah, that could do it. [02:56] spiv: I'm still futzing around with refactoring the start of push [02:56] its rather unsatisfying [04:54] so i just pushed from a branch right into our trunk, instead of merging my branch and then pushing [04:55] is there a way i can revert this? [04:55] jelmer: I just had a thought. [04:55] I am fairly certain I did an uncommit on the branch I am having trouble with. [04:56] Could it be the root cause of the missing revision problem? [04:59] lamalex: Find the rev that should be its head, and use push or pull to set it. [05:00] fullermd: can you give me example syntax? [05:01] lamalex: "cd $TRUNK ; bzr pull --overwrite -r$OLD_HEAD ." or "cd mybranch ; bzr push --overwrite -r$OLD_HEAD $TRUNK" [05:02] Then set append_revisions_only in the $TRUNK/.bzr/branch/branch.conf to guardrail it a bit in the future 8-} [05:03] :) [05:06] fullermd: thank you! [07:01] later folks === thekorn_ is now known as thekorn [07:59] lifeless made a funny on the mailing list :-) [07:59] I did? [08:00] response to my final vs rc3 [08:00] I don't think additional testing will make this bug more severe. :) [08:00] right [08:00] 2am that's funny to me for some reason [08:00] :) [08:00] ;-P [08:00] it was ironic I guess [08:57] jfroy: it shouldn't but I guess it could [08:58] jfroy: did you push the original branch (from before the uncommit) anywhere? === thekorn_ is now known as thekorn [09:12] jelmer: urg sorry, just noticed your messages [09:13] I don't remember if I pushed the branch to svn before doing the uncommit or after [09:17] jfroy: so you didn't use anything like --overwrite when pushing? [09:17] I don't believe so. [09:41] jelmer: so in any case, if you need data to figure it out, just let me know. [09:43] jfroy: Ok [09:51] HOLAS [09:52] ALGUIEN ME HECHA UNA MANO [09:52] NO PUEDO ENTRAR EN NINGUN CHAT CASI, OPERA ME DICE QUE AHY UN ERROR CON UN DDL [09:52] FIREFOX NO LOS CARGA [09:52] GOOGLE CRHOME O COMO SEA VALE CALLAMPA [09:53] Y EXPLORER ME SACA, DICE ID NO VALIDA [09:53] are you for real? [10:05] jelmer: no, the bzr-svn at the time I filed the bug, with recent improvements I hope it is all fixed now, but I'll let you know when I try again [10:46] LarstiQ: I suspect so [10:54] Furrfu. Remember those wonderful days when everybody's on vacation and the list is silent? [10:55] fullermd: I can't keep track anymore, at 1910 unread now :/ [10:56] However did we survive without 30 rounds of "No, see, it does XYZ." "You're wrong, it does exactly what you said." "Yes, that's my point, it does what I said." "No, you're blowing FUD, it does exactly what you said." [..........] [10:57] Hi all! What is the good way to handle this? make a modifications m1 and commit then a modification m2 and commit in branch B. How to push only modifications m2 on a branch A? [10:57] I already made the error not making an m2 branch [10:58] In a strict sense, you can't. The nearest you can do is cherrypick it over with merge. There's no ancestral link behind that, though. [10:58] so bad! Thanks fullermd [10:59] or well, rebase [10:59] Or use a loom. That's just like rebase, right? [10:59] fullermd: tsk :P [10:59] * LarstiQ read part of that thread yesterday [11:00] Did you read at least 2 mails of it? [11:00] yes [11:00] You pretty much read the whole thing then. [11:01] ok I'll look for that, thanks [11:01] yogsototh: Cherrypicking with merge is almost certainly what you want. In this case, rebase is probably just a really roundable way of doing exactly that. [11:03] I see, I can also play with bzr diff and bzr patch I suppose. Thanks [11:04] That'll end up in the same place as the cherrypick. Using merge will be a bit simpler. [11:04] Yep === sabdfl2 is now known as sabdfl === thekorn_ is now known as thekorn [13:57] guys.. I am trying to push to an svn repo , and I am getting a traceback [13:57] http://ricardokirkner.pastebin.com/d61d26395 [13:58] can anyone help me figure out why this is happening? [14:01] jelmer: ^ this one is for you [14:01] jelmer: do you highlight on 'svn' yet? [14:11] how do I display the revid for a given revision? bzr log --verbose doesn't show it. I'm using bzr 1.13 [14:13] lifeless: I think he stopped [14:13] ricardokirkner: are the bzr branch and svn repo public btw? [14:14] LarstiQ, no, sorry... they are internal to our company [14:14] ricardokirkner: k [14:14] if you need any info, tell me and I will provide it if I can [14:14] ricardokirkner: just enough to reproduce it :) [14:15] ricardokirkner: are there merged revisions in what you are trying to push? [14:15] ricardokirkner: what does bzr think the revno for the local bzr branch and what is in svn are? [14:16] LarstiQ, yes, there are merged revisions in there [14:16] ricardokirkner: one sec [14:16] ricardokirkner: please file a bug [14:16] jelmer, alright... [14:18] jelmer, bug on bzr, or bzr-svn? [14:18] ricardokirkner: bzr-svn [14:18] ricardokirkner: actually [14:18] right [14:18] ricardokirkner: this is fixed in a recent version of bzr-svn [14:19] jelmer, the thing is 0.5.3 (what I am using) is the latest version compatible with bzr 1.13 (the latest release version of bzr) [14:19] for 0.6 I need 1.14 [14:19] which is rc [14:19] should I post the bug anyway? [14:19] ricardokirkner: 0.5.4 is for 1.14 [14:22] jelmer, so, in order to avoid this issue I have to use bzr 1.14? [14:23] ricardokirkner: Yes, it looks similar to a bug I fixed for 0.5.4 [14:24] sohmestra: log --show-ids [14:24] lifeless: thanks [14:24] mhhh... I'll try to test it using 1.14 [14:24] and let you know [14:24] thx [14:28] lifeless: no, I don't do svn highlights, it would be annoying for #svn-dev :-) [14:37] ricardokirkner: I'd like to know if that fixes it for you too, it looks similar to something I have trouble reproducing but my colleagues run into from time to time. [14:37] so can bzr-email be used in a hook on a shared branch or is it only for client-based hooking [14:37] * phinze knows about bzr-hookless-email as well but is evaluating the options [14:38] phinze: afaik, bzr-email will be used on a remote branch regardeless of client installs _if_ you are using the smartserver and have email configured for that branch [14:38] phinze: but not if people use transports like sftp:// [14:39] LarstiQ: cool; my group uses bzr+ssh so i think we should be good if i install it systemwide on the shared server then [14:39] LarstiQ, as soon as I finish testing I let you know [14:39] ricardokirkner: thanks [14:39] phinze: I admit to not knowing exactly how to configure it [14:40] phinze: but branch.conf I'd think [14:41] LarstiQ: yeah that's my guess... i'll try it out [14:41] james_w: ping [14:42] hi phinze [14:43] hey, you interested in throwing bzr-testrunner out to the world? [14:43] sure [14:43] i'm not well versed in lp-fu, but i assume it wouldn't be too difficult? [14:43] maybe it should have a better name first though? [14:43] yeah, it's easy to set up a project for it [14:44] yeah i'm at a loss for names [14:45] bzr-sentinel, bzr-branchguard, bzr-guardian [14:45] thinking something more generic to imply that testsuite is not required but any command? [14:45] jelmer, LarstiQ no luck. I tried with 1.14rc2 and bzr-svn 0.5.4 and 0.6 [14:45] and neither solves the push issue [14:45] ricardokirkner: please file a bug [14:45] I do that now [14:46] ricardokirkner: thanks [14:46] bzr-canary [14:47] also, I'm not sure if the shell-hooks plugin makes it unnecessary [14:49] phinze: have you put it in a branch? [14:58] jelmer, the bug is https://bugs.launchpad.net/bzr-svn/+bug/365108 [14:58] Launchpad bug 365108 in bzr-svn "AssertionError on push" [Undecided,New] [14:58] thanks for the support [15:02] why does switching branches and switching back crap all over my working tree? [15:03] http://rafb.net/p/tUZ9c479.html [15:03] maybe because the branch is old :( [15:04] and now that I switched back I have all these conflicts, http://rafb.net/p/bfiY8c60.html [15:09] james_w: just locally... latest version is http://paste.ubuntu.com/155933/ [15:09] phinze: cool, thanks [15:09] phinze: bzr-testrunner seems to be the best name to me, what do you think? [15:10] yeah straightforward [15:10] * phinze looks at shell-hooks quickly [15:12] probably still useful to save every script having to implement the "checkout the tree" bit [15:12] and the redirection [15:13] yeah plus shell-hooks sends a bunch of arguments along [15:13] yeah i think it's still worthwhile to throw out there [15:16] phinze: https://launchpad.net/bzr-testrunner [15:16] please push your branch to lp:~bzr/bzr-testrunner/trunk [15:20] james_w: will do [15:26] hello [15:26] i am trying to merge from a diverged branch, how can i see the uncommited changes i had before the merge? [15:27] ricardokirkner: do you have a way to reproduce this bug? [15:33] james_w: Paul Hinze is not a member of Bazaar Developers... [15:35] james_w: looking into https://launchpad.net/~bzr/+mentoring ... ~= "fix a bug to join the club"? [15:36] a new team for this plugin seems like overkill [15:37] i would hope to contribute enough to be considered for Bazaar Developers membership... but i have not yet [15:37] I could push the branch up, then merge your changes as needed until you are a member [15:37] how would that suit you? [15:40] james_w: works for me... lp:~phinze/+junk/bzr-testrunner [15:54] a new team is fine [15:54] teams are cheap [15:54] and its appropriate if phinze is maintainer [15:55] names wise, I'd suggest bzr-testoncommit or something [15:55] testrunner is ok, but perhaps it can be improved [15:55] *night all* [15:55] night [15:55] and it's not just commits [15:55] phinze: oh the bug number - Ididn't have that before, just look at bzr's new bugs [15:56] james_w: I know that [16:03] jelmer, sort of... I don't know when this was first introduced, but since then, (almost) every push crashes [16:03] jelmer, I think at some point I merged changes from two different branches and then tried to push them to the svn repo [16:04] and after that the problems started, but I am not entirely sure about that [16:13] ricardokirkner: is it a public branch? [16:14] jelmer no... sorry .. it's customer private code [16:14] if I can run the tests you need, just tell me [16:14] and I tell you back the results === ja1 is now known as jam [16:37] phinze: pushed as lp:bzr-testrunner. It should be added to http://bazaar-vcs.org/BzrPlugins as well so that people can find it [16:37] do you want to do that? [16:37] james_w: awesome, thanks... yeah i can add it [16:37] cool, thanks [16:40] james_w: did you want to try and mess with a group as suggested by lifeless? or just let me bother you with merge requests :) [16:41] I don't mind you bothering me, but we can set up a group if you want to be recognised as an author [16:46] https://launchpad.net/%7Ebzr-testrunner <-- james_w [16:48] thanks [16:48] all changed [16:48] you should have full access now [16:49] beautiful, ty [16:58] * SamB_irssi wonders what he should do with his debugger branch in the DOSEMU svn repository now that he's merged it back to trunk with bzr-svn [16:59] I want to make more debugger changes ... should I pull in trunk and make more, or delete and make a new branch, or what? [17:01] disregarding svn backing, I'd pull trunk to debugger and then continue there [17:01] * SamB_irssi wonders if he should disregard svn backing === sabdfl2 is now known as sabdfl [17:06] is there an unmerge? [17:06] * SamB_irssi wonders why sf.net isn't allowing svn:mergeinfo [17:07] Kobaz: what would that do? [17:07] LarstiQ: undo the merge that was just done [17:07] Kobaz: bzr revert? [17:08] what about the merge did you want to undo? [17:08] the whole thing? [17:08] evening bialix [17:08] jam: are you here? [17:08] heyo LarstiQ [17:09] LarstiQ: how are you? [17:10] does anybody knows about new dependency in 1.14: pylzma. I assume it's optional. Is it correct? [17:11] bialix: mistakenly thought it was no longer cold weather with the sun, and thus caught a cold [17:11] * LarstiQ could be better [17:11] bialix: how about you? [17:11] ah [17:12] too much work. and my daughter going to the school this year, I have to help her [17:14] do you know when the jam appears here usually this week? [17:19] lifeless: hi. now that gnome moved to git, is there any bzr-git in sight? [17:19] https://launchpad.net/bzr-git [17:20] bialix: ah, primary school? [17:20] * LarstiQ would expect jam awake by now [17:20] bialix: I expect pylzma is optional too [17:20] how good does that work? [17:21] asac: not as good as bzr-svn, but better than bzr-hg [17:22] LarstiQ: yes, primary school [17:23] bialix: cool, I imagine that's very exiting for her? [17:23] LarstiQ: hmm. guess i will have to try ... thanks [17:23] LarstiQ: the school today seems much complex than in my time. sometimes I think it's much harder to get to the school than to University [17:23] bialix: woha. How much complexity can there be in primary schooling? [17:23] apparently more than I think [17:24]