[00:00] igc: I think it's very much worth fixing, because it regularly trips up bzr users, no matter how experienced they are. [00:01] jml: do we have logs showing how often users are pushing pack-0.92 branches vs 0.9 branches? [00:01] hahaha [00:01] no. [00:01] jml: do you think it's related to trying to stack on the far end? [00:02] igc: I don't know. What I do know is that stacking isn't behaving as I'm told it should. [00:02] jml: if this is the performance users are seeing out-of-the-box, it's scary. [00:02] igc: if they use old formats, that's what they see when pushing to LP. [00:02] igc: incidentally, do you have -Dhpss enabled? [00:02] jml: just added 'debug_flags=hpss' to bazaar.conf now [00:03] igc: cool. it's worth having for situations like this. [00:03] poolie: were you planning to make 1.9 the default early in the 1.14 release cycle? [00:03] i'd ilke to [00:03] poolie: or did jelmer still have issues we need to sort first? [00:04] it may be getting a bit close to 2.0 but we should still do it [00:04] that branch still doesn't pass [00:04] i think i understand what to do but i haven't done it yet [00:04] igc: I'd very much appreciate if you could take the time to file a good bug about this. [00:06] hmm. or I can "upgrade" to pack-0.92 and do it myself. [00:06] igc: it hasn't stacked. I was sure we had this fixed - what bzr are you using [00:08] lifeless: bzr.dev r4163 [00:09] ok [00:09] buggering a file [00:09] igc: whats your local branch format [00:13] igc: can you do bzr info -v on the branch you pushed from please [00:13] igc: I want the branch format line [00:14] lifeless: I *think* I'm reproducing the bug w/ bzr.dev r4164, pack-0.92 repo, branch7 format. getting lots of hpss calls like http://paste.ubuntu.com/133325/ [00:14] jml: lp will do lots of hpss calls full stop [00:14] lifeless: bzr info -v output http://paste.ubuntu.com/133326/ [00:15] lifeless: it doesn't normally take five minutes to push up a stacked branch that is identical to the stacked-on branch. [00:15] so my guess is [00:15] lifeless: but I can wait an hour or so and see if this is really the same behaviour [00:15] a stackable source branch [00:15] shortcutting the check for can-stack [00:16] when actually it can't [00:16] and thus we don't upgrade-on-the-fly [00:16] sounds plausible. [00:16] no jml, thats enough to go on I think [00:17] lifeless: if I file a bug, what should I put in it? (or do you want to file it instead?) [00:17] I've filed [00:18] lifeless: thanks. I'll look out for it. [00:20] spiv: how did you go assessing alternatives for 'I'm in a gaol' [00:23] lifeless: I'm pretty happy with adding an ignore_fallbacks param to open_branch et al. But we have a problem with the cloning_metadir RPC, which currently *depends* on following a branch reference to determine the repo format, and the client depends on server to tell it the repo format. [00:24] spiv: oh, ugh. [00:24] I think branch references on servers are fugly [00:25] so I propose that on a server we do something different; e.g. return the current default [00:25] So there's no way to have the gaol and preserve the behaviour of the cloning_metadir RPC. I think probably we should add a new RPC, and make the old one just guess at the default format for branch refs. 1.13 clients might be confused sometimes, everyone else should be ok. [00:25] Hmm, we don't even need a new RPC, really. [00:25] no, we don't :) [00:26] We can just make the 1.14 client ask the referenced branch for the source format and ignore whatever the first server reckoned. [00:26] spiv: I was proposing that we just behave differently [00:27] oh btw [00:27] It sounds like we're agreeing? [00:28] if you want to change the ignore_fallback parameter to some kind of callback [00:28] i will buy you alcohol [00:28] mwhudson: oh? [00:28] spiv: broadly; I think you're saying the client can get the old behaviour by working differently, I'm saying the old behaviour is simply undesirable with servers in the loop [00:28] it would let me stop using the transform_fallback_location hook, which is basically a bad idea [00:28] spiv: and we should just change it [00:29] mwhudson: you use it to get a properly loaded branch, yes? [00:29] lifeless: yes [00:29] mwhudson: AFAICT you'll still need it [00:29] mwhudson: not in the server process, but in the scanner etc [00:29] well, if this ignore_fallback parameter became a callback that allowed me to open a different branch instead (or no branch, your use case) [00:29] then i wouldn't [00:30] we'd just say open('...', fallback_hook=) [00:30] lifeless: it's only the puller that really really needs it [00:30] mwhudson: how is that better for you that the transform hook [00:30] *than* [00:30] lifeless: i don't have to worry about uninstalling it [00:31] mwhudson: why would you worry about that? [00:31] * mwhudson pages in furiously [00:31] mwhudson: last I heard you uninstall it in your test suite which isn't needed as TestCase in bzrlib does that [00:33] lifeless: one of the awkwardnesses is that the 'hook' wants to have state per my invocation of branch.open [00:33] lifeless: i can make the hook work [00:33] lifeless: but it's not natural [00:33] mwhudson: perhaps it should be given the branch url too? [00:33] well it is, in effect [00:34] (it gets the passed half-open branch) [00:34] mwhudson: the thing is, Branch.open is Branch.open_containing which is bzrdir.open_branch which is WorkingTree.open_containing which is ... [00:34] lifeless: i know [00:35] I'm not happy about adding a parameter to it as it is (this is what spiv and I disagreed on yesterday) [00:35] i'll let you fight it out then :) [00:35] I'd really rather not have to scatter lambda:None around to use it [00:37] yeah, i can see that [00:37] also I think there is a difference between [00:38] 'globally, I'm running in a funky space', and 'right here I do not want to open it' [00:38] specifically, [00:38] the first case is servers, the puller, etc [00:38] the second is reading data from an unupgraded stacked branch [00:38] which requires a heck of a lot of other work done anyhow [00:42] lifeless: branch: Branch format 6 [00:44] thanks [00:53] jelmer: yeah? [00:58] Did bzr and bzrtools make it to the ppa without bzr-svn, or is something wrong with my package configuration? [00:59] * SamB wishes the PPAs could do Debian packages too ... [01:10] glyph: I didn't get a chance let me sort that out now. I though jelmer might do it as he has done in the past [01:21] johnf: Thanks. Just wanted to know if it was everybody's system or just mine :) [01:29] SamB: never mind, I misread 345067 [01:29] SamB: bug 345067 I mean [01:29] Launchpad bug 345067 in bzr-svn "bzr-svn doesn't relay messages from subvertpy ImportErrors" [Undecided,Fix released] https://launchpad.net/bugs/345067 [01:30] jelmer: I still haven't figured out what the REAL problem is [01:30] SamB: well, did you actually build subvertpy? [01:32] yeah [01:32] the .so is there === timchen1` is now known as nasloc__ [01:37] can't seem to find libneon [01:38] SamB: please try the latest subvertpy [01:38] SamB: it should give a clearer error message [01:39] oh [01:39] huh [01:39] I just tried running SVN ... [01:39] guess what! [01:39] it can't find libneon on this box either ... [01:39] fail? [01:40] one day I'll find time to implement WebDAV+DeltaV in Python [01:41] (actually, I typed "svn pull" by mistake when I was trying to pull subvertpy ;-) [01:41] damn you, slackware, and your lack of dependencies! [01:48] jml: bug 345169 [01:48] Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169 [01:49] lifeless: thanks. [01:55] jelmer: Hi jelmer, thumper has just directed me to you with a request [01:55] jelmer: just filed this: https://bugs.launchpad.net/bzr/+bug/345198 [01:55] Ubuntu bug 345198 in bzr "error trying to "bzr push" to an SVN repository" [Undecided,New] [01:56] pohutukawa: jelmer was active 15 min ago but is in europe [01:56] pohutukawa: hi [01:56] thumper: thx. Bad time for someone in EU to be alive/awake [01:56] it's also the last version of bzr-svn [01:56] jelmer: oh, you are. late worker ... [01:57] pohutukawa: fortunately for us, jelmer is insane [01:57] :) [01:57] hey [01:57] where'd we be without insane people? [01:57] has anyone hooked up emacs rgrep or similar to bzr ls [01:58] mwhudson: I prefer saying I'm a student :-) [01:58] pohutukawa: 0.4.13 is quite old [01:58] jelmer: ok, i'll remember that for next time :) [01:58] jml: you can just say [01:58] M-x grep [01:58] and type bzr ls --versioned --null | xargs -0 grep -ne whatever [01:59] jml: but it's not superduper convenient [01:59] mwhudson: that simple, eh? [01:59] yeah [01:59] jelmer: hmmm, OK. It's the one in Intrepid ... and it used to work until yesterday or the day before that ... [01:59] mwhudson: I'd like an interface similar to rgrep [01:59] I guess it's not that hard to knock up in elisp [02:00] jelmer: what's the preferred way to upgrade it in this case? [02:00] jml: M-x customize-variable grep-find-template [02:00] (!) [02:00] always have a bit of a bad feeling when circumventing the package management ... [02:02] pohutukawa: You'd have to upgrade bzr itself as well when upgrading bzr-svn [02:02] pohutukawa: the bzr PPA has the latest bzr-svn built for intrepid fwiw [02:02] :-/ [02:02] pohutukawa: anyway, the problem seems to be in the tags, did you change any recently/ [02:02] ah, if there's a PPA, that sounds a lot more promising towards succeeding without a domino effect of upgrade dependencies [02:02] ? [02:03] jelmer: what tags? [02:03] I didn't add tags recently, neither in bzr, nor in svn [02:04] but maybe someone else did. let's see [02:04] pohutukawa: for upgrading, see the UPGRADING file included with bzr-svn [02:04] you may also find the "bzr svn-upgrade" command useful [02:06] jelmer: bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): Version (0, 3, 0, 'final', 0) present, at least (0, 4) required [02:06] pohutukawa: yeah, you need at least 0.4.4 [02:06] it might not be in the PPA [02:06] looking at it, I haven't even checked out tags from SVN to the bzr branch [02:07] just the trunk [02:07] so it can't be SVN tags [02:07] and I haven't (knowingly) added bzr tags [02:07] pohutukawa: try running "bzr tags" in your bzr branch [02:07] it will import tags from svn [02:08] got 8 lines with names followed by a column of "?" [02:09] most of these lines correspond with directories within the repo, but one is a tag from "way back" when I used SVN directly, and not through bzr [02:10] pohutukawa: so one of the workarounds you can try is removing all tags in your local bzr branch [02:10] and then pulling from the remote branch again [02:10] and then pushing [02:12] OK, first of all getting new bzr stuff from PPA for intrepid [02:12] incl. bzr-svn 0.5.3 [02:14] jelmer: OK, with the new bzr the push worked, but ... [02:14] ... it tells me about "Conflicting tags" [02:14] which is a first good step. Now "cleanup" some tag mess [02:19] * jelmer gets some sleep [02:19] jelmer: thanx for the help! everything seems clean now [02:19] pohutukawa: push works again? [02:19] don't even know where those tags came from, to be hones [02:19] yes [02:19] great [02:20] pohutukawa: they should match the directories in tags/ [02:20] jelmer: thx, and have a good night. Bedankt!!! [02:20] in the svn repo [02:20] hmmm, OK [02:20] how would I get those down now? [02:20] pohutukawa: why is it that all newzealanders seem to speak a few words of Dutch? :-) [02:20] 'Cause I'm German ;-) [02:20] pohutukawa: bzr pull from the svn branch should import them [02:20] and been to the netherlands quite often for playing Honkball and SCUBA diving [02:21] ahh [02:21] did a bzr pull, and they're back. Hpe they're consistent now [02:21] jelmer: good night, then. [02:22] gnight [03:01] spiv: I don't think Remote*Format should have a network_name, but I can't remember if I added them or you did :P [03:04] Kobaz: pong? [03:18] jelmer: you also aren't propagating import error messages from the import of sqlite3 ... assuming that you try to import it [03:19] igc, hi [03:20] what on earth is that push doing that it's taking so long? [03:20] poolie: its not stacking [03:20] bug 345169 [03:20] Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169 [03:21] oh ok [03:22] I have a fix, running the full test suite now [03:27] poolie: it's still going btw - up to 73M at a leisurely 1-2 kB/s [03:27] lifeless: well done and thank-you [03:30] * SamB notes down the software he's noticed missing so far so he can tell the sysadmin about it ... [04:04] lifeless: are the development2 formats now obsoleted by 1.9? [04:10] poolie: we don't have a development format thats newer than 1.9 in trunk at the moment, but I figured it was better to keep them and the alias live until we do have a newer one. [04:14] lol its so easy to trigger the lp bug on notifications [04:14] of the connection staying open [04:16] http://people.ubuntu.com/~robertc/LP%20Notification%20bug-Bazaar.png [04:16] I can see ajax making this worse :P [04:16] or better [04:16] depending [04:17] spiv: hola, we should coordinate [04:29] lifeless: there used to be a real solution for that, but people complained about the URLs being ugly [04:41] possibly having ugly urls is better than looking like you don't know what's happening [04:41] esp if there's a 'close' button that strips off the notification bits [05:01] Bug#345232 help? [05:01] #345232 [05:02] uncharted territory for me I don't know where to start, when PQM fails to merge [05:06] jamesh: I know [05:06] bug 345232 [05:06] Launchpad bug 345232 in bzr "1.13.1 regression: PQM failure to merge" [High,In progress] https://launchpad.net/bugs/345232 [05:06] BasicOSX: i answered it [05:06] jamesh: I was there :P [05:06] it's an easy fix [05:06] ok [05:07] hth [05:07] ping me if it doesn't [05:07] but i'm going out to the shops for a bit first [05:10] I guess I need to update the releasing doc? I do not see anything about changing _script_version in bzr [05:11] i think it's in there but if it's unclear please fix it [05:12] BasicOSX: _script_version only needs the major version [05:13] BasicOSX: oh, I'm wrong [05:13] uhm [05:13] BasicOSX: it does need changing :( [05:13] np, I stumble you catch me, it's ok :-) [05:16] BasicOSX: thank you for doing this [05:16] rm is non trivial [05:16] heh, I was going to thank you guys for being patient and helpful [05:35] lifeless: is there a bug about the notifications with examples on reproducability? [05:39] lifeless: re bug 330494, i propose to just remove the options [05:39] Launchpad bug 330494 in bzr "Remove list of formats from bzr init and bzr init-repo" [Medium,Confirmed] https://launchpad.net/bugs/330494 [05:39] and tell people to use --format 1.9 [05:39] and then, for the --format parameter, say see `help formats' [05:57] thumper: notifications? [05:58] poolie: well, I'm not against that per se, but as I commented in the bug, the list will be undiscoverable if we do that [05:59] even if we say 'see also'? [05:59] poolie: help formats doesn't list all the formats [05:59] iiuc all of them are listed in other help topics? [05:59] its now static text [05:59] because help formats used to be the full list from the options and it was too long :P - same issue [05:59] ok [06:00] so i thought they were all included in either current-formats or other-formats [06:00] I'd rather, TBH, have the option list short and detailless - hand crafted, and help formats be the full dynamic list it used to be [06:00] and that those were dynamic [06:00] just including the common ones? [06:01] well, the filtered logic we have - hide hidden etc already exists [06:02] hmm [06:02] current-formats is sane, and other-formats has rest [06:02] perhaps thats enough [06:02] ok [06:03] its a little long winded though [06:12] i agree [06:12] nm for now [06:13] the annoying thing about trying to fix one of these bugs is how it makes you notice more [06:28] :) [06:31] igc, are you still here? [06:35] What quick check can I do on the .tar.gz to confirm the pyrex-ifed files are in there? [06:39] tar tzf | grep \\.c [06:40] there should be about 4-5 files [06:41] poolie, there is a fix up for bug 345169 if you want to do a review [06:41] Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169 [06:41] lifeless: http://www.nopaste.org/p/apmIZgncK [06:42] k [06:42] BasicOSX: looks fine to me [06:42] k, "ignore" my post to the ML :-) [06:45] 1:45am, sleepy, watching check-dist-tarball scroll makes my eyes heavy! will push and announce things in the morning. [06:47] * lifeless is gone [06:49] poolie: yes [06:58] hi all [07:00] hi vila [07:01] lifeless: ping. working on parallel selftest. KnownFailure and UnavailableFeature deserialized, with 8 procs, selftest for ~17500 tests is down to 2/3 minutes [07:01] vila: cool [07:01] vila: I'm working on ec2parallel now [07:01] vila: most of that code should not land in bzr itself, I only committed it there to get it to you [07:02] lifeless: right, so where do you plan to land it ? [07:02] lifeless: should I make bzr pluggable and go for plugin instead ? [07:02] subunit [done], testtools [part of it is up for review already] [07:02] lifeless: or do you target testtools/subunit ? [07:02] and a small strategy bit in bzr itself [07:03] subunit landed ? I saw a merge request for it yersterday but didn't check today [07:04] poolie: see http://bazaar-vcs.org/SummerOfCode2009 [07:04] vila: done not landed [07:04] vila i'm reviewing your ftp server thing [07:04] I modified ThreadsafeForwardingResult to add wnFailure and UnavailableFeature deserialization, should I subclass instead ? [07:04] poolie: thanks ! [07:04] poolie: I think I forgot to add a NEWS entry [07:05] well, there aren't unittest standards for those aspects yet [07:06] lifeless: but [07:06] lol [07:06] no but [07:06] look in the subunit and testtools log [07:07] you'll see addSkip [07:07] lifeless: but TAP2SubUnit handles xfail it seems, but not TestProtocolServer [07:07] we need to do something similar for all the custom things in bzr [07:07] lifeless: I saw that, but couldn't decide if *some*things should stay bzr specific or not [07:07] vila: on indeed, where te subunit wire protocol decides that X is already handledand subunit can't deserialise thats a plain ol bug [07:08] so definitely -> fixes to subunit for that [07:08] it would be clearer if I described my goals I think [07:08] I want: [07:08] - a couple of small functions in bzr that specify how to turn a bzr test suite into an externally run suite [07:10] vila: like http://paste.ubuntu.com/133468/ [07:10] vila: thats bzr specific [07:10] vila: that, option parsing to enable this, is all that should be in bzr itself for this, IMO [07:11] vila: and even that should be a helper bzr chooses to use rather than inaccessible in bzrlib [07:13] lifeless: sounds reasonable, when asked to parallelize (-j n ?) do we want a warning and fallback to serialized selftest or just abort ? The idea is that selftest should still return coherent return codes [07:14] vila: expand on that, I suspect you are missing an assumption [07:15] if I run 'selftest -j n' and miss the dependencies, I want selftest to either abort (sorry, couldn't verify your tests ran) or just fallback to normal behavior (I couldn't parallelize, but I ran the tests anyway) [07:16] either is fine; I'd abort myself [07:16] vila: for now, just schlep plain diffs to me [07:16] I slightly prefer that too, deal. [07:16] I have a bunch of untangling of my sketch to do :P [07:17] jml: which reminds me - could you please review my subunit merge request, its trivial [07:17] lifeless: your _subunit_ one? [07:17] * jml looks [07:17] * vila mumbles: bundle when I send diffs and now diffs when I want bounded branches :) [07:17] rats bound branches [07:19] lifeless: one question: do you want to stop reading when there's a blank line? [07:19] lifeless: oh, any idea why a 'bzr serve --port localhost:0' is coming from ? It stays alive and blocks the whole thing with zombies [07:19] s/why/where/ [07:19] jml: end of file [07:19] hmm. maybe readline() includes the terminating line char [07:19] * jml experiments [07:19] mwhudson: so the answer is [07:20] mwhudson: readlines buffers regardless of the buffer size [07:20] mwhudson: readline doesn't [07:20] lifeless: ah, ok [07:20] lifeless: once killed, everything terminate gracefully [07:20] >>> news.readline() [07:20] '--------------------\n' [07:20] vila: not specifically, no [07:20] jml: yes, it does [07:20] it returns '' for end of file [07:21] so bool(line) <=> EOF [07:21] yay. [07:21] and '\n' for intermediate empty lines [07:21] right [07:21] vila: well gracefully with still failures=1, errors=9, which I intend to address first [07:21] the subunit fix is what gives us graceful concurrentp progress [07:21] lifeless: approved. [07:21] for i in file: === for i in iter(file.readline, ''): [07:22] jml: thanks [07:22] iter takes a second parameter?! [07:22] or something like that [07:22] * jml keeps learning Pythno [07:22] mwhudson: meep [07:22] yep [07:22] mwhudson: also, for i in file: == for i in file.readlines() :( -- buffers 1K or so suckage [07:22] well [07:22] different implementations i think [07:23] mwhudson: so I argue ~= [07:23] yes, ok [07:23] mwhudson: no, I started with for i in file [07:23] mm, may need to checkt he C code [07:23] regardless, it suckaged [07:24] lifeless: i'm not disagreeing with your observations, just your deductions [07:25] the code implementing readlines and iteration for files is entirely disjoint [07:25] i can believe both buffer though [07:25] and yes, looks like readline() is yet another case [07:25] * mwhudson reads code, gets confused [07:26] too late in the day to be thinking anyway [07:26] lifeless: also, from a high level, splitting by concurrency only once doesn't give the best results here with 8 procs, some processes finish far quicker than others. IMO, once things stabilize enough, we should look at making each process handles *several* test slices instead of just one [07:28] lifeless: roughly, the actual 200 seconds can go down to 120 or something I think [07:28] mwhudson: :P [07:28] vila: well [07:28] vila: I appreciate that [07:29] vila: ideally it streams (say) 30 seconds worth at a time [07:29] or we annotate each test with a cost and make the partitions have equal cost [07:32] Could be, I don't strive for perfection there though, if I can just feed the processes a bit more, I'd be happy (and end up with a simpler code I think). Evaluating test cost upfront or based on previous execution sounds a bit fragile/hard [07:32] but as I said, not something I want to decide on without a first version running smoothly [07:33] lifeless: by the way, any idea when you could have a look a loom tests, I still have failures and no enough understanding to fix them :-/ [07:36] yay activity bars [07:36] And yet *another* person burned by Ubuntu only shipping bzr version 1.3! [07:37] * AfC scratches another chalk mark on the wall... [07:38] it should be fixed soon [07:38] at least in backports [07:47] lifeless: i'm reading your patch then i'm going to go [07:47] AfC: btw, with 1.13 shipped you should be seeing better network behaviour already [07:48] lifeless: I'll keep an eye out - the bzr package on my distro is upgraded already, but I haven't done anything demanding software wise this week so I haven't had a chance to form a subjective view yet. [07:58] lifeless: no more zombies no 'bzr serve' hanging processes, WNOHANG is *not* your friend :) [07:59] vila: its not the parallel suite causing it [07:59] vila: it happens on pqm too [07:59] lifeless: you mean the 'bzr serve' one ? [07:59] yes [08:00] well, at least I got read of the zombies... or not, I'll keep an eye on it but WNOHANG and calling waitpid *before* joining the thread didn't sound right [08:03] lifeless: right, its' back, but indeed, far less zombies as expected [08:03] * vila acquires target [08:10] so [08:10] I have BZR_PARALLEL=subprocess working [08:10] but fugly batched output again [08:11] lifeless: send diffs :-) [08:12] yes dear [08:12] :-) === bob2 is now known as Guest7068 [08:14] http://paste.ubuntu.com/133493/ [08:16] lifeless: thanks [08:16]