[00:26] spiv: ping; my place is available if you're interested; or I can head north. [00:30] hello there. [00:30] If a repo's URL changes, can bzr be told of that change or do people need to do a new checkout/branch? [00:33] Pegasus_RPG: 'bzr switch' can be used to change what things are checkouts of [00:33] branches don't care, they just need to pass the url to the next pull/merge [00:33] e.g. 'bzr pull URL --remember' [00:34] lifeless: ok, so a user needs to issue both a switch and the pull --remember? [00:34] Pegasus_RPG: either/or [00:34] oh ok cool [00:35] thank you muchly [00:35] if they have a checkout, switch, if they have a branch, pull/merge --remember [00:35] (The #mixxx teamis getting our feet wet) [00:35] with bzr [00:35] cool [00:35] reading "Bazaar was made for merges" made me happy [00:36] (I recently had to merge one of our branches to trunk on SVN...not fun) [00:36] btw, is there any decent Linux GUI for BZR? (Like KDESVN is for svn?) [00:36] http://www.mixxx.org/ ? [00:36] yep that's us [00:37] for kde, you should look at qbzr [00:37] ok thanks [00:37] for gnome there is gtk-bzrn [00:37] *gtk-bzr* [00:37] * Pegasus_RPG has kde and was not impressed with Olive [00:37] olive is gtk based [00:37] you may like qbzr more [00:38] and please file bugs about the things you'd like different [00:38] they are both under active development [00:38] OK cool. Thanks again [00:40] can I create bazaar users without creating system users? I guess similar to how subversion could create users? [00:41] lifeless: I'll head south soon, just sending a fix for the get_parent_map bug [00:41] cool [00:41] shtylman: svn doesn't really know about users either, do you mean the apache integration? [00:42] shtylman: but the answer is approximately "no" [00:42] mwhudson: I see...so places like launchpad...they create system wide uers?...lets say I can do that...how then do I limit the user to bzr only? [00:42] is that possible...? [00:42] shtylman: launchpad has a custom ssh server [00:42] ahh [00:43] shtylman: you can play tricks with .ssh/authorized_keys though [00:44] (i think this is what bitbucket does for ex) [00:46] mwhudson: k...thanks..I will look into some alternatives [01:27] lifeless: did my InterBranch.pull patch look ok to you other than the issues you raised? [01:28] jelmer: I haven't looked all that closely; as long as there is a per_interbranch test parameterisation done sanely, its probably good [01:37] lifless: yeah, I think that is the case (we already had the infrastructure for InterBranch.update_revisions()) [02:20] hello hello [02:21] as of yesterday [02:21] bzr is amazingly slow [02:21] https://pastebin.canonical.com/15795/ [02:21] I'm pulling a branch with a few small changes [02:21] and it's taking ages [02:22] is there anything in bzr.dev that would provoke this? [02:22] not sure what all those "Repository.get_parent_map" are [02:22] or RemoteSSHTransport.readv 5 offsets => 2 coalesced => 1 requests (2) [02:22] its falling down to vfs [02:22] ah [02:23] why would it do that? [02:23] because lp is still running 1.12 [02:23] well, it was working fantastically well up until yesterday [02:23] and edge says 1.13: https://code.edge.launchpad.net/ [02:23] you're looking at the wrong things [02:24] and edge lies vis-a-vis the server [02:24] the 3 minute gap between lines 11 and 12 is the problem [02:24] ah [02:24] the rest is 17 seconds long [02:25] if you have ssh connection sharing, and suspended with a master ocnnection open, that might fit [02:25] ah, I do [02:25] nothing to do with bzr :) [02:25] I see [02:26] but something must of changed to suddenly make this a problem, no? [02:26] even though it's my settings [02:26] no [02:26] its been latent in your ssh config, or perhaps a ssh change on your system [02:27] .ssh/config: https://pastebin.canonical.com/15796/ [02:28] beuno: ...and? [02:28] beuno: kill your master connections, try the pull again, if its not faster, we can dig deeper [02:30] ehm [02:32] lifeless, as usual, you're right [02:32] thanks [02:33] I know :) [02:36] lifeless: you don't *really* expect us to let THAT stand, do you? [02:36] :) [02:37] weeeel [02:37] l === ja1 is now known as jam [02:49] lunching === Leefmc is now known as Leemp [03:51] jelmer: the check devs have said 'will be integrated in april, or we'll give you commit and you can do it yourself' :) [04:40] The docs say "bzr log -r date:yesterday..date:today" should give me all of today's revisions, but it only returns revision 1 [04:41] but "bzr log -r date:yesterday.." works as I expect [04:41] is "today" strange or are the docs wrong? [04:41] Possibly both ;) [04:41] you may have found a bug [04:43] heh, "date:today..date:yesterday" still returns revision 1 [04:56] Actually, date:today.. gives you all of today's revs... [04:57] it does [04:57] ivan: did you start your project today? [04:57] yep [04:57] so, date:today is 12am today [04:57] the start of today [04:57] I think [04:57] date:yesterday..date:today probably gives you all of yesterday's revs, and the first rev from today. [04:58] Which would fit. [05:07] date:1999-01-01..date:2000-01-01 still gives me r1 :) [05:24] something to read http://dabeaz.com/coroutines/ [05:41] ivan: date: has a lot of rather scary dark corners :) [05:43] I really like bzr, even after just a few hours [05:44] For instance, the latest rev [I have] of bzr.dev has timestamp: Tue 2009-03-31 02:11:33 +0100 [05:45] But date:2009-03-31 doesn't find anything for me, because that rev is from 2009-03-30 in my TZ. [05:45] ivan: we like it too ;) [06:05] are there any consequences if I'm inconsistent about which branch is my mainline? [06:06] it doesn't really seem like it, given how revision numbers work [06:07] ivan: mainline is just social, so you can organise however you like [06:09] thanks [06:21] jelmer: ping [06:55] can I steal the commit message from the (only) change made in a branch? [06:55] I merge a branch in, then don't want to type the commit message again [07:02] ivan: we don't have UI glue to do that; if there is only one change, why not just pull ? [07:07] An auto-commit-message plugin might be a cute hack. [07:08] Actually, maybe using a more full variant (like --short) instead of --line for the merged revs in the commit editor might be helpful. [07:08] lifeless: i did not know about pull :) [07:09] Well, until you get the people who remove the delimiter line accidentally and end up commiting the whole deal as the log message, anyway... ;) [07:21] hi all [07:21] * fullermd waves at vila. [07:29] jml: several new-stacked-branch performance fixes landed today, last one in-train at the moment [08:56] ehm, I hate when qbzr is being presented as a kde application :( [09:03] * vila quietly remove alias kbzr qbzr [09:55] BasicOSX: Since you're the current release manager (and poolie's not here right now): There's a question on LP about how the "current release" branch isn't being maintained. https://answers.launchpad.net/bzr/+question/66037 [10:34] i'm trying to use the trunk versions of bzr-git and dulwich to import a git repo, but it dies with some kind of mmap error: http://rafb.net/p/9nnue853.html [10:34] anyone know what to do? :-) [10:36] it's ok with allocating 230952 bytes, but fails when allocating 2595068 [10:37] looks like it works if I patch dulwich/pack.py with: supports_mmap_offset = False [10:48] is there a ulimit for mmap? [10:53] probably not [10:58] so it is the size argument that trips it up? [10:59] it's possibly a bug in python2.6 with the offset, or some calculation of the parameters, because some take page sizes rather than bytes [11:01] oh, that's bad [11:07] yeah, it's definitely buggy, reported a month ago [11:09] oh, what's the link? [11:12] https://bugs.launchpad.net/bzr-git/+bug/336393 [11:12] Ubuntu bug 336393 in dulwich "Can't branch on Windows" [Medium,Triaged] [11:12] and https://bugs.launchpad.net/dulwich/+bug/352998 [11:12] Ubuntu bug 352998 in dulwich "supports_mmap_offset-related crash with Python 2.6" [Undecided,New] [11:13] I don't mind fixing every program that I run, though it does get exhausting :) [11:13] ivan: could you do it again, but print all the parameters this time? [11:14] it would be good to know what they all are, thanks [11:16] PARAMS ARE 6 230952 1 0finding revisions to fetch 0 [11:16] PARAMS ARE 10 2595068 1 12ding revisions to fetch 6 [11:16] bzr: ERROR: mmap.error: [Errno 22] Invalid argument [11:17] the param order for the print matches mmap.mmap(f.fileno(), size, access=access, offset=offset) [11:17] thanks [11:17] I'll drop that in the bug [11:18] :-) [11:18] so the differences are that the size is greater, and that an offset is being used [11:19] and that it's a different fd I guess [12:04] * SamB lols at Guido's new title [12:05] or, uh, joke title [12:11] * SamB wishes gmail would just gray out the Archive button where it is not appropriate [12:20] SamB: I'm partial to barry's title too :) [12:21] LarstiQ: but it's not as meaningful a word, I think [12:21] SamB: true, true. [12:22] though it *is* delightfully silly [12:23] and Python people are just silly enough that that message would actually be quite plausible if it weren't April 1st [12:24] * jelmer wonders what he is missing [12:25] jelmer: http://www.python.org/dev/peps/pep-0401/ [12:28] lol [12:29] lifeless: ping, selftest --parallel works again, care to review ? [12:30] They really did add the barry_as_FLUFL future though. [12:30] http://svn.python.org/view?view=rev&revision=70945 [12:30] james_w: builddeb tests failing it may be due to recent changes in commit you may want to check [12:32] But I think it just adds the <> operator, not the print statement. [12:33] vila: I don't see it, have a traceback for me? [12:35] james_w: ./bzr selftest -s bzrlib.tests.test_msgeditor.MsgEditorTest.test_generate_commit_message_template_hook with bzr.dev@4230 [12:35] File "/home/vila/.bazaar/plugins/builddeb/__init__.py", line 64, in debian_changelog_commit_message [12:35] if not commit.work_tree.has_filename(cl_path): [12:35] AttributeError: 'Commit' object has no attribute 'work_tree' [12:35] urgh [12:36] james_w: The bug may be on bzr side for not being compatible though, you may have a better POV than me in this area [12:36] darnit, I need to get that flaky RAM and/or motherboard fixed ... [12:36] vila: yeah, see it now [12:38] james_w: good, I check I had builddeb up to date in the mean time, did I send you a bundle for test failures since 2009-03-16 ? [12:38] james_w: about pristine-tar ? [12:39] is there an alternative to sed for rewriting many similar URLs in a number of branch.confs simultaneously? [12:39] vila: got one on Mon, 16 Mar 2009 17:32:11, thanks [12:39] ok [12:39] it adds the PristineTarFeature [12:41] SamB: I'd write a small Python script using bzrlib. [12:41] james_w: just checking it wasn't lost as it doesn't show up on lp:bzr-builddeb [12:41] I've probably just not pushed yet, sorry [12:41] james_w: np, np, no urgency [12:42] james_w: you may even veto it, your call :-) [12:42] nope, it's merged in my local branch :-) [12:42] er, basically I meant "plugin" === sidnei__ is now known as sidnei [12:58] Hello [12:58] I've a problem with bazaar [12:59] all my pushes to my local server are frozen at : [12:59] \ 17kB @ 15kB/s === thekorn_ is now known as thekorn [12:59] not all, it depends on the repository [12:59] some are frozen, some are working normally [12:59] but branch is still working normally [13:10] When dealing with Launchpad, what type of URL do you think should be used as the parent/submit/etc. location? lp:~foo/bar/baz? http://bazaar.launchpad.net/~foo/bar/baz/? [13:12] vila: ping [13:12] don't forget lp:bar [13:12] if you let bzr set it with "bzr push lp:foo" then it will write the second form, but that's debated [13:13] james_w: Yeah, I know. To use an lp: URL you'd have to edit branch.conf, but I do that all the time anyway, so.. [13:14] jelmer: pong [13:14] ploum: what kind of server are you using ? what bzr version (client/server) ? [13:20] vila: so, what do you prefer I do in regard to get_username() ? [13:20] raise NotATerminal and provide a mock implementation that doesn't and test that, similar to get_password() ? [13:20] vila: I'm using bzr+http (smart server) [13:21] vila: the client and the server are both using ubuntu intrepid with bzr from ppa [13:21] ploum: then add 'debug_flags = hpss' in bazaar.conf on the client or -Dhpss on the command line we'll know a bit more [13:21] after a while (like 5 minutes) I have : [13:22] bzr: ERROR: Could not acquire lock "(remote lock)" [13:22] ploum: sorry I don't know intrepid version by heart, use 'bzr version' [13:22] vila: so it should look like : bzr -Dhpss push bzr+http://... ? [13:22] hmm, apparantly when pages try to use tables for layout, you can improve the way they print out by deleting extraneous cells in firebug ... [13:22] 1.13 [13:24] jelmer: there is no point in not testing code, I mention the two issues are distinct: get_username should check the tty (it will be called *before* get_pasword now) [13:25] that part of get_password becomes irrelevant if you call get_username before get_password, so don't break it [13:25] ploum: the lock should the consequence of a previous ctrl-c no ? use 'bzr break-lock' before bzr pull -Dhpss [13:27] No revisions to pull. [13:27] HPSS calls: 9 [13:27] now trying push [13:28] jelmer: or get rid of it on the assumption that it is in fact dead code, but then you'll have to propose a solid explanation that it was never needed [13:28] ploum: ghaaa, of course I meant push :) [13:28] I was not sure if you wanted some information [13:28] ploum: sry [13:28] so I broke the lock (as you said) [13:28] no problem, thanks for trying to help me :-) [13:28] vila: my point is, if I make get_username() raise NotATerminal then I can't test it [13:29] vila: and I have to add a mock implementation of it like get_non_echoed_pw() [13:31] wb vila (-: [13:31] jelmer: haaaa, sry, then you should refactor get_non_echoed_password in both implementations [13:31] jelmer: darn ctrl-w again :) [13:32] vila: refactor get_non_echoed_password? [13:33] the purpose of get_n_e_p in TestUI is to get rid of the 'echo' constraint, it's a side-effect if it doesn't raise NotATerminal :) [13:33] vila: but we won't have a terminal during the tests [13:34] jelmer: I get that and we don't want to raise NotAterminal in most of the cases [13:34] jelmer: let start again [13:34] when get_username|password is called by bzr, we should raise NotATerminal if indeed there is no terminal to query the user [13:35] when testing, we don't want to check that *of course* except to test tht NotATerminal is raised but not the rest of the behavior [13:35] vila: [13:35] bzr: ERROR: Could not acquire lock "(remote lock)" [13:35] HPSS calls: 10 [13:35] but I did break-lock before [13:35] ploum: are you alone using that repository ? [13:37] oh wait! [13:37] I had to break the lock on the server [13:37] not on the client [13:37] vila: ahh [13:37] ploum: both, but don't do that if someelse is using that repo [13:37] jelmer: haaa too :) [13:38] maybe should I report a bug so : [13:38] 1) There's less delay when you cannot acquire a lock [13:38] 2) It's more explicit about locks [13:38] vila: so we should have a helper for get_username() that gets overridden in TestUIFactory and just does checking for whether there's a terminal? [13:38] vila: I'm alone on that repository [13:39] ploum: ok, so a bare 'bzr break-lock' should propose you to break both locks except if you mess things up before by breaking only the remote one [13:39] jelmer: TestUIFactory shouldn't raise NotATerminal, it's here to be used *without* a terminal anyway, there should be another test for checking NotATerminal [13:40] vila: I think so [13:40] which doesn't use TestUIFactory [13:40] not everyone a SSH access to the repository [13:40] jelmer: whether there is a single method in [Test]UIFactory to handle that is up to the first dev that needs it :-) [13:41] ploum: 'not everyone' is not exactly the same as 'only ploum' :) [13:43] vila: indeed. I mean : I have ssh access to my repository so I can break a lock if needed but what about people that cannot do that ? [13:44] ploum: if they can't write they can't lock [13:44] if they can't lock they don't need to break locks [13:44] but if you use bzr+http, you can create a lock [13:44] without being able to breaking it [13:44] if you use bzr+http you can lock and you can break locks [13:45] that's why I didn't understood you [13:45] I was not aware of that [13:45] ploum: you do 'bzr break-lock bzr+http://whatever [13:45] I logged into the server with SSH to break lock at that place [13:45] sorry [13:45] thanks for the information [13:45] ploum: np [13:47] thanks for the help [13:47] I managed to push my commits [13:47] jelmer: so basically I think prompt() should take care of NotATerminal *and* prompt encoding and then only prompt needs to be redefined in TestUiFactory [13:48] jelmer: it sounds rather unfortunate that this was done by get_password so far... [13:50] vila: well, get_password() doesn't use prompt() afaik [13:50] since getpass() prints the prompt for it [13:50] jelmer: that's one facet of the bug :) [13:50] it should use self.prompt and then pass an empty prompt to getpass [13:51] vila: but would it be ok for now to just raise NotATerminal from get_username() ? [13:53] jelmer: you mean 'I found a bug, but I'd like to not fix it now but instead duplicate the bogus code, is that ok' ? :-) [13:53] basically, yes :-) [13:55] jelmer: hmmm, I can fix it, but then we'll conflict, wait a minute [13:55] Mmph. I wish there were a way to pass defaults to log formatters... [13:56] fullermd: nag igc or better expose your use case to the ML, this is under discussion [13:57] Well, my use case is that I WANT to see the merge revs on --long all the time :p [13:57] "Undo what you did" is rather obstreperous naggery. [13:58] fullermd: 'My preferred use case is not the default one anymore' is a valid user feedback in my book [13:59] fullermd: and when it comes to UI tweaks, user feedback is *gold* [14:00] fullermd++ [14:01] Peng_: mail-the-ML++ [14:02] log and log formatters are actively worked on, the more feedback we get.... [14:02] I think I'm over my quota of griping-ish mails to the ML for one day. [14:02] fullermd: quota++ [14:02] vila: Sorry, I just hit my quota of getting off my ass and doing things for the week. [14:03] Peng_: quota++ [14:03] Exception: IntegerOverflow [14:03] Sorry, it's limited to a 2-bit signed int. [14:07] vila: ok [14:09] huys, when is support for "Doesn't matter the EOL format" coming? [14:10] antoranz: ...1.14? [14:11] antoranz: It should land in bzr.dev, uh, yesterday or tomorrow or something. [14:11] really? cause I had read about this feature coming like... a year ago... and I just made a lousy test and it failed miserably [14:12] antoranz: It's been in progress for ages. [14:13] and it's really coming in 1.14? or it's just a guess? [14:14] antoranz: The required infrastructure has already been merged. The EOL stuff itself has either been merged, is up for review, or is projected to be up for review within 48 hours; I don't remember which. [14:15] ok.... sounds like it's coming finally [14:18] by the way... did you hear that microsoft is using git for version control? http://www.fsdaily.com/HighEnd/Microsoft_uses_git_for_version_control [14:27] antoranz: It's possible that MS *is* using git, but that article is an april fools' joke. [14:27] damn! am I so obvious? :-) [14:29] hi guys.. I am having some issues with merges.. [14:29] the thing is I have two svn repos [14:29] I need to merge [14:29] i tried to use bzr for this [14:29] I created a bzr branch for each branch in the svn repos [14:30] then I tried to merge between the bzr branches [14:30] and I got the error bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. [14:30] ricardokirkner: svn repositories or svn branches? [14:31] ricardokirkner: I mean, do they have shared history? [14:31] jelmer, I have an upstream repo with branch A and a local repo with branch B (which is a copy of branch A from upstream) [14:31] I have worked locally on branch B and now I want to push to upstream [14:31] the thing is, the whole development started out with svn, and before being able to change our workflow, I need to push these changes to upstream first [14:32] ricardokirkner: upstream svn repo and local svn repo? [14:32] and I would like to preserve history [14:32] jelmer, yes [14:32] ricardokirkner: but how was branch B originally created from branch A? [14:33] jelmer, as far as I remember, svn export ; svn import [14:33] I know its not ideal, and that is the reason why bzr cannot find a common ancestor [14:34] but, cannot it be told to be 'more intelligente' :-) [14:34] ? [14:34] ricardokirkner: you can force bazaar to do the merge by using the "-r0..-1" argument to merge [14:34] ricardokirkner: but it'll most likely result in a large number of conflicts [14:34] That sounds like it would yield a staggeringly terrible result... [14:34] as there is no shared history information [14:35] jelmer, I try and let you know [14:54] moin mwhudson [14:54] hi jelmer [15:53] vila: it's a test isolation problem. The tests don't clear the msgeditor hooks. [15:53] they aren't registered in hooks.known_hooks, but that registry is a little underdocumented [16:08] jelmer, what's the deal with bug 336749? [16:08] Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [Undecided,Invalid] https://launchpad.net/bugs/336749 [16:08] ted is getting desperate :) [16:12] beuno: it's a bug in ghost handling in VersionedFiles [16:13] beuno: if you add a text with a ghost parent it blows up when re-extracting that text [16:13] jelmer, so I need to chase lifeless about it? [16:13] beuno: yeah [16:14] jelmer, thanks [16:14] beuno: I tried to see if I could figure out what was causing it, but couldn't easily find the issue [16:14] I'm also not too sure what's happening exactly when storing packs [16:15] inkscape is in a bad situation because of it, because they're last import is broken [16:15] something somewhere is assuming that the delta parent is the left hand side parent [16:15] yeah, so I've understood [16:15] so they're in a situation where they either manage to do the import, or have to switch or something [16:15] LarstiQ has a similar issue with his company repo [16:15] and there are more people that have hit this problem [16:19] beuno: I've marked this particular bug as High already earlier this month [16:19] jelmer: sorry, longer than anticipated and phone calls too, digging the subject anyway, I end up getting rid of NotATerminal anyway, so forget about it, but add the tests for utf8 (unless you know better about what encoding should be used for unicode usernames) [16:20] vila: ok [16:20] jelmer, yeah, saw it, thanks. I'll start chasing people and see where that gets me :) [16:20] jelmer: I'll submit something about NotATerminal [16:21] vila: I'll send a new merge request to the list if that's ok [16:21] see you there :) [16:22] james_w: which tests don't clear ? yours ? bzr ones ? someone else tests ? [16:25] vila: the general bzr test setup [16:26] it clears all the know hooks so that doing say "commit" in a test doesn't trigger hooks [16:26] but fails to clear this hook, so my code runs. The test that fails shouldn't actually run any of the plugin code at all, so that's the real bug. [16:30] james_w: ok, you should file a bug (I'm surprised commit hooks are not registered, but there may be a reason), anyway in the mean time you can also protect you own code, see bzrlib/tests/test_msgeditor.py test_generate_commit_message_template_hook [16:31] yeah [16:43] jelmer: before I forget ! Make a big fat item in NEWS as GUIs will have to implement get_username now [16:46] jelmer: and also: regarding defaulting to getpass.getuser(), I think the easiest it to make get_username prompts only if asked (i.e. not prompt by default) grepping for getpass.getuser will give you the call sites, only http doesn't care anymore [16:50] james_w: hooks.known_hooks is a recent addition, *because* of issues like this [16:51] (there were other hook instances *inside* bzrlib that were being missed) [16:52] sure, I realise that, I'm just trying to work out what to add to it to register this hook point [16:54] james_w: not 100% sure, but basically something like "bzrlib.branch", "Branch.hooks" [16:55] so ,