[00:00] Peng_, you broke bzr/lp indirectly, ^ is your commit :p [00:00] lifeless: I just reviewed the "Review Feedback" post [00:00] hello, from what I am reading, nautilus-bzr should be installer w/ bzr-gtk... this is not obvious if I look at my menu items :) is there a doc somewhere about nautilus-bzr ? [00:00] s/installer/installed [00:01] chevdor, you should see icons overlayed when you browse a versioned directory with nautilus [00:01] beuno, ... but I don't :) [00:01] chevdor, what version of bzr-gtk have you installed? [00:01] beuno, this is why I am asking, I'd like to know what/where to search for a problem [00:02] beuno, gtk 0.93.0 [00:02] beuno: just push, no need for --overwrite [00:03] chevdor, ah, it's disabled in 0.93. I'd recommend installing 0.95, which was released today [00:03] thanks jam [00:04] beuno, ahhh ok that explains :) I'll go to bed then and get the trunk tomorrow, thanks for your help, i can't wait to see that :) [00:04] chevdor, np. G'night [00:04] jam: but you didn't do bb:approve :P [00:04] beuno, thx, ++ [00:05] lifeless: I think I did [00:05] http://rafb.net/p/uRBIHU22.html [00:05] Peng_, revision 192 of loggerhead thanks you for your contribution [00:06] mornin' poolie [00:06] hello beuno, lifeless [00:07] lifeless: there's a review with vote as well [00:07] hey poolie [00:08] ah [00:08] its not in my inbox :( [00:08] found it [00:08] thanks james_w [00:08] and jam [00:10] spiv: bug 254797 [00:10] Launchpad bug 254797 in bzr "traceback when branching from bzr+http" [Undecided,New] https://launchpad.net/bugs/254797 [00:10] spiv: I'm thinking a whole in the interface tests or something ? [00:23] Now https://code.launchpad.net/~loggerhead-team/loggerhead/trunk gives the "Pack already exists" error. [00:23] Peng_, try again, I got the same when committing [00:23] it's something wrong with auto-packing [00:24] oh, wait, branch is b0rked in LP [00:24] * beuno pokes lifeless [00:24] :) [00:24] hrm, my commit didn't go through, even though bzr said it did [00:25] Finally, I'm not the only one with a broken branc. :) [00:25] LOL [00:26] * beuno wonders if bzr pack lp:loggerhead fixes it [00:36] Peng_, what happens if you pull from lp:loggerhead? do you get revno 192? [00:36] ok, bzr pack fixed it [00:36] ...Yeah, I just did it, and it worked. [00:37] Before then, it just said no new changes. [00:37] Peng_, cool, everything should be back to normal then [00:38] :) [00:42] lifeless: nearly done with the review; I found a test bug [00:42] lifeless: and I agree, that bzr+http bug does suggest we have a hole in our tests [00:43] spiv: the iter_changes ordering assumption? [00:43] spiv: cause I think thats actually not a bug :P; we do directory-at-a-time for performance everywhere [00:44] lifeless: the 'bzr added' output ordering assumption [00:44] lifeless: and it is a bug, because I get an intermittent test failure [00:45] :) [00:45] oh, ok [00:45] thanks! [00:53] has the mailing list just started sending copies of messages if you are also getting them directly? [01:00] james_w, i have not changed it to do that === poolie_ is now known as poolie [01:00] was there perhaps an upgrade? [01:00] maybe it's something else [01:01] there wasn't a mailman upgrade [01:01] it's a per list &| user setting though [01:02] I'll see if it continues, or it was something else === edcrypt1 is now known as edcrypt [01:07] if i remove a branch / checkout from a shared repo, can i remove that branch's info from the repo store? [01:09] hm, i am probably using shared repo incorrectly, perhaps i should have one for each distinct remote repo, or project, just to share its' branches, so i wont have to worry about this.. [01:11] meteoroid, when you remove a branch from a shared repo, it's revisions are still there. The only workaround I know if is creating a new shared repo, and branching everything you want to keep into the new one, discard the old one [01:11] beuno: that's what i figured.. [01:12] so, e.g. for svn, i should probably share one repo for each svn repo root. [01:12] meteoroid, yes, I use a different shared repo for each project, which will msot likely share it's history [01:13] makes sense.. [01:29] === modified file 'bzrlib/tests/test_options.py' [01:29] --- bzrlib/tests/test_options.py 2007-09-03 01:50:29 +0000 [01:29] +++ bzrlib/tests/test_options.py 2008-08-05 00:29:05 +0000 [01:29] @@ -81,8 +81,7 @@ [01:29] [01:29] def test_allow_dash(self): [01:29] """Test that we can pass a plain '-' as an argument.""" [01:29] - self.assertEqual( [01:29] - (['-'], {'fixes': []}), parse_args(cmd_commit(), ['-'])) [01:29] + self.assertEqual((['-']), parse_args(cmd_commit(), ['-'])[0]) [01:29] [01:29] spiv: ^ [01:30] I think the test was overly sensitive; it fails on my 3117 merge [01:30] spiv: what do you think ? [01:36] lifeless: looking... [01:36] I nearly JFDIid it [01:36] lifeless: I agree [01:37] there are more in that file [01:37] cmd_commit :( [01:37] I'll put a XXX there [01:39] Really test_options shouldn't be relying on cmd_* classes in builtins. [01:40] thats what my XXX says :) [01:40] # XXX: Using cmd_commit makes these tests overly sensitive to changes [01:40] # to cmd_commit, when they are meant to be about option parsing in [01:40] # general. [01:40] Hmm, it imports cmd_log and cmd_status, but doesn't use them. [01:40] fixed [01:41] sending again [01:41] pyflakes reports that 'builtins', 'repository', 'symbol_versioning' and 'Command' are also unused, if you want to clean it up more... [01:43] done [01:44] thanks [01:44] jam: ping [01:59] james_w, i would guess that you used a different sender address from the subscribed address [02:00] poolie: aha! thanks, that explains it. [02:01] all: what do you think of sending the standup notes to the bazaar list? [02:01] would it be too much noise? [02:01] I think Rob's mailer might have switched addresses for me when replying [02:02] i guess it's just one more message out of a couple of dozen per day [02:03] poolie: I think some of them are relevant, some not. [02:04] I'd suggest blogging or twittering for that sort of unfocused stuff though [02:04] or getting people to send mail individually about what they're doing [02:04] which we do:) [02:09] I guess what I really mean is [02:10] if you feel that theres a canonical internal-knowledge-thing happening; perhaps stop doing daily status reports for the team internally; forcing that communication back onto the regular channels ? [02:15] lifeless, any news about bzr-gtk pqm? [02:15] no, thanks for reminidng me [02:18] Ug. 1.6r3 requires a version of python central that doesn't exist on gutsy? Boo! [02:18] b3, rather [02:18] awmcclain, really? i wonder why? [02:19] from the ppa i assume you mean? [02:19] Maybe I'm doing something wrong. [02:19] oh i see [02:19] he following packages have unmet dependencies: [02:19] bzr: Depends: python-central (>= 0.6.7) but 0.5.15ubuntu2 is to be installed [02:19] Correct. [02:19] i thought it would rebuild on gutsy but obviously not, would you please file a bug [02:19] sure thing [02:21] poolie: will changes to .dev land in 1.6 final at this point ? [02:22] yes [02:22] thanks [02:22] after i deal with your review to the upgrade test i'd like to make rc1 [02:22] i'll ask you to do pqm fu then [02:22] my desktop's video card is dying which is annoying [02:23] my windtendos sound card is sucking [02:30] poolie: I reopened the feisty bug which is the same. [02:30] grumble grumble [02:31] poolie, the copy package thing bit me last time too :/ [02:32] what are you guys doing? [02:32] I believe that someone pointed out that you should upload the oldest version (dapper probably), and copy dapper -> gutsy, dapper -> hardy, etc [02:33] lifeless, I *think* it's because we copied from hardy -> gutsy, etc, instead of starting from the bottom [02:33] or at least that's what cprov recommended if IIRC [02:33] erm [02:33] I didn't think you should *ever* copy between releases [02:34] uhm, then what's the copy feature for? [02:34] ubuntu never copies, the whole archive is rebuilt from release to release [02:34] not entirely true [02:34] they do copy sometimes [02:34] I don't know what the copy feature is for; but I can assert that packages from one release to another have no guarantee of working - [02:34] ABI changes, support tool changes etc [02:35] james_w: slangasek asserted to me that there is a full rebuild in the cycle for every release at this point in time [02:35] james_w: when I was last in London [02:35] copying between suites is differnet [02:35] don't PPAs support copying source (might work) or source+binary (will only work in very specific circumstances) [02:35] I've see hardy-proposed->intrepid [02:36] beuno, oh i see [02:36] about coping from oldest to newest [02:36] they support copying either source or binaries [02:37] I urge you to only copy source [02:37] poolie, that way it will depend on an older version instead of a newer [02:37] only one option works for this [02:37] beuno, yes, i see [02:37] what i mean is, the web ui gives an error if you choose one of the options, so only the other can be chosen [02:37] but myself I wouldn't copy at all, I'd use e.g. autoppa and upload each release independently [02:38] moving to autoppa is probably better [02:38] what's autoppa? [02:39] autoppa really isn't ready yet imo [02:39] and not just on sid [02:42] jelmer: maybe so, though there are folk using it heavily [02:43] lifeless, it does stuff like invoke "bzr revert" on each individual file in the source branch without asking [02:44] jelmer: I didn't claim perfection; I claimed that there are folk using it a lot [02:45] lifeless: (and I really mean use os.system("bzr revert ") for each file) [02:45] whoa [02:45] lol jkakar needs a cluebat then [02:46] jelmer, so what do you think we should do instead? manually update all the packages? [02:46] or write a custom script to do it? [02:46] well [02:46] I'd file more bugs on autoppa [02:46] Fix autoppa, ideally [02:46] I think the idea behind autoppa is nice and jkakar doesn't seem to be opposed to improving it :-) [02:48] Autoppa? Is that some holy grail that automatically builds packages for a variety of releases? [02:48] awmcclain: yes, that's the idea [02:48] Ooooo... [02:49] it can build *source* packages for various releases and uploads them to ppa [02:49] Oh, source is all I want. Is it released? [02:49] yeah, http://launchpad.net/autoppa [02:55] Is autoppa compatible with pdebuild or just debuild? [02:56] it just invokes debuild atm I think [02:56] mmm. it's written in python? [02:57] Looks like. I could hack that. Wow. I wish I would have known about this when I created 9 packages in my PPA. [02:57] x2 releases. [02:58] Is 1.6 a lot faster than 1.2 or 1.4? [02:58] (subject change) [02:58] a lot = noticably [02:59] *noticeably [02:59] I am interested in improving AutoPPA, a lot of it is hackish. [02:59] I already have a branch in progress to use bzrlib directly, but I'm stuck on a couple of issues. [03:00] jkakar: if we can help give us a shout [03:00] I haven't managed to get to it, but I have been planning to spend time on it recently. [03:00] james_w: Thanks. [03:00] I'd be happy to help as well [03:00] When I do get to it I'll ask for help; in the meantime, I appreciate bug reports. :) [03:00] I already filed a bunch, as you may have noticed :-) [03:01] jelmer: Yes, thanks. :) I still need to review and merge you branches, which I will do soon. [03:06] * Verterok ibook took 6998.977s to ran 13715 tests [03:06] Verterok, did they all pass? [03:07] with: failures=14, errors=13, known_failure_count=17 [03:07] beuno: ^ [03:07] and 797 skipped [03:07] Verterok, time to file bugs! [03:07] indeed [03:07] but I don't known what test failed :P [03:08] beuno: my term history have some arbritary limit :P [03:09] * Verterok now running all the test suite wiht stdout & stderr redirected to files :) [03:11] Verterok, I'm guessing none of it gets logged in .bzr.log? [03:12] beuno: yeap [03:20] also, yay firefox OOM killed [03:33] hey all [03:33] No such file or directory: u'/home/mtaylor/src/drizzle/.bzr/repository/indices/366c128ec96628e2e71bf57ee4d56c1d.six' [03:33] I got that ^^ while _pushing_ [03:33] that would be the source repository, not the dest repository, it's mentioning [03:43] mtaylor, did you get a traceback in ~/.bzr.log [03:43] could you please file a bug with the details [03:43] i think you can retry the push and it will be ok [03:43] poolie: yes... worked on retry [03:43] i think this is a dupe of something we're going to fix [03:43] ok [03:43] poolie: you want me to file the bug anyway? [03:44] um let me find the number and i'll get you to attach it to that one... [03:44] ok [03:49] bug 153786 [03:51] mtaylor: were you committing to the source from another process? (or pulling into it?) [03:52] lifeless: no [03:52] lifeless: I had aborted a previous push shortly before [03:52] mtaylor: ok, thats interesting then [03:52] mtaylor: you grep for 366c128ec96628e2e71bf57ee4d56c1d in /home/mtaylor/src/drizzle/.bzr/repository/pack-names [03:53] lifeless: and after the later successful push was finished, I got an "Read from remote host bazaar.launchpad.net: Connection timed out" [03:53] and if its present check for 366c128ec96628e2e71bf57ee4d56c1d.pack in .../packs, and 366c128ec96628e2e71bf57ee4d56c1d.{t,s,r,i}ix in .../indices [03:53] nope. not in pack-names [03:53] if 366c128ec96628e2e71bf57ee4d56c1d is not present in the pack-names index then I think its as poolie says, a dupe of a known race condition that is safe (but annoying) [03:54] ok [03:56] how is drizzle going? [04:00] lifeless, about that upgrade test from the other day [04:00] after sleeping on it, i don't think it does belong in the per-stacking-repository-format tests [04:00] because there is no straightforward place for that format to be inserted [04:01] i'm making the stacking repository using basis_bzdir.sprout(... stacked=True) [04:01] and that lets the other format choos [04:01] choose* [04:06] poolie: hmm, let me do a micro-teset [04:07] of course we could have a test that makes a new repo of the relevant format and then sets up a fallback, then upgrades the fallback, etc [04:07] that would be useful, but not quite the same test [04:38] poolie: http://infovore.org/archives/2008/02/06/demonstrating-snap/ [04:38] spiv: yo [04:45] lifeless: yo [04:45] spiv: I'm confused [04:46] poolie: btw, load_tests in a sub-area works Just Fine [04:46] So, it boils down to statements of intent. [04:47] poolie: http://rafb.net/p/J3j6NT50.html [04:47] poolie: demonstrating adding two scenarios to a module which is further parameterised [04:47] spiv: they are the same statement though! [04:47] include foo, exclude foo/bar [04:47] exclude wins if foo/bar is excluded [04:47] test_commit_exclude_subtree_of_selected's name says "this is a test for what happens when you exclude a subtree that is also selected." [04:48] yes, exactly! [04:48] Which is different statement to "this is a test for the excludes argument overrides the specific files" [04:48] Closely related, but not the same. [04:48] *blink* [04:49] no its not [04:49] selected files are specific files [04:49] Actually, looking at test_commit_exclude_subtree_of_selected I don't even see it passing any specific files. [04:49] Yes, I know they are synonyms, my point isn't about that. [04:50] the default specified path is '/' [04:50] but I can add 'a' to the call [04:51] anyhow, I still don't understand [04:52] So, I think a test that does commit('msg', exclude=['foo'], specific_files=['foo']) and is named "test_exclude_overrides_specific_files" declares a different intent than the existing test_commit_exclude_subtree_of_selected, both in name and in implementation. [04:52] (even ignoring the "selected" vs. "specific") [04:52] errr [04:52] I disagree [04:53] updated comment (thanks) and added specific files to the call: [04:53] http://rafb.net/p/k6twXM76.html [04:53] I see the subtree test as exploring what happens when "a" is selected but "a/b" is excluded, which I think has different intent. [04:54] (note that your comment suffers a greater chance of bitrot on refactoring, and is not strictly correct, but if it makes more sense to you I'm happy) [04:54] That's what happens when the two arguments partially overlap/conflict. [04:55] spiv: re intent; I wrote both sets of prose, they have the same *intent*. I think thats why I'm finding your description difficult, you are asserting things that are not true; you can assert that the intent you think it has is different [04:55] lifeless: (yeah, there's a tradeoff between extreme precise and either too vague or too verbose) [04:55] hmm, the more I think about the comment change the less I like it [04:55] Well, to my mind they are separate claims. [04:55] I can see how you can consider one to be a strict superset of the other. [04:55] the problem is that _update_builder_with_changes *may* record an unmodified version of excluded paths [04:56] or it might record a merge [04:56] or it might not record it at all if its new [04:56] spiv: select foo, exclude foo is a specific corner case in the space of 'excludes override selects'. [04:57] "... if appropriate"? "... will $better_verb ..."? [04:57] spiv: select foo, exclude foo/bar is another corner case [04:57] I think it would be easy to have (foo, foo) pass and (foo, foo/bar) fail, but very difficult to have the reverse. [04:57] so I wrote a test for the reverse [04:58] Right, I absolutely think you need the latter test. [04:58] I don't think the prose about excludes is coupled to the (foo, foo) case with anywhere near the glue you seem to think it is [04:58] it doesn't say 'an exclude of the same path as a selected path will win' [04:59] I just think the simpler case might be worth having as it is both as a way to gradually build up the reader's understanding of behaviour and as it directly correlates to how it is explained in the documentation. [04:59] it says that excludes take precedence which covers the full range of cases and is not bound to any specific test. In fact the *example given* in the command help is the one I test [05:00] spiv: !? [05:00] When excludes are given, they take precedence over selected files. [05:00] For example, too commit only changes within foo, but not changes within [05:00] As a secondary thing, it wasn't immediately obvious to me as a casual reader that the subtree case was sufficient to cover the simpler case, and I didn't find it when looking for the simpler case. [05:00] foo/bar:: [05:00] [05:00] bzr commit foo -x foo/bar [05:00] So, I really was expressing a very very mild preference :) [05:00] I fail to understand how (foo, foo) correlates better to the docs! [05:01] I'm not meaning to argue to strongly that it should change, just explain my "huh, this didn't quite match my expectations" reaction when looking at the patch, and a possible thing to do about it. [05:01] [I'm feeling a little frustrated here; I realise you want to make the code better, but your points don't seem to fit the actual code or docs well, and thats making it hard for me] [05:02] Part of it was some confusion on my part: it wasn't immediately obvious to me that the subtree case a) covered the simpler case, and b) necessarily covers the simpler case because of the nature of the problem. [05:03] I'd rather this as a comment I think: [05:03] # Skip excluded paths. Excluded paths are processed by [05:03] # _update_builder_with_changes. [05:04] Which might still be an argument for having the simpler case as well, but a fairly weak one. [05:04] spiv: I'd like to know what docs refer to this simpler case though [05:04] lifeless: just that first line I quoted. [05:04] you say 'as it directly correlates to how it is explained in the [05:04] documentation. [05:04] ' [05:05] lifeless: so, the docs and test are fine. [05:06] spiv: yet that same paragraph (within REST limitations) describes foo and foo/bar ? Should we expect developers to read less-than-that-paragraph? [05:06] spiv: what do you think of my updated comment? [05:07] lifeless: I like that new comment. Thanks! [05:09] ok, so I merged the previous patch ( it was 'tweak') - here is a post-merge update for it: http://rafb.net/p/Jc6oP514.html [05:09] pls approve :) [05:10] irc:approve ;) [05:10] (maybe one day bb will watch the IRC channel...) [05:10] thumper, did you ever get around to making the gnome-theme branch available? [05:11] beuno: I fixed my problems if that is what is asking [05:11] beuno: it is public I believe [05:11] beuno: but not yet on the playground [05:11] thumper, you where having problems merging in the new theme [05:11] beuno: firebug to the rescue [05:12] thumper, cool, so gnome is running the new theme? [05:12] beuno: not yet, [16:11] beuno: but not yet on the playground [05:12] beuno: but it could be soon [05:13] beuno: I'm fixing the revision feed for LP [05:13] thumper, ah, right. Ok, cool, let me know if you need any help with that [05:13] spiv: thanks, bombs away [05:13] thumper, cool, that will be useful now that codebrowse is up most of the time :p [05:14] thumper, I'll also get to your merge request in a minute. I'll just slap some comments on it and merge [05:14] beuno: cool, thanks [05:14] lifeless: so, at the risk of prolonging a finished discussion, I have a suggestion for you to consider... rename test_commit_exclude_subtree_of_selected to something like test_commit_exclude_overrides_selected_files. [05:15] spiv: heh. [05:15] lifeless: the thinking is that the purpose of the test isn't just for the subtree corner case, that just happens to be how the test is implemented. [05:15] spiv: at this point I'll defer; three pqm merges for one small feature are too many [05:15] I think you're right [05:15] lifeless: if you've already fired a patch, then I'm totally cool with doing nothing at this point :) [05:15] Pushed up to revision 3604. [05:16] Please use submit_branch, not pqm_branch to set the PQM merge target branch. [05:16] Checking the working tree is clean ... [05:16] Checking that the public branch is up to date ... [05:16] $ [05:16] oh wow [05:16] Ok, cool. Sorry for the small confusions on my part that made it hard for us to understand each other! [05:17] the pushed up to revision 3604 line is space padded to the rhs [05:17] probably the process bar [05:17] spiv: no probs, these things happen [05:18] The small confusions are possibly a sign of something that could be improved. My guess is that something is my coffee ;) [05:18] Thinking of food and drink... lunch time. [05:19] :> [06:04] what plugins are needed to run bzr bd in hardy? [06:07] bzr-builddeb I guess. [06:08] let me rephrase that. "bzr db" cant load plugin from '/usr/lib/python2.5/site-packages/bzrlib/plugins' [06:08] bzr-builddeb is already installed [06:08] gnomefreak: there should be a backtrace in ~/.bzr.log [06:08] s/db/bd/ [06:12] you know whats funny the errors are just about the same [06:13] http://pastebin.mozilla.org/506523 is the full file but im not sure wher eyou need it from so i have full logs [06:15] gnomefreak: nowhere in that log have you tried to run "bzr bd" [06:15] gnomefreak: so there's no relevant traceback that I can see. Another thing you could try is python -c "import bzrlib.plugins.builddeb" [06:16] spiv: sure it is [06:16] it left it out [06:16] maybe too big of a log [06:16] gnomefreak: there's no line that has "bzr arguments: [u'bd', ...]" [06:17] http://pastebin.mozilla.org/506525 [06:18] spiv: its not hte whole file, maybe a limit to size on pastebin [06:18] Ah, ok. [06:18] "# [06:18] ImportError: No module named apt_pkg" [06:18] that's the problem. [06:18] didnt use apt [06:18] nor apt_pkg [06:18] No, but the plugin does. [06:18] You presumably need to do "apt-get install python-apt" [06:19] ok will try [06:20] i would have thought builddeb package would bring it as a dep if its needed [06:20] that fixed it. thanks [06:20] Yeah, me too. [06:20] If you installed it from a deb, then that does sound like a bug in the package. [06:22] gnomefreak: What system are you on and what's the package version number? [06:23] Odd_Bloke: system? Hardy 386 and let me checkversion [06:23] builddeb = 0.95 bzr = 1.5-1 [06:25] gnomefreak: Where did you get builddeb from? [06:25] beuno: hi [06:25] mwhudson, hi again [06:25] beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory-listing-improvements <- nice functionality, iffy layout [06:25] Odd_Bloke: the repos [06:25] beuno: guess what i'd like you to do :) [06:25] crap wait [06:25]