[00:09] igc: want to take a second look at https://code.edge.launchpad.net/~patrick-regan/bzr/lp-quicktutorial/+merge/15073? I think it looks good now. [00:12] spiv: done [00:16] igc: thanks! [00:33] spiv: I have a suggestion for pqm-submit [00:33] spiv: let it take a lp merge request url. [00:35] lifeless: +1 [01:37] lifeless: any comments on bug 488544 [01:37] Launchpad bug 488544 in launchpad-code "unclear meaning of resubmit action" [Undecided,New] https://launchpad.net/bugs/488544 [01:49] poolie: yes, commented. [01:49] heh [01:50] expected you to say "yes, that bug has comments" :-) [01:50] I'm not quite that harsh:) === jelmer_ is now known as jelmer [03:21] * igc lunch [03:45] Heh, I made push default to --no-strict, and it just bit me. :D [03:57] bzr alias oops='merge --uncommitted ../trunk' [03:58] getting bzr revert ../trunk in there would also be good [04:03] mwhudson: this is another reason to use a single checkout :) [04:04] yes, i guess that's true [04:04] lifeless: do you prefer merge proposals to already have NEWS in them, or is best to add that at the last minute, given the potential for conflicts? [04:06] the former [04:11] * mwhudson proposes a merge [04:15] poolie: I have a suggestion for your lp scripts [04:15] mwhudson: you can always resolve it later [04:15] ok [04:15] poolie: 'add an approve for folk in the bzr team' [04:15] so that e.g. your proposals show up with 1 approval by default, once the script runs. [04:15] non-canonical people in ~bzr? [04:16] hm, i might be confused [04:16] which script? [04:16] well you're writing lpapi scripts to help bzr get more out of lp, right? [04:16] ok, this is a new but similar script? [04:16] yes [04:16] interesting [04:16] thats the policy we still have that LP doesn't know about. [04:17] alternatively the robot could just complain about things that have had N reviews but not changed status [04:17] thats also interesting to do, and different. [04:17] so I wouldn't say its an alternative. [04:18] would just adding those votes really add value? [04:19] poolie: I think so. At the moment I have to read two columns: author and votes. [04:20] if I knew that proposals from committers would have the committers vote present in the votes column,I could scan faster. [04:21] hm [04:21] i'll think about it [04:21] you can prototype this by manually voting +1 on your own things [04:21] its only a suggestion ;) [04:21] hmm, the script would have to run as 'root-alike' I guess. [04:21] because it would want to impersonate the committer. [04:22] thumper: ^ would be nice to be able to do the above experiment. [04:23] lifeless: thanks for the review [04:32] lifeless: quick call? [04:32] sure [04:49] hello all [04:57] Hi. :) [05:26] poolie: btw https://code.edge.launchpad.net/~lifeless/testtools/0.9.1/+merge/15256 [05:42] poolie: thanks for the review. [05:42] thanks for doing it [05:42] poolie: I think I was more saying 'this is the outcome' [05:43] do you think its more tasteful like this? [05:43] i do [05:43] cool [05:43] i think it's less likely to lead to that kind of failure [05:43] i guess we can see if jml agrees [05:44] I discussed doing a point release with him before doing the change. [05:44] I'm confident he won't object to the content of the change. [06:35] lifeless: do you have any ideas about https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/434987 [06:35] Launchpad bug 434987 in devscripts "chdist fails with "E: Internal Error, Could not perform immediate configuration (2) on libattr1"" [Undecided,New] [06:35] ideally, a way to work around it [07:28] hi all ! [07:30] Whoop, that must mean it's time for me to go :p [07:32] hehe, enjoy your night fullermd :) [07:33] Oh, it's hardly night, not for many many hours yet... [07:33] I just got through my post-breakfast stuff. [07:33] oooh, you meant go *to* work, sorry for the misunderstanding [07:44] hi vila [07:46] hey :) [07:54] vila, so how about if you add the comments for shelve-no-tty and merge it? [07:55] poolie: fair enough, I'll do that (<- spiv) === loxs_wrk is now known as loxs [08:31] ping jml, spiv [08:31] jml, spiv: can we get the emacs mirror on LP updated? [08:32] see https://code.edge.launchpad.net/~vcs-imports/emacs/trunk [08:32] the new url is http://bzr.savannah.gnu.org/r/emacs/trunk/ [08:32] igc, what should it be updated to? [08:32] jml: how would I change that? [08:32] jml: do I need to join some team? [08:33] to get permission? [08:33] igc, you need to be in ~vcs-imports. I've changed it. [08:33] * jml is not here [08:37] jml who is not there, can you re-enable that import too? It says Next mirror: Disabled [08:38] igc, I have re-enabled it. [08:39] but then it gets disabled again very quickly [08:39] something is fishfy [08:39] fishy [08:45] wtf [08:45] why [08:45] is that owned by ~vcs-imports? [08:45] Hi! While it's still some time off, I'm starting to think about trac-bzr 0.3.x releases. Have just registered a series in lp. [08:46] (it doesn't seem like it is an import branch though) [08:46] Now I wonder: should there be beta milestones before the official releases? Would there be enough of a user base to get actual beta-testing done? [08:46] Or would simply asking people around here to give latest checkouts a try be enough of a test so I could simply start with 0.3.0? [08:47] MvG: hi, are you about trac-bzr? [08:47] bialix: Yes. [08:48] given in mind there was no release at all in the past, I'd say you can just cut tarball and move forward. [08:48] i.e. do release, or don't [08:48] beta is overkill right now [08:49] Glad you think so. Will certainly serve me a lot of worries. [08:51] those who used trac-bzr already used to use trunk [08:51] (how's bad I said :-/) [08:52] mwhudson, I might have changed the owner way back when [08:52] mwhudson, a more interesting question to me is, "why does it apparently retry and then still fail with an error message referring to the old branch location" [08:53] jml: yeah, that's a bit odd [08:56] * jml drinks something awesome that rhymes with "banoffee" [08:58] mwhudson, I'm torn between investigating it, and not. [09:09] hi jml [09:09] jml: https://code.edge.launchpad.net/~vcs-imports/emacs/trunk seems happier now [09:10] not happy [09:10] just happier [09:10] mwhudson, looks happyish [09:10] let's leave it for 6 hours and see what happens :-) [09:11] or kill it and start again [09:11] mwhudson, the dates on the 'recent revision' thing seem a little off :) [09:11] yeah [09:12] (weird, years used to begin with a 1 and no one cared) [09:12] poolie, hi [09:14] jml: loggerhead seems to have a more plausible idea of the revisions [09:14] i wonder if it's choking the scanner [09:15] poolie, fwiw, I think that food prepared from _Lobscouse and Spotted Dog_ makes more sense over here. [09:16] mwhudson, I'll bet its choking the scanner. [09:16] it's [09:18] jml, i bet [09:47] poolie: re: devscripts, not offhand, let me have a look [09:47] nm [09:47] i'm sending a mail summarizing where i got up to [09:51] anyhow, I'd be using schroot fwiw [09:55] lp devscripts? [10:38] * bialix hates to get random errors in the tests with sftp testing server like this: PermissionDenied: Permission denied: "lock/held": [Errno 13] Permission denied === kostja_o1ipov is now known as kostja_osipov [10:43] Hello [10:44] could somebody help me with bzr gannotate? [10:44] what I actually need is to find out the revision id of a changeset that deletes lines [10:45] since the lines are not in annotate output, I can't find the revision [10:45] what is the procedure for that in bzr? [10:45] I'm doubt there is simple way to find deleted lines [10:45] they are deleted [10:45] maybe hgrep plugin will help? [10:45] or log -p? [10:46] oh well... there of course is. you scroll back in the revision history, till you find the changeset that still has the lines [10:46] the next changeset removes them [10:46] but it can be quite tedious [10:46] I won't call this way "simple" [10:46] would be nice if I could see all revisions in a file on a time line so that I could do binary search on it [10:47] you're need weave representation it seems [10:47] you may want to ask jam when he'll be here === lionel__ is now known as lionel [11:17] kostja_osipov: bzr qannotate provides the per-file graph, i.e. displays all the revisions that modify a file one way or another [11:21] gnight [11:26] vila: it's not quite true: this graph is sorted and represents only revisions which modified lines in currently annotated version. but if you go back in history and annotate older versions you'll get more graph [11:27] bonjour vila, btw :-) [11:27] bialix: hi ! [11:27] bialix: you're right, I keep forgetting the difference :-( [11:28] bialix: I should really talk to garry about *not* using that graph but presenting the real per-file graph instead, I'm pretty sure the performance penalty will be lost in the noise [11:28] vila: sometimes I have the same needs as kostja_osipov, I'm still not found easy way to bisect this [11:29] vila: you can, but actually this feature done not from performance point of view [11:29] I guess it's intended [11:30] but as we see, sometimes this approach has flaws [11:30] file a bug! [11:30] please [12:03] hello [12:03] lol [12:04] sometimes i work on a project with someone else. Now i'd like to do some kind of version control, he's been looking into bzr already. [12:05] It's a webbased project (cakephp) and we're working on the same files every now and then, can this be controlled with bzr? [12:06] yes [12:06] in a variety of ways [12:06] ok, will need to go into some tuts i guess [12:07] probably. [12:07] stanman246, have you used a version control tool before? [12:07] no [12:09] stanman246, the big difference from just editing files is that rather than just hitting "save", you can group changes together in a single "commit", which generally also has a short description of the change [12:09] come across Git, hows that? [12:09] stanman246, roughly speaking it has feature parity with Bazaar. I find it's UI more complex and less helpful. [12:10] jml: yes, so i saw [12:10] ah [12:10] but... bzr is working with .bzr folders locally right? [12:10] stanman246, yes, kind of, but that seems an odd question to ask. [12:11] really need to tut first, before asking, sry [12:11] stanman246, are you and your colleague editing PHP files on the web server itself? [12:11] not at first [12:12] stanman246, ok. [12:12] that's good :) [12:12] we used to use winscp to get the files, edit them and then up them [12:13] but with bzr we could edit the files on the server right? [12:13] I don't feel really comfy with that thos [12:14] it's not a good way of doing things. [12:14] VCS makes it slightly easier to separate changing the code from doing a release, IMO. [12:14] and changing files onto the webserver in the web area is basically doing a release [12:16] anyway, here's what I'd do to start with: [12:17] make a copy of your code. [12:17] local [12:17] right [12:17] ? [12:17] for now, anywhere. [12:18] just make sure you have a copy in case everything goes horribly wrong [12:18] but also have a copy that you can change into and run 'bzr init' then 'bzr add' and then 'bzr commit' [12:19] this makes a branch that you can play with [12:20] if you put that branch onto the server (either by copying it or running 'bzr push' or something) then you can either check it out ('bzr checkout') or branch it ('bzr branch') [12:49] vila: thanks, I actually used bzr log -p and was able to dig up the changeset i need [12:49] kostja_osipov: cool, did you succeed with your cherry-picks yesterday ? [12:50] vila: i'm still in progress. [12:50] I am reapplying the first patch in a series, and it touches 40 files and each file has conflicts. [12:50] our problem yesterday was a bit of a bit larger puzzle :) [12:51] hmm, so you're back to doing the *first* merge without using patch -p0 ? [13:13] hey all, I'm seeing the error "not installing http[s]+webdav:// support (only supported for bzr 1.12 and above)" on every command i run. any ideas why this is happening and how to fix? running bzr 2.0.0 [13:17] hi i have a question [13:17] i have two repos one or locally connected server [13:17] and other on my local host [13:18] maxb: ping [13:19] pong [13:20] maxb: do you remember your patch for qlog to preserve leading spaces? [13:20] yes [13:20] and the problem is: [13:20] does it still work for you with latest qbzr trunk? [13:20] i first branched from server to my localhost [13:20] than edited few files [13:20] then comited locally [13:21] maxb: when I've merged your patch I've added the test. Now this test started to fail [13:21] bialix: oh. no, it doesn't [13:21] and i can see status "unknown" in olive ide... do you know what does that mean? [13:21] maxb: you've asked me why I want test for such small thing. that is. [13:21] bialix: Your point is proven! :-) [13:21] can we pair to fix it? [13:22] I need to grab lunch now. I will look at it in a few hours [13:22] ok, ping me when you'll have a time [13:23] marek_: any reason to not use bzr-explorer? [13:24] no reasons [13:24] :) [13:25] marek_: I don't see a log of your questions but I can help with explorer, not with olive [13:28] maxb: when you'll back: here is my branch with updated test: lp:~bialix/qbzr/htmlize-nbsp [13:46] To anyone interested in trac-bzr: I've got 7 propesed merges waiting for review at https://code.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges . I'd be glad if at least some of them would have a second pair of eyes looking at them before I commit them to trunk. Thanks! === verterok_ is now known as verterok [13:48] abentley, mzz: of course past contributors are particularly likely candidates for such reviews, so if you can spare the time... [13:49] MvG: sorry, but I have no interest in trac-bzr anymore. [13:50] abentley: all right, noted. Won't bother you with this in the future. [13:54] maxb: I found the root of problem, but the fix is not so trivial... [14:05] maxb: fixed and pushed to trunk2a. testing are welcome [14:06] hi, i've got ubuntu 9.04 running and installed bzr [14:07] but the version is 1.13.1 and my colleague has the repository set up on v 2.0, can i upgrade my bzr version? [14:11] stanman246: you can use the bzr PPA [14:11] stanman246: There is a bzr PPA that carries the latest released version of bzr, bzrtools and a few other things [14:12] stanman246: https://launchpad.net/~bzr/+archive [14:12] stanman246: or you can upgrade to 9.10 :) [14:16] haha [14:16] thinking of that... [14:16] hey, 9.10 is awesome [14:16] the later is a couple of clicks away while the former requires a bit more work :) [14:16] it drives my T400s just fine [14:17] I think the only feature of the laptop that does not work is the "silence the mic" button [14:17] but i bet i could make that work too if i would care :) [14:23] hmm... on my hp 6720s 9.10 didn't work with compiz.. [14:23] just did the ppa upgrade to 2.0.2! [14:27] ok, now i'm gonna read some! Thanks for the info! [14:57] bialix: Are you still working on https://bugs.launchpad.net/trac-bzr/+bug/327508 as that report is assigned to you? [14:57] Launchpad bug 327508 in trac-bzr "[wishlist] add Bazaar Location link to the contextual navigation under Browse Source" [Undecided,New] [14:58] MvG: oh, no sorry, I'm not [14:58] bialix: I guess I'll then reasissign to nobody. [14:58] vila, email2blog: http://beuno.com.ar/archives/168 [14:58] yes, please [14:59] MvG: too bad for me, I was too busy since 2009/03 until now [14:59] beuno: hehe [15:01] push --no-strict :-P [15:01] bzr upload-files FILES --no-strict :-P :-P [15:01] bzr upload-files --jfdi? [15:03] --jdi? perhaps [15:03] oh, got it [15:05] :) [15:05] it's the ruder version [15:08] And the subliminal message is: vila, http://beuno.com.ar/archives/168, now, jdfi [15:08] :-D [15:09] vila, I'm glad that got through ;) [15:09] ha ha ha [15:58] bzr clone lp:~rocky-burt/trac-bzr/bug-263300 fails for me. Seems that the launchpad bzr server for some reason isn't happy: [15:58] bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('TREE_ROOT', 'bialix@ukr.net-20090118015300-t997i4a3wn3jjpr2')") [15:58] Any ideas? Is this a launchpad issue or a bzr issue? [16:03] vila: Bug #488824 [16:03] Launchpad bug 488824 in qbzr "qannotate: don't filter log of revisions" [Medium,Confirmed] https://launchpad.net/bugs/488824 [16:04] bialix: lp:~bialix/bzr/shelve-no-tty make the test suite fail :-/ [16:04] details? [16:04] shelve --all / shelve --list ? [16:05] blackbox.test_shelve.TestShelveRelpath.test_shelve_in_subdir blackbox.test_shelve.TestShelveList.test_shelve_destroy [16:05] * bialix looks [16:05] it took me a while to notice because pqm send me a truncated mail for the first failure and I didn't notice the mail at first either [16:06] shelve --all [16:06] so.... [16:06] vila, I think plan B then [16:07] hmm, weird, pqm fails for the second one only while both fail here.. [16:07] what is plan B / [16:07] what is plan B ? [16:07] oh and thanks for filing that bug, I went to lunch and forgot :-/ [16:08] you reject my patch and I provide new patch which will check tty presence in osutils around lines def getchar(): return msvcrt.getch() === beuno is now known as beuno-lunch [16:08] vila: shame on you [16:09] but lunch is the most important, so ok [16:09] vila: but I'll need your help for testing linux-specific getchar() [16:09] hmm, I don't think that will work, there are cases where we want to read from stdin being a file and that's a valid use case [16:09] msvcrt.getchar() never read from stdin [16:10] this is direct access to keyboard buffer [16:10] but it's windows specific [16:10] so what? [16:10] this is the root of my problem and why this patch is created [16:10] so that doesn't match the cover letter of your patch that wasn't windows specific [16:11] vila: because I have no way to test shelve in qrun on non-windows [16:11] can you? [16:11] anybody? [16:11] * bialix screams: HEEELP [16:12] vila: osutils.py around line 1900 [16:13] * bialix has no idea how linux part works, tty and termios not his area of expert [16:14] * bialix trying to prepare non-qt test [16:15] bialix: how about transfering your patch to shelf_ui.Shelver.prompt instead ? [16:16] so you don't have to check at two different places... or in getchar() but making the os specific versions pushed down to _getchar() ? [16:16] this is possible [16:17] I'm clearly get lost in shelf_ui [16:17] usage of sys.stdout makes me nervous [16:17] getchar() is used only prompt() but it seems to require a real terminal anyway [16:17] hi GaryvdM [16:18] privet Gary [16:18] that means hi [16:18] Hi bialix, vila [16:18] hi GaryvdM [16:18] vila: your chance to say about log in annotate! [16:18] hehe [16:19] joke [16:19] I've just stumbled with it myself [16:19] GaryvdM: bialix just filed bug #488824 about qblame not using a true per-file graph [16:19] Launchpad bug 488824 in qbzr "qannotate: don't filter log of revisions" [Medium,Confirmed] https://launchpad.net/bugs/488824 [16:19] GaryvdM: can you remind me why ? [16:20] vila: so ok, I'm agree moving my tty check to prompt [16:20] err, I mean [16:20] vila: Performance [16:20] vila: so I need resubmit or you reject or how? [16:20] vila: maybe have a right click - "Show all revisions that change this file" option [16:20] GaryvdM: I'm agree to have knob [16:20] bialix: just pushing the change to your branch should be enough [16:21] bialix: knob? [16:21] I want a plugin that has a pre_change_branch_tip hook, that I configure to run a test suit before I push to a specified location [16:21] That will be like a mini pqm that I can use for qbzr [16:21] GaryvdM: that shouldn't be a perf problem, we do that for bzr log FILE by finding the relevant keys in the index [16:21] GaryvdM: checkbox [16:22] vila: Yes - but it is still slower than just taking the list of revisions from the annotate [16:22] bialix: ok - I see [16:22] GaryvdM: or context menu -- does not matter [16:22] GaryvdM: hook? I can do it [16:23] GaryvdM: hmm, faster but incorrect :-) It will be nice if you could do it in the background after displaying the first page :-D [16:23] Does such a plugin exist, or should I write one from scratch? [16:24] GaryvdM: it would be pretty trivial [16:24] vila: can I ask about tree.is_ignored? [16:24] vila: Yes - I can do it after the annotate has been shown. [16:25] But I'm still a bit surprised that querying the index only makes such a difference compared to the annotation time... anyway, you know better, but we had a use case this morning that your current implementation doesn't help (I thought it was): [16:25] it was afternoon [16:25] searching for deleted lines can be done only if all revisions are displayed in the graph [16:25] vila: yes [16:25] bialix: before my lunch is morning :-) [16:26] bialix: even if I take it at seven PM :D [16:26] yep, I'm a bit distracted [16:26] :-D [16:26] LOL [16:26] bialix: what about trees.is_ignored ? [16:28] I think the name is awfully misleading [16:28] so I think is it worth to starting patch or just forget [16:28] this method does not check is file actually ignored [16:29] it returns matching ignore pattern only [16:29] that's what the docstring says [16:30] so if file versioned but matches ignore pattern -- this function name is wrong [16:30] >-/ [16:30] docstring said: Check whether the filename is ignored by this tree. [16:30] What will be a better name ? [16:30] this is not true [16:30] bialix: look at the workingtree one [16:30] better name: something about ignore pattern [16:31] Check whether the filename matches an ignore pattern. [16:31] ECONFLICT [16:31] but anyway, my point still valid [16:32] function name is not correct [16:32] it's counterintuitive for API users (QBzr) [16:32] I've just yesterday fixed serious bug because of this [16:32] I don't follow. What are you searching for ? [16:33] There is no such thing as an ignored file. If you want to be pedantic you should say: will that file be ignored if I try to add it *now*. [16:34] That's what wt.is_ignored() answers [16:35] vila: we understood it to be "is this file ignored" [16:35] Hmm, not even [16:35] But what does that mean ? [16:36] wt.would_be_ignored() vs wt.is_being_ignored() maybe? [16:36] vila: The bug fix that bialix was taking about = "is_ignored = not versioned and tree.is_ingored()" [16:37] gioele: yes [16:38] vila: WorkingTree subclass MutabkeTree which in turn subclass tree.Tree [16:38] tree.Tree is therefore defined interface IIUC [16:38] and interface in tree.Tree said that is_ignored checks is file actually ignored [16:39] I suppose somewhere along the road original meaning has lost [16:39] and now is_ignored means is_matches_ignore_pattern [16:39] Sounds right [16:39] so to remove confusion in weak minds like mine and I have proposal to change method name [16:40] bialix: good, you understand that means taking care about deprecating the old name right ? [16:40] yes, [16:41] that's why I'm trying to talk with some of core devs first [16:41] IIUC such change is too big for 2.1.0rc [16:41] so better to make it after 2.1.0 gone glod [16:42] right? [16:42] That's for the 2.1 RM to decide, don't worry too much about it, that's why we have deprecations for [16:43] this function is very heavily used [16:43] and not only inside bzrlib [16:43] but and by 3rd party tools, I guess [16:43] at least in QBzr definitely [16:44] I will worry too much [16:44] Then maybe only the doc should be fixed ? [16:44] mmmm, no. all or nothing [16:45] the name is misleading in my humble opinion [16:45] lol, is that how you negotiate ? [16:45]