[00:01] lifeless: pong; just figuring out my after-work commitments now so I can plan that. [00:06] mwhudson: Now with more evil and depravity :) http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/revision/324/loggerhead/templates/macros.pt [00:14] spiv: kk [00:16] lp's ssh refuses to connect :( [00:16] weigon: LP's down for maintenance. [00:16] maintanence? Eh, whatever. [00:17] *doh* thx [00:21] crap, revision properties contain arbitrary binary data? [00:22] jelmer: it's just {str:str} isn't it, so i guess so? [00:23] mwhudson: what's the easiest way to escape arbitrary data in something representable in unicode? [00:24] jelmer: repr()? s.encode('unicode-escape')? base64? [00:25] jelmer: i guess it might be meant to be utf-8 or something [00:25] i guess i'm the wrong person to ask [00:26] jelmer: why do you say they contain arbitrary data? [00:26] Peng_: base64 is overkill, unicode-escape requires a unicode string (and I have no way of creating one) [00:27] Peng_: your increased depravity looks fine to me :) [00:30] mwhudson: Is that a bb:approve? :D [00:30] lifeless: at least one of the tests tries to add "\xb5" as property value [00:32] (in other words, a object and invalid utf8) [00:34] jelmer: ah interesting [00:34] and we what, base64 enciode them ? [00:35] it seems like it silently gets casted to unicode [00:35] in the XML serializer [00:35] so "\xb5" goes in, u"\xb5" comes out [00:36] but you said \xb5 isn't valid unicode? [00:37] lifeless: it's invalid utf8 [00:46] jelmer: is the test testing that or is it a bug in the test? [00:49] lifeless: the bug is in the test [00:49] lifeless: "No shells on this server." ... Connecting with putty with same certificate seems to work. You said if that was so, then bzr didn't pick up Pageant. How would I fix that? [00:56] MizardX: now we've reached the end of my knowledge :( I haven't used bzr on windows [00:56] Ok. Thanks. [00:56] MizardX: but we now know that your launchpad and putty stuff is setup [00:56] uhm [00:57] did you install using the windows binary, or the 'python installer' ? [00:57] binary [00:57] bzr --version will give you the path to a log file [00:57] I think it's compiled with py2exe [00:57] you might look in that log and see if there is anything about pagent/putty [00:59] Just "ssh implementation is OpenSSH" and "ConnectionReset: Connection closed: please check connectivity and permissions" [00:59] ok [01:00] that suggests it found a ssh.exe on your machine and is using that [01:00] there is an environment variable to control this I think, one sec [01:01] do you have plink installed? [01:02] yes [01:02] ok [01:02] try [01:02] setting the BZR_SSH environment variable to 'plink' [01:04] "FATAL ERROR: Disconnected: No supported authentication methods available", not it doesn't find the certificate [01:04] now* [01:06] lifeless: I'll head to you. ETA is 11:50 by the time I buy my coffee :) [01:06] Ah, pageant wasn't running... [01:07] "Branched 8 revision(s)." :D [01:07] Thanks, lifeless. [01:10] mwhudson: ping [01:10] mwhudson: Mind if I make an old-style class in Loggerhead new-style without getting it reviewed? (Well, asking is almost as inconvenient as a review...) [01:11] MizardX: cool [01:16] what does this mean: error: unable to create symlink 'themes' on this platform [01:16] Would I be correct at guessing you're running Windows? [01:16] Also, how did this come about? What command caused it? [01:16] unfortuneatly yes [01:17] i was just getting a branch [01:17] Then I can only assume the branch contains symlinks, which have no equivalent on Windows... I dunno what else it could mean. [01:18] ugh, ok... the thing is is that it gave me any of the other files in the branch [01:20] Launchpad is running bzr 1.13 on production now. [01:21] ~18s & 21 hpss calls to push no revisions to a stacked branch. ~7s of that is SSH connection time. [01:23] ~27s & 32 hpss calls to push one revision to a stacked branch. [01:24] jml: is this better :) [01:24] yes. [01:27] g'day all [01:27] how long should bzr selftest take on a macbook ? [01:27] it has been running an hour and a hlaf [01:28] sm: it takes about 20 minutes here [01:28] lifeless: bzr pull is noticeably faster. [01:28] jelmer: on a macbook ? [01:28] sm: ah, no, sorry - linux [01:29] lifeless, spiv: congratulations! [01:29] thanks [01:32] hmm. making a new stacked branch is still kind of slow. [01:32] I wonder if bumping our format to 1.9 would change that. [01:32] do you have the patches we landed yesteday? [01:33] lifeless: only if they are in the nightly -- I'll update my bzr.dev and try pushing with that. [01:33] well, whats your nightly version? [01:34] lifeless: 1.14~bzr8.10-4223-1 [01:35] lifeless: down from 81 -> 66 calls using bzr.dev. still the same elapsed time. [01:37] jml: ok, thats interesting [01:37] pop the log up somewhere [01:39] lifeless: http://paste.ubuntu.com/142445/ -- first is using nightly, second is bzr.dev [01:40] both are pushes of the same branch to Launchpad but to different locations. branch was made locally from a mirror of the default stacked-on branch. so no new revision data for either push. [01:44] What would be the best way to have a particular file updated every commit to include a revision number? I think I could use a hook for it, but it looks like I would have to require it be installed on all committer's computers. [01:45] Snova: Well, that's what the new keyword plugin is for, although it just applies to the working tree, not the history itself, like svn:keywords. [01:45] Snova: That'd mean you only need the people who actually need the revision numbers to install it. [01:45] Snova: Anyway, the usual workaround is to have your Makefile run "bzr version-info >whatever". [01:46] Snova: what do you want to achieve with this? [01:46] lifeless: I'd like the server I'm writing to send the revision number along with the version. [01:47] Snova: of the codebase its running? [01:47] Yes. [01:47] as Peng says, invoking bzr version-info during server startup is probably better [01:48] I could, but then it assumes it's always in a branch... a source tarball or any form of distribution wouldn't... although I primarily want this during development, if I actually released it there wouldn't be much point. === ja1 is now known as jam [01:49] I guess that works, and it's the simplest way. [01:49] you can hook that into your tarball export logic too [01:55] lifeless: http://bugs.python.org/issue5660 [02:00] jml: well, we think we have stuff in the works that will cut another ~10s out of that fairly soon (needs new verbs, though). [02:01] jml: thanks for the log [02:01] Hooray for Bazaar! [02:01] spiv: cool. [02:02] jml: so if you're lucky, 1.14 on the server and client will fix it [02:02] if you're not, it won't :) [02:02] if I'm extra double lucky, we might get an edge codehosting service so we can run 1.14 on the server before the next LP release. [02:04] when is the next release? [02:04] lifeless: four weeks from today [02:09] What would the edge codehosting do? Have a second copy of everything? Would the main and edge instances both pull mirrored branches? [02:12] jml: btw, my locations.conf for my bzr branches now defaults to lp [02:14] spiv: nice! [02:14] 67 HPSS calls, 48s (including SSH handshake) and 207k to push up a new branch with a new revision. Not too bad. [02:14] Peng_: it would just be the SSH server & surrounds. There would be no edge puller. [02:14] Peng_: it would use the same data and be in every way analogous to the edge web service [02:15] jml: uh [02:15] jml: bzr: ERROR: Server sent an unexpected error: ('error', '') [02:15] jml: that was on a Branch.unlock RPC on an empty push [02:16] spiv: hmm. I bet it's an operational glitch. [02:16] jml: maybe the XML-RPC server was unreachable temporarily for the "hey please rescan this branch" ping? [02:16] jml: how hard would it be to get that message to a) have an OOPS code, and b) make it clear that LP is to blame, not the client? :) [02:18] spiv: if you asked me, I would have thought that the OOPS was already in it. [02:18] jml: I see! [02:19] jml: So that means there is probably already an OOPS generated, at least? That's nice! [02:20] jml: btw, it does seem to be a transient issue, a second attempt at the empty push worked just fine, rather than erroring on the final (13th! spooky!) RPC. [02:21] jml: In my magical land of perfect software and ponies, and temporary inability to reach xmlrpc.lp.internal wouldn't break anything... [02:21] https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/281042 [02:21] Error: This bug is private [02:21] s/and/an [02:21] describes such a land. except that it's private, for reasons that elude me at present. [02:22] jml: ah, yes, I guess it was a timeout, judging from the 20s + a bit it took between request and error response. [02:23] * spiv clicks the hard-to-find "me too" link. [02:23] (Something seems wrong when it's easier to add a "me too" comment than use the "me too" feature...) [02:26] spiv, yes. Quite a few things, actually. Hopefully, we'll address that in 2.2.5 with the change in the bug lauout page [02:27] spiv: fwiw, https://bugs.edge.launchpad.net/launchpad-bazaar/+bugs?field.tag=codehosting-ssh is actually a fairly complete list of bugs in the codehosting server [02:27] spiv: btw, what's the status of your ~ patch? [02:28] jelmer: limbo; I need to find some spare time to rewrite along the lines poolie wanted to see if I'm happy with his approach [02:29] jelmer: I think I'll be fine with poolie's approach (although his approach does need a new server, which is a minor drawback), but it needs to be implemented... [02:30] spiv: ah [02:31] (on the other hand my approach needs a new client and his doesn't...) [02:44] Could someone take a look at lp:xubuntu-docs and see if there is anyway we can improve performance? Branching and pushing seems to take a very long time on it [02:45] cody-somerville: use bzr 1.14 [02:45] cody-somerville: and be sure you have done bzr launchad-login [02:45] I have [02:45] I'm using 1.13 [02:46] is 1.14 in the ppa? [02:46] in the nightly ppa yes [02:46] jelmer: jam has suggested that the filter registration function just take a callable, not a dict and a callable [02:46] jelmer: I think it's a good idea. OK with you if I put a patch up for that? [02:46] we want the API stable for 1.14 [02:47] cody-somerville: also, have you tried branching and pushing since the lp rollout that happened an hour or so ago? [02:47] I just branched [02:48] cody-somerville: I'm doing a branch now, and it's streaming to me here in Sydney at ~150K/s [02:49] (which I believe is the capacity of this ADSL link) [02:49] (I have a 1.5MB connection, so thats 1.2MB used by bzr [02:50] cody-somerville: and how long did it take to branch? [02:50] cody-somerville: [you are aware you have 30Mb of history] [02:51] Yea, I figure thats what the problem is [02:51] I did some nasty stuff to get the revision history to show correctly [02:51] cody-somerville, and, you could use a shared repo, so you only download whatever revision once in a life time [02:51] I am using a shared repo [02:52] cody-somerville: "12:46 < lifeless> cody-somerville: and how long did it take to branch? [02:52] " [02:52] so it should be very fast after you did it oncec...? [02:52] once even [02:52] lifeless, about a minute [02:52] "time bzr branch lp:xubuntu-docs" here just took 4m23.953s, which seems to be about as fast as this ADSL link allows. [02:52] Given that it had to fetch ~36M [02:53] cody-somerville: do another branch with -Dhpss please, and we can look at the network activity if you grab the log for that bzr command from your ~/.bzr.log [02:53] okay === timchen119 is now known as nasloc__ [02:55] 60 seconds is long to figure out you have everything locally, unless you didn't branch into your shared repo [02:55] I did and am again [02:55] oh; also try 'time bzr checkout --lightweight $SOME_LOCAL_BRANCH /tmp/foo' [02:57] lifeless: FWIW, that takes less than 1s here. [03:00] cody-somerville: ping; 1 minute should have finished ages back [03:00] lifeless, It takes a long time to copy and paste the log :P [03:00] cody-somerville: I'm kindof paying attention here to give you a fast turnaround; if you're going away to do stuff let me know and I'll get back to coding [03:00] http://pastebin.ubuntu.com/142472/ [03:01] No, just takes a long time to copy and paste 6078 lines [03:01] you missed the top of the log even so :) [03:01] Before that is log stuff about another command I did [03:02] oh wait [03:02] nvm [03:02] cody-somerville: don't worry [03:02] you're not using a shared repo [03:02] so its copying everything [03:02] http://pastebin.ubuntu.com/142475/ [03:03] oh... I guess you're right [03:03] I thought I had created that [03:04] btw, I did bzr check and it said this: http://pastebin.ubuntu.com/142477/ [03:05] Is an inconsistent parent bad? [03:05] its something to fix [03:05] bzr reconcile will fix it [03:06] lifeless, So I moved a bunch of files - when I merge from the parent, which hasn't moved the files, will bzr do the right thing or will they go to the old location? [03:07] cody-somerville: why don't you try ?:) [03:07] lifeless, cause the branch is reconciling atm or I would ;) [03:07] oh, that was quick [03:09] lifeless, would a repack help make the branch smaller? [03:10] cody-somerville: no [03:10] bzr repacks itself as it needs to [03:12] what about that obsolete_packs directory? [03:12] is that maybe causing the download to be more than it needs to be? [03:13] No, it doesn't affect downloads at all. [03:13] hmm... the branch seems to be bigger now than before [03:14] cody-somerville: 1 minute is not long [03:14] You have 36M of actual revision history, which doesn't sound so unlikely for nearly 200 revisions of a 5.9M tree of files. [03:14] Its 77M on disk [03:14] cody-somerville: all seems to be working reasonably; its under a second to make a working tree, and with a shared repo new branches hsould be about 3 seconds or less [03:14] cody-somerville: thats because of the reconcile; ignore it [03:15] cody-somerville: housekeeping will take care of it [03:15] lifeless, so will this reconcile get pushed to launchpad? [03:15] cody-somerville: no [03:15] launchpad needs to be reconciled separately [03:15] should I do that? [03:16] if you like [03:16] what exactly am I fixing? [03:16] Will it make merging easier or something? [03:16] what revisions annotate will attribute content to [03:18] cody-somerville: generally speaking you shouldn't need to worry or do anything special with bzr to make it perform well; the one key exception is shared repositories [03:18] and the second key exception is using a smart server if one is available (which lp: does for you once you login, and bzr+ssh/bzr+http do elsewhere) [03:26] Hey I discovered the super awesome "bzr join" command without any help from mwhudson but the only problem is that I can't figure out how to use it would anyone like to assist me [03:26] I have two unrelated branches and I want to make one of them just be part of the other one. [03:28] hmm... [03:28] bzr doesn't seem to have done the right thing :( [03:28] and ugh.. "1432 conflicts encountered". [03:29] exarkun: use the bzr merge-into plugin; join is part of an as-yet unreleased feature [03:29] cody-somerville: did it print 'criss cross merge' at the top ? [03:29] no [03:30] thats very odd then [03:30] what are the conflicts? [03:30] and when you say you did nasty things, could you be more specific [03:31] I'm going to guess you've been doing history-glueing in some nasty manner, and it is [predictably] biting you [03:31] Well, I took branch A and branch B [03:32] lifeless: Oops! I figured out how to use bzr join while I wasn't looking at IRC. [03:32] A wasn't based on branch B [03:32] lifeless: Should I start over with merge-into? [03:32] But really was [03:32] exarkun: if it has worked, go for it. [03:32] okay cool, thanks :) [03:32] So I merged B into A using -c 1 [03:32] That worked fine and I got what I wanted except I lost all the revision history from branch B and some people didn't like that [03:33] cody-somerville: when you say 'a wasn't based on branch b' do you mean 'they were completely separate projects' ? [03:33] No, it was Xubuntu docs and Ubuntu docs [03:33] They're similar but the branches didn't have shared revision history because Matthew restarted all the branches from scratch for some reason [03:33] I imagine for performance reasons [03:34] ok, which means 'they were completely separate projects' [03:34] no history -> separate projects [03:34] Right [03:34] B was based on C [03:34] you should use 'bzr merge-into' to join them. [03:34] and now I'm trying to merge C into B [03:35] Oh I missed a part [03:35] I removed everything in B and put in the contents from A to get the history back [03:35] and then I merged A into B to get the metadata [03:36] B *is* based off of C and now I'm trying to merge C into B [03:37] well [03:37] you might try merge --weave [03:37] I moved a ton of stuff into a subdirectory [03:37] it may do better [03:37] did you move using 'bzr mv' ? [03:37] so now I have a bunch of files in the old directory ending with .BASE and .OTHER [03:37] lifeless, I did in A, yea [03:37] or did you move by doing 'mv; bzr add' ? [03:38] I did bzr move [03:38] but in A [03:38] is A merged into C or B or neither? [03:38] into B [03:41] so should I do: bzr remerge --merge-type weave --reprocess [03:42] * cody-somerville tries [03:43] lifeless, If this doesn't work, would branching C and doing the moves over again and then merging that into B work and make future merges of C work? [03:43] hmm... only 1324 conflicts this time [03:44] but didn't do the right thing. bzr diff desktop-guide (the directory I moved almost all the directories into) returns nothing. [03:45] cody-somerville: what would you expect it to return? [03:45] lifeless, The changes bzr merged in? [03:47] lifeless, bzr isn't touching any of the files already in the branch [03:47] lifeless, all the conflicts are on files its added [03:50] I'm also getting this error now trying to branch inside the shared repository I created: http://pastebin.ubuntu.com/142494/ [03:52] cody-somerville: you ran 'bzr init-repo' to make the shared repository, yes? [03:52] yup [03:52] cd to the root of the shared repo [03:52] okay [03:52] and run bzr upgrade --default-rich-root [03:53] bzr: ERROR: no such option: --default-rich-root [03:53] 'use bzr 1.14' :) [03:53] hell you're canonical, you should be using the nightly ppa :) [03:55] ;p [03:55] also, I just got this when trying to do bzr remove */po/*.po: bzr: ERROR: [Errno 24] open: Too many open files: '.' [04:40] hmm, I wish that the GNOME vcs-imports branches weren't the default branches :-( [05:20] SamB: if there's a better branch to use, file a request at https://answers.launchpad.net/launchpad-bazaar asking for the default to be changed. [05:21] spiv: well, in #launchpad they've got me seeing if I was using a bleeding-edge enough bzr that they should have fixed the problem where it takes forever to push to a branch with little to no shared history with the branch it is to be stacked on ... [05:22] SamB: ah, yes. We keep fixing bugs :) [05:23] SamB: but even so, if there's a better branch, do let the relevant people know [05:23] and they said something about how GNOME is supposed to be switching to git [05:24] so that the bzr-playground branches might not be that great for too long [05:31] SSH handshake time is now well over a third of the overall time in random incremental pushes to my branches on LP. [05:32] oh, incremental pushes seem fine [05:49] SamB: I'm opening to changing the message if it can be less confusing [05:49] SamB: but I figured I should explain why it is saying that (and why it's not "lying"). [05:49] Well, "transferring" is a much more neutral word [05:49] if it can't be bothered to figure out which of the two activities it is engaged in is taking all the time ... [05:50] I'm not sure what you mean by that comment? [05:50] The activity is (accurately, by its choice of perspective) called "fetching". [05:50] well, it's not waiting on the fetches from the local repository ... it's waitng on the stores to the other one [05:51] Not really, those things aren't really decoupled. [05:51] well, okay, in that case the word is "transfer" [05:52] so [05:52] we're going to overhaul this [05:52] and make it prettier [05:52] at least, in en_US that's the case [05:52] transfer is indeed a synonym [05:52] or nearly so [05:52] at the right point in the code [05:52] maybe in en_AU or en_UK, fetch is more synonymous with transfer? [05:53] but one of the basic problems is that the code doesn't *know* which end of the pipeline the human is sitting [05:53] so really, a more directional adverb to describe what is going on isn't easy to correlate with the UI [05:53] well ... saying "transfer" is a nice and neutral thing to do in that case [05:53] or when, say, both repos are local [05:53] sure, thats one way we can alter the message [05:54] all I'm trying to say is: [05:54] - it is broken at the moment [05:54] okay, yeah, I gathered ;-) [05:54] - its not top of the pops for time until the rc [05:54] - until then, I don't plan on thinking too hard about it [05:55] (so please forgive me for simply acking that its an issue, until we're looking at the code, finding a combination that reads well and fits the code isn't necessarily easy [05:55] the code itself *is* highly directional [05:57] you know, I guess I don't need to finish this push ;-) [05:57] SamB: is it still slow? [05:58] it's just that I was just pushing the same thing to a new branch [05:58] so now that I've established that it was just a confusing progress message, I don't need to finish [05:58] oh :) [05:58] makes sense to me [06:29] lifeless: did you see my patch about --parallel ? [06:31] no [06:33] lifeless: ~one liner to make it work but I think you're the one that can review it [06:49] where is it [06:57] vila: ^ [06:57] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2iqlozk7x.fsf%40free.fr%3E [06:58] # A registry where get() returns a suite decorator. [06:58] parallel_registry = registry.Registry() [06:58] + [06:58] + [06:58] def fork_decorator(suite): [06:59] those changes are bogus , PEP8 allows adjacent for things that are closely related [06:59] specifically I want the FOO_decorator and register..FOO adjacent [07:05] vila: reviewed [07:15] lifeless: still ok to separate each couple ? [07:18] sure === serg_ is now known as serg === serg is now known as anyone === anyone is now known as serg [11:43] If I do bzr revert on a file, does that count as a change? IOTW, if I commit it, will it commit the reverted file as a head revision? [11:45] bzr revert is no different from manually changing the working tree [11:45] plain 'bzr revert' will just revert to the head revision, so it wouldn't commit anything [11:46] Ah OK - thanks. I used to use perforce, and that behaved quite differently IIRC. It would rememeber what revision number of each file you currently have in your working tree. [11:46] hm? [11:46] So pulling out an old version to look at was not a change. [11:46] ah [11:47] no, bzr revert operates purely on the working tree, you can do something like 'bzr cat -r file >file' and it will be more or less the equivalent [11:47] Right - makes sense. Thanks! [12:18] jelmer/vila: would authentication.conf have problems with passwords that contain @ characters? [12:19] Specfically, if I put my password in the file, it fails, remove it and I get prompted more than once for each bzr-svn push [12:21] awilkins: quote it [12:21] Aha [12:22] vila: Failed [12:23] awilkins: :-/ quoted as in user@host => user%40host ? [12:23] Ah, as in "c@r" [12:23] awilkins: sorry, I meant url encode it [12:24] Hmmph, still not working [12:25] Although by now I may have locked out my account I suppose [12:25] Nope, still works fine at the command line [12:25] awilkins: what protocol are you using ? [12:25] svn+http [12:26] you mean bug #256612 ? [12:26] Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612 [12:26] or some related problem ? [12:27] THe username is correctly being picked up from auth.conf with is set up for the host [12:27] If I add the password it failes [12:27] I thought connecting succesfully with *svn* was the current work-around [12:27] Yes, I thought I'd done that [12:27] Although it was with TSVN [12:27] I'll try getting it cached in the CLI client also [12:29] That works [12:30] good, then you encountered the bug above or something very close [12:33] It's obviously using the password when it's provided in the conf file, but it appears to be wrong === ja1 is now known as jam [12:56] lifeless, jml: they've fixed the deepcopy(TestCase(...)) bug [12:58] lifeless, jml: but you might want to take a look at the new TestCase.addTypeEqualityFunc method [13:33] jelmer: I imported an svn repository with bzr-svn's svn-import. I see "svn revno: x" in log output, but I can't use -r svn:x. Why not? === sabdfl1 is now known as sabdfl === NEBAP is now known as NEBAP|work === NEBAP|work is now known as NEBAP|away === NEBAP|away is now known as NEBAP|work [14:17] fbond: you need a newer version of bzr-svn to do that on imported branches [14:18] igc: yeah, just taking a callback sounds good to me [14:18] jelmer: Okay, thanks. [14:19] jelmer: I'm using trac-bzr; it'd be really swell if I could get the old references to svn revisions work in the diff viewer. ;) [14:19] I mean [283] links and whatnot. === ja1 is now known as jam === abentley1 is now known as abentley [15:04] vila: bleh, I'm not sure how I missed that appearance of 'password' [15:04] jelmer: :-) [15:05] vila: I did actually refactor that function but changed it back after I noticed it broke for LC_ALL=C [15:07] jelmer: huh ? the one you copy from has been passing for ages or did I miss something ? [15:07] vila: Yes, but I changed it after I copy pasted it [15:07] haaa :) [15:08] vila: and that broke the tests, so I fixed it and ended up with what the original did :-) [15:08] vila: Your NotATerminal patch looks ok, with one minor concern [15:08] vila: won't this caused backtraces when there's no terminal? [15:08] getpass() will raise an exception that's not caught atm [15:10]