| beuno | Peng_, you broke bzr/lp indirectly, ^ is your commit :p | 00:00 |
|---|---|---|
| jam | lifeless: I just reviewed the "Review Feedback" post | 00:00 |
| chevdor | 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 |
| chevdor | s/installer/installed | 00:00 |
| beuno | chevdor, you should see icons overlayed when you browse a versioned directory with nautilus | 00:01 |
| chevdor | beuno, ... but I don't :) | 00:01 |
| beuno | chevdor, what version of bzr-gtk have you installed? | 00:01 |
| chevdor | beuno, this is why I am asking, I'd like to know what/where to search for a problem | 00:01 |
| chevdor | beuno, gtk 0.93.0 | 00:02 |
| lifeless | beuno: just push, no need for --overwrite | 00:02 |
| beuno | chevdor, ah, it's disabled in 0.93. I'd recommend installing 0.95, which was released today | 00:03 |
| lifeless | thanks jam | 00:03 |
| chevdor | 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 |
| beuno | chevdor, np. G'night | 00:04 |
| lifeless | jam: but you didn't do bb:approve :P | 00:04 |
| chevdor | beuno, thx, ++ | 00:04 |
| jam | lifeless: I think I did | 00:05 |
| lifeless | http://rafb.net/p/uRBIHU22.html | 00:05 |
| beuno | Peng_, revision 192 of loggerhead thanks you for your contribution | 00:05 |
| beuno | mornin' poolie | 00:06 |
| poolie | hello beuno, lifeless | 00:06 |
| james_w | lifeless: there's a review with vote as well | 00:07 |
| james_w | hey poolie | 00:07 |
| lifeless | ah | 00:08 |
| lifeless | its not in my inbox :( | 00:08 |
| lifeless | found it | 00:08 |
| lifeless | thanks james_w | 00:08 |
| lifeless | and jam | 00:08 |
| lifeless | spiv: bug 254797 | 00:10 |
| ubottu | Launchpad bug 254797 in bzr "traceback when branching from bzr+http" [Undecided,New] https://launchpad.net/bugs/254797 | 00:10 |
| lifeless | spiv: I'm thinking a whole in the interface tests or something ? | 00:10 |
| Peng_ | Now https://code.launchpad.net/~loggerhead-team/loggerhead/trunk gives the "Pack already exists" error. | 00:23 |
| beuno | Peng_, try again, I got the same when committing | 00:23 |
| beuno | it's something wrong with auto-packing | 00:23 |
| beuno | oh, wait, branch is b0rked in LP | 00:24 |
| * beuno pokes lifeless | 00:24 | |
| Peng_ | :) | 00:24 |
| beuno | hrm, my commit didn't go through, even though bzr said it did | 00:24 |
| Peng_ | Finally, I'm not the only one with a broken branc. :) | 00:25 |
| beuno | LOL | 00:25 |
| * beuno wonders if bzr pack lp:loggerhead fixes it | 00:26 | |
| beuno | Peng_, what happens if you pull from lp:loggerhead? do you get revno 192? | 00:36 |
| beuno | ok, bzr pack fixed it | 00:36 |
| Peng_ | ...Yeah, I just did it, and it worked. | 00:36 |
| Peng_ | Before then, it just said no new changes. | 00:37 |
| beuno | Peng_, cool, everything should be back to normal then | 00:37 |
| Peng_ | :) | 00:38 |
| spiv | lifeless: nearly done with the review; I found a test bug | 00:42 |
| spiv | lifeless: and I agree, that bzr+http bug does suggest we have a hole in our tests | 00:42 |
| lifeless | spiv: the iter_changes ordering assumption? | 00:43 |
| lifeless | spiv: cause I think thats actually not a bug :P; we do directory-at-a-time for performance everywhere | 00:43 |
| spiv | lifeless: the 'bzr added' output ordering assumption | 00:44 |
| spiv | lifeless: and it is a bug, because I get an intermittent test failure | 00:44 |
| spiv | :) | 00:45 |
| lifeless | oh, ok | 00:45 |
| lifeless | thanks! | 00:45 |
| james_w | has the mailing list just started sending copies of messages if you are also getting them directly? | 00:53 |
| poolie_ | james_w, i have not changed it to do that | 01:00 |
| === poolie_ is now known as poolie | ||
| james_w | was there perhaps an upgrade? | 01:00 |
| james_w | maybe it's something else | 01:00 |
| elmo | there wasn't a mailman upgrade | 01:01 |
| elmo | it's a per list &| user setting though | 01:01 |
| james_w | I'll see if it continues, or it was something else | 01:02 |
| === edcrypt1 is now known as edcrypt | ||
| meteoroid | if i remove a branch / checkout from a shared repo, can i remove that branch's info from the repo store? | 01:07 |
| meteoroid | 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:09 |
| beuno | 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 |
| meteoroid | beuno: that's what i figured.. | 01:11 |
| meteoroid | so, e.g. for svn, i should probably share one repo for each svn repo root. | 01:12 |
| beuno | meteoroid, yes, I use a different shared repo for each project, which will msot likely share it's history | 01:12 |
| meteoroid | makes sense.. | 01:13 |
| lifeless | === modified file 'bzrlib/tests/test_options.py' | 01:29 |
| lifeless | --- bzrlib/tests/test_options.py 2007-09-03 01:50:29 +0000 | 01:29 |
| lifeless | +++ bzrlib/tests/test_options.py 2008-08-05 00:29:05 +0000 | 01:29 |
| lifeless | @@ -81,8 +81,7 @@ | 01:29 |
| lifeless | 01:29 | |
| lifeless | def test_allow_dash(self): | 01:29 |
| lifeless | """Test that we can pass a plain '-' as an argument.""" | 01:29 |
| lifeless | - self.assertEqual( | 01:29 |
| lifeless | - (['-'], {'fixes': []}), parse_args(cmd_commit(), ['-'])) | 01:29 |
| lifeless | + self.assertEqual((['-']), parse_args(cmd_commit(), ['-'])[0]) | 01:29 |
| lifeless | 01:29 | |
| lifeless | spiv: ^ | 01:29 |
| lifeless | I think the test was overly sensitive; it fails on my 3117 merge | 01:30 |
| lifeless | spiv: what do you think ? | 01:30 |
| spiv | lifeless: looking... | 01:36 |
| lifeless | I nearly JFDIid it | 01:36 |
| spiv | lifeless: I agree | 01:36 |
| lifeless | there are more in that file | 01:37 |
| lifeless | cmd_commit :( | 01:37 |
| lifeless | I'll put a XXX there | 01:37 |
| spiv | Really test_options shouldn't be relying on cmd_* classes in builtins. | 01:39 |
| lifeless | thats what my XXX says :) | 01:40 |
| lifeless | # XXX: Using cmd_commit makes these tests overly sensitive to changes | 01:40 |
| lifeless | # to cmd_commit, when they are meant to be about option parsing in | 01:40 |
| lifeless | # general. | 01:40 |
| spiv | Hmm, it imports cmd_log and cmd_status, but doesn't use them. | 01:40 |
| lifeless | fixed | 01:40 |
| lifeless | sending again | 01:41 |
| spiv | pyflakes reports that 'builtins', 'repository', 'symbol_versioning' and 'Command' are also unused, if you want to clean it up more... | 01:41 |
| lifeless | done | 01:43 |
| lifeless | thanks | 01:44 |
| lifeless | jam: ping | 01:44 |
| poolie | james_w, i would guess that you used a different sender address from the subscribed address | 01:59 |
| james_w | poolie: aha! thanks, that explains it. | 02:00 |
| poolie | all: what do you think of sending the standup notes to the bazaar list? | 02:01 |
| poolie | would it be too much noise? | 02:01 |
| james_w | I think Rob's mailer might have switched addresses for me when replying | 02:01 |
| poolie | i guess it's just one more message out of a couple of dozen per day | 02:02 |
| lifeless | poolie: I think some of them are relevant, some not. | 02:03 |
| lifeless | I'd suggest blogging or twittering for that sort of unfocused stuff though | 02:04 |
| poolie | or getting people to send mail individually about what they're doing | 02:04 |
| lifeless | which we do:) | 02:04 |
| lifeless | I guess what I really mean is | 02:09 |
| lifeless | 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:10 |
| jelmer | lifeless, any news about bzr-gtk pqm? | 02:15 |
| lifeless | no, thanks for reminidng me | 02:15 |
| awmcclain | Ug. 1.6r3 requires a version of python central that doesn't exist on gutsy? Boo! | 02:18 |
| awmcclain | b3, rather | 02:18 |
| poolie | awmcclain, really? i wonder why? | 02:18 |
| poolie | from the ppa i assume you mean? | 02:19 |
| awmcclain | Maybe I'm doing something wrong. | 02:19 |
| poolie | oh i see | 02:19 |
| awmcclain | he following packages have unmet dependencies: | 02:19 |
| awmcclain | bzr: Depends: python-central (>= 0.6.7) but 0.5.15ubuntu2 is to be installed | 02:19 |
| awmcclain | Correct. | 02:19 |
| poolie | i thought it would rebuild on gutsy but obviously not, would you please file a bug | 02:19 |
| awmcclain | sure thing | 02:19 |
| lifeless | poolie: will changes to .dev land in 1.6 final at this point ? | 02:21 |
| poolie | yes | 02:22 |
| lifeless | thanks | 02:22 |
| poolie | after i deal with your review to the upgrade test i'd like to make rc1 | 02:22 |
| poolie | i'll ask you to do pqm fu then | 02:22 |
| poolie | my desktop's video card is dying which is annoying | 02:22 |
| lifeless | my windtendos sound card is sucking | 02:23 |
| awmcclain | poolie: I reopened the feisty bug which is the same. | 02:30 |
| awmcclain | grumble grumble | 02:30 |
| beuno | poolie, the copy package thing bit me last time too :/ | 02:31 |
| lifeless | what are you guys doing? | 02:32 |
| beuno | I believe that someone pointed out that you should upload the oldest version (dapper probably), and copy dapper -> gutsy, dapper -> hardy, etc | 02:32 |
| beuno | lifeless, I *think* it's because we copied from hardy -> gutsy, etc, instead of starting from the bottom | 02:33 |
| beuno | or at least that's what cprov recommended if IIRC | 02:33 |
| lifeless | erm | 02:33 |
| lifeless | I didn't think you should *ever* copy between releases | 02:33 |
| beuno | uhm, then what's the copy feature for? | 02:34 |
| lifeless | ubuntu never copies, the whole archive is rebuilt from release to release | 02:34 |
| james_w | not entirely true | 02:34 |
| james_w | they do copy sometimes | 02:34 |
| lifeless | 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 |
| lifeless | ABI changes, support tool changes etc | 02:34 |
| lifeless | 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 |
| lifeless | james_w: when I was last in London | 02:35 |
| lifeless | copying between suites is differnet | 02:35 |
| james_w | don't PPAs support copying source (might work) or source+binary (will only work in very specific circumstances) | 02:35 |
| james_w | I've see hardy-proposed->intrepid | 02:35 |
| poolie | beuno, oh i see | 02:36 |
| poolie | about coping from oldest to newest | 02:36 |
| poolie | they support copying either source or binaries | 02:36 |
| lifeless | I urge you to only copy source | 02:37 |
| beuno | poolie, that way it will depend on an older version instead of a newer | 02:37 |
| poolie | only one option works for this | 02:37 |
| poolie | beuno, yes, i see | 02:37 |
| poolie | 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 |
| lifeless | but myself I wouldn't copy at all, I'd use e.g. autoppa and upload each release independently | 02:37 |
| poolie | moving to autoppa is probably better | 02:38 |
| beuno | what's autoppa? | 02:38 |
| jelmer | autoppa really isn't ready yet imo | 02:39 |
| jelmer | and not just on sid | 02:39 |
| lifeless | jelmer: maybe so, though there are folk using it heavily | 02:42 |
| jelmer | lifeless, it does stuff like invoke "bzr revert" on each individual file in the source branch without asking | 02:43 |
| lifeless | jelmer: I didn't claim perfection; I claimed that there are folk using it a lot | 02:44 |
| jelmer | lifeless: (and I really mean use os.system("bzr revert <filename>") for each file) | 02:45 |
| poolie | whoa | 02:45 |
| lifeless | lol jkakar needs a cluebat then | 02:45 |
| poolie | jelmer, so what do you think we should do instead? manually update all the packages? | 02:46 |
| poolie | or write a custom script to do it? | 02:46 |
| lifeless | well | 02:46 |
| lifeless | I'd file more bugs on autoppa | 02:46 |
| jelmer | Fix autoppa, ideally | 02:46 |
| jelmer | I think the idea behind autoppa is nice and jkakar doesn't seem to be opposed to improving it :-) | 02:46 |
| awmcclain | Autoppa? Is that some holy grail that automatically builds packages for a variety of releases? | 02:48 |
| jelmer | awmcclain: yes, that's the idea | 02:48 |
| awmcclain | Ooooo... | 02:48 |
| jelmer | it can build *source* packages for various releases and uploads them to ppa | 02:49 |
| awmcclain | Oh, source is all I want. Is it released? | 02:49 |
| jelmer | yeah, http://launchpad.net/autoppa | 02:49 |
| awmcclain | Is autoppa compatible with pdebuild or just debuild? | 02:55 |
| jelmer | it just invokes debuild atm I think | 02:56 |
| awmcclain | mmm. it's written in python? | 02:56 |
| awmcclain | 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 |
| awmcclain | x2 releases. | 02:57 |
| awmcclain | Is 1.6 a lot faster than 1.2 or 1.4? | 02:58 |
| awmcclain | (subject change) | 02:58 |
| awmcclain | a lot = noticably | 02:58 |
| awmcclain | *noticeably | 02:59 |
| jkakar | I am interested in improving AutoPPA, a lot of it is hackish. | 02:59 |
| jkakar | I already have a branch in progress to use bzrlib directly, but I'm stuck on a couple of issues. | 02:59 |
| james_w | jkakar: if we can help give us a shout | 03:00 |
| jkakar | I haven't managed to get to it, but I have been planning to spend time on it recently. | 03:00 |
| jkakar | james_w: Thanks. | 03:00 |
| jelmer | I'd be happy to help as well | 03:00 |
| jkakar | When I do get to it I'll ask for help; in the meantime, I appreciate bug reports. :) | 03:00 |
| jelmer | I already filed a bunch, as you may have noticed :-) | 03:00 |
| jkakar | jelmer: Yes, thanks. :) I still need to review and merge you branches, which I will do soon. | 03:01 |
| * Verterok ibook took 6998.977s to ran 13715 tests | 03:06 | |
| beuno | Verterok, did they all pass? | 03:06 |
| Verterok | with: failures=14, errors=13, known_failure_count=17 | 03:07 |
| Verterok | beuno: ^ | 03:07 |
| Verterok | and 797 skipped | 03:07 |
| beuno | Verterok, time to file bugs! | 03:07 |
| Verterok | indeed | 03:07 |
| Verterok | but I don't known what test failed :P | 03:07 |
| Verterok | beuno: my term history have some arbritary limit :P | 03:08 |
| * Verterok now running all the test suite wiht stdout & stderr redirected to files :) | 03:09 | |
| beuno | Verterok, I'm guessing none of it gets logged in .bzr.log? | 03:11 |
| Verterok | beuno: yeap | 03:12 |
| lifeless | also, yay firefox OOM killed | 03:20 |
| mtaylor | hey all | 03:33 |
| mtaylor | No such file or directory: u'/home/mtaylor/src/drizzle/.bzr/repository/indices/366c128ec96628e2e71bf57ee4d56c1d.six' | 03:33 |
| mtaylor | I got that ^^ while _pushing_ | 03:33 |
| mtaylor | that would be the source repository, not the dest repository, it's mentioning | 03:33 |
| poolie | mtaylor, did you get a traceback in ~/.bzr.log | 03:43 |
| poolie | could you please file a bug with the details | 03:43 |
| poolie | i think you can retry the push and it will be ok | 03:43 |
| mtaylor | poolie: yes... worked on retry | 03:43 |
| poolie | i think this is a dupe of something we're going to fix | 03:43 |
| poolie | ok | 03:43 |
| mtaylor | poolie: you want me to file the bug anyway? | 03:43 |
| poolie | um let me find the number and i'll get you to attach it to that one... | 03:44 |
| mtaylor | ok | 03:44 |
| poolie | bug 153786 | 03:49 |
| lifeless | mtaylor: were you committing to the source from another process? (or pulling into it?) | 03:51 |
| mtaylor | lifeless: no | 03:52 |
| mtaylor | lifeless: I had aborted a previous push shortly before | 03:52 |
| lifeless | mtaylor: ok, thats interesting then | 03:52 |
| lifeless | mtaylor: you grep for 366c128ec96628e2e71bf57ee4d56c1d in /home/mtaylor/src/drizzle/.bzr/repository/pack-names | 03:52 |
| mtaylor | lifeless: and after the later successful push was finished, I got an "Read from remote host bazaar.launchpad.net: Connection timed out" | 03:53 |
| lifeless | and if its present check for 366c128ec96628e2e71bf57ee4d56c1d.pack in .../packs, and 366c128ec96628e2e71bf57ee4d56c1d.{t,s,r,i}ix in .../indices | 03:53 |
| mtaylor | nope. not in pack-names | 03:53 |
| lifeless | 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:53 |
| mtaylor | ok | 03:54 |
| lifeless | how is drizzle going? | 03:56 |
| poolie | lifeless, about that upgrade test from the other day | 04:00 |
| poolie | after sleeping on it, i don't think it does belong in the per-stacking-repository-format tests | 04:00 |
| poolie | because there is no straightforward place for that format to be inserted | 04:00 |
| poolie | i'm making the stacking repository using basis_bzdir.sprout(... stacked=True) | 04:01 |
| poolie | and that lets the other format choos | 04:01 |
| poolie | choose* | 04:01 |
| lifeless | poolie: hmm, let me do a micro-teset | 04:06 |
| poolie | 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 |
| poolie | that would be useful, but not quite the same test | 04:07 |
| lifeless | poolie: http://infovore.org/archives/2008/02/06/demonstrating-snap/ | 04:38 |
| lifeless | spiv: yo | 04:38 |
| spiv | lifeless: yo | 04:45 |
| lifeless | spiv: I'm confused | 04:45 |
| lifeless | poolie: btw, load_tests in a sub-area works Just Fine | 04:46 |
| spiv | So, it boils down to statements of intent. | 04:46 |
| lifeless | poolie: http://rafb.net/p/J3j6NT50.html | 04:47 |
| lifeless | poolie: demonstrating adding two scenarios to a module which is further parameterised | 04:47 |
| lifeless | spiv: they are the same statement though! | 04:47 |
| lifeless | include foo, exclude foo/bar | 04:47 |
| lifeless | exclude wins if foo/bar is excluded | 04:47 |
| spiv | 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:47 |
| lifeless | yes, exactly! | 04:48 |
| spiv | Which is different statement to "this is a test for the excludes argument overrides the specific files" | 04:48 |
| spiv | Closely related, but not the same. | 04:48 |
| lifeless | *blink* | 04:48 |
| lifeless | no its not | 04:49 |
| lifeless | selected files are specific files | 04:49 |
| spiv | Actually, looking at test_commit_exclude_subtree_of_selected I don't even see it passing any specific files. | 04:49 |
| spiv | Yes, I know they are synonyms, my point isn't about that. | 04:49 |
| lifeless | the default specified path is '/' | 04:50 |
| lifeless | but I can add 'a' to the call | 04:50 |
| lifeless | anyhow, I still don't understand | 04:51 |
| spiv | 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 |
| spiv | (even ignoring the "selected" vs. "specific") | 04:52 |
| lifeless | errr | 04:52 |
| lifeless | I disagree | 04:52 |
| lifeless | updated comment (thanks) and added specific files to the call: | 04:53 |
| lifeless | http://rafb.net/p/k6twXM76.html | 04:53 |
| spiv | 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:53 |
| lifeless | (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 |
| spiv | That's what happens when the two arguments partially overlap/conflict. | 04:54 |
| lifeless | 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 |
| spiv | lifeless: (yeah, there's a tradeoff between extreme precise and either too vague or too verbose) | 04:55 |
| lifeless | hmm, the more I think about the comment change the less I like it | 04:55 |
| spiv | Well, to my mind they are separate claims. | 04:55 |
| spiv | I can see how you can consider one to be a strict superset of the other. | 04:55 |
| lifeless | the problem is that _update_builder_with_changes *may* record an unmodified version of excluded paths | 04:55 |
| lifeless | or it might record a merge | 04:56 |
| lifeless | or it might not record it at all if its new | 04:56 |
| lifeless | spiv: select foo, exclude foo is a specific corner case in the space of 'excludes override selects'. | 04:56 |
| spiv | "... if appropriate"? "... will $better_verb ..."? | 04:57 |
| lifeless | spiv: select foo, exclude foo/bar is another corner case | 04:57 |
| lifeless | 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 |
| lifeless | so I wrote a test for the reverse | 04:57 |
| spiv | Right, I absolutely think you need the latter test. | 04:58 |
| lifeless | 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 |
| lifeless | it doesn't say 'an exclude of the same path as a selected path will win' | 04:58 |
| spiv | 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 |
| lifeless | 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 | 04:59 |
| lifeless | spiv: !? | 05:00 |
| lifeless | When excludes are given, they take precedence over selected files. | 05:00 |
| lifeless | For example, too commit only changes within foo, but not changes within | 05:00 |
| spiv | 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 |
| lifeless | foo/bar:: | 05:00 |
| lifeless | 05:00 | |
| lifeless | bzr commit foo -x foo/bar | 05:00 |
| spiv | So, I really was expressing a very very mild preference :) | 05:00 |
| lifeless | I fail to understand how (foo, foo) correlates better to the docs! | 05:00 |
| spiv | 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 |
| lifeless | [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:01 |
| spiv | 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:02 |
| lifeless | I'd rather this as a comment I think: | 05:03 |
| lifeless | # Skip excluded paths. Excluded paths are processed by | 05:03 |
| lifeless | # _update_builder_with_changes. | 05:03 |
| spiv | Which might still be an argument for having the simpler case as well, but a fairly weak one. | 05:04 |
| lifeless | spiv: I'd like to know what docs refer to this simpler case though | 05:04 |
| spiv | lifeless: just that first line I quoted. | 05:04 |
| lifeless | you say 'as it directly correlates to how it is explained in the | 05:04 |
| lifeless | documentation. | 05:04 |
| lifeless | ' | 05:04 |
| spiv | lifeless: so, the docs and test are fine. | 05:05 |
| lifeless | 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 |
| lifeless | spiv: what do you think of my updated comment? | 05:06 |
| spiv | lifeless: I like that new comment. Thanks! | 05:07 |
| lifeless | 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 |
| lifeless | pls approve :) | 05:09 |
| spiv | irc:approve ;) | 05:10 |
| spiv | (maybe one day bb will watch the IRC channel...) | 05:10 |
| beuno | thumper, did you ever get around to making the gnome-theme branch available? | 05:10 |
| thumper | beuno: I fixed my problems if that is what is asking | 05:11 |
| thumper | beuno: it is public I believe | 05:11 |
| thumper | beuno: but not yet on the playground | 05:11 |
| beuno | thumper, you where having problems merging in the new theme | 05:11 |
| thumper | beuno: firebug to the rescue | 05:11 |
| beuno | thumper, cool, so gnome is running the new theme? | 05:12 |
| thumper | beuno: not yet, [16:11] <thumper> beuno: but not yet on the playground | 05:12 |
| thumper | beuno: but it could be soon | 05:12 |
| thumper | beuno: I'm fixing the revision feed for LP | 05:13 |
| beuno | thumper, ah, right. Ok, cool, let me know if you need any help with that | 05:13 |
| lifeless | spiv: thanks, bombs away | 05:13 |
| beuno | thumper, cool, that will be useful now that codebrowse is up most of the time :p | 05:13 |
| beuno | thumper, I'll also get to your merge request in a minute. I'll just slap some comments on it and merge | 05:14 |
| thumper | beuno: cool, thanks | 05:14 |
| spiv | 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:14 |
| lifeless | spiv: heh. | 05:15 |
| spiv | 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 |
| lifeless | spiv: at this point I'll defer; three pqm merges for one small feature are too many | 05:15 |
| lifeless | I think you're right | 05:15 |
| spiv | lifeless: if you've already fired a patch, then I'm totally cool with doing nothing at this point :) | 05:15 |
| lifeless | Pushed up to revision 3604. | 05:15 |
| lifeless | Please use submit_branch, not pqm_branch to set the PQM merge target branch. | 05:16 |
| lifeless | Checking the working tree is clean ... | 05:16 |
| lifeless | Checking that the public branch is up to date ... | 05:16 |
| lifeless | $ | 05:16 |
| lifeless | oh wow | 05:16 |
| spiv | Ok, cool. Sorry for the small confusions on my part that made it hard for us to understand each other! | 05:16 |
| lifeless | the pushed up to revision 3604 line is space padded to the rhs | 05:17 |
| lifeless | probably the process bar | 05:17 |
| lifeless | spiv: no probs, these things happen | 05:17 |
| spiv | The small confusions are possibly a sign of something that could be improved. My guess is that something is my coffee ;) | 05:18 |
| spiv | Thinking of food and drink... lunch time. | 05:18 |
| lifeless | :> | 05:19 |
| gnomefreak | what plugins are needed to run bzr bd in hardy? | 06:04 |
| spiv | bzr-builddeb I guess. | 06:07 |
| gnomefreak | let me rephrase that. "bzr db" cant load plugin from '/usr/lib/python2.5/site-packages/bzrlib/plugins' | 06:08 |
| gnomefreak | bzr-builddeb is already installed | 06:08 |
| lifeless | gnomefreak: there should be a backtrace in ~/.bzr.log | 06:08 |
| mlh | s/db/bd/ | 06:08 |
| gnomefreak | you know whats funny the errors are just about the same | 06:12 |
| gnomefreak | http://pastebin.mozilla.org/506523 is the full file but im not sure wher eyou need it from so i have full logs | 06:13 |
| spiv | gnomefreak: nowhere in that log have you tried to run "bzr bd" | 06:15 |
| spiv | gnomefreak: so there's no relevant traceback that I can see. Another thing you could try is python -c "import bzrlib.plugins.builddeb" | 06:15 |
| gnomefreak | spiv: sure it is | 06:16 |
| gnomefreak | it left it out | 06:16 |
| gnomefreak | maybe too big of a log | 06:16 |
| spiv | gnomefreak: there's no line that has "bzr arguments: [u'bd', ...]" | 06:16 |
| gnomefreak | http://pastebin.mozilla.org/506525 | 06:17 |
| gnomefreak | spiv: its not hte whole file, maybe a limit to size on pastebin | 06:18 |
| spiv | Ah, ok. | 06:18 |
| spiv | "# | 06:18 |
| spiv | ImportError: No module named apt_pkg" | 06:18 |
| spiv | that's the problem. | 06:18 |
| gnomefreak | didnt use apt | 06:18 |
| gnomefreak | nor apt_pkg | 06:18 |
| spiv | No, but the plugin does. | 06:18 |
| spiv | You presumably need to do "apt-get install python-apt" | 06:18 |
| gnomefreak | ok will try | 06:19 |
| gnomefreak | i would have thought builddeb package would bring it as a dep if its needed | 06:20 |
| gnomefreak | that fixed it. thanks | 06:20 |
| spiv | Yeah, me too. | 06:20 |
| spiv | If you installed it from a deb, then that does sound like a bug in the package. | 06:20 |
| Odd_Bloke | gnomefreak: What system are you on and what's the package version number? | 06:22 |
| gnomefreak | Odd_Bloke: system? Hardy 386 and let me checkversion | 06:23 |
| gnomefreak | builddeb = 0.95 bzr = 1.5-1 | 06:23 |
| Odd_Bloke | gnomefreak: Where did you get builddeb from? | 06:25 |
| mwhudson | beuno: hi | 06:25 |
| beuno | mwhudson, hi again | 06:25 |
| mwhudson | beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory-listing-improvements <- nice functionality, iffy layout | 06:25 |
| gnomefreak | Odd_Bloke: the repos | 06:25 |
| mwhudson | beuno: guess what i'd like you to do :) | 06:25 |
| gnomefreak | crap wait | 06:25 |
| gnomefreak | wrong terminal | 06:25 |
| * beuno branches and hopes for the best | 06:26 | |
| gnomefreak | builddeb = 0.93ubuntu1 bzr = 1.3.1-1ubuntu0.1 | 06:26 |
| beuno | mwhudson, I'm guessing it has something to do with the "problems with formatting though" of the commit? | 06:26 |
| mwhudson | beuno: specifically, this puts the icon for the folder/branch in a separate cell to the target | 06:26 |
| Odd_Bloke | gnomefreak: OK, that's more like what I was expecting. | 06:26 |
| gnomefreak | sorry i forgot to go to chroot in that terminal | 06:26 |
| mwhudson | so the '..' link lines up with the names | 06:27 |
| mwhudson | beuno: the icon cell ends up way too wide though | 06:27 |
| Odd_Bloke | The issue seems to be that bzr-builddeb depends on python-debian but python-debian only recommends python-apt. | 06:27 |
| mwhudson | perhaps it would just be easier to add an icon for uplink... | 06:27 |
| beuno | mwhudson, I'll fix, look, and merge :) | 06:27 |
| mwhudson | beuno: thanks! | 06:27 |
| beuno | I'm trying to avoid getting to fixing setup, which has annoyed the hell out of me so far | 06:28 |
| mwhudson | should address Peng's "leaking root directory name" thing too | 06:28 |
| Peng_ | Eh what? | 06:29 |
| Odd_Bloke | gnomefreak: Ah, it's fixed in Debian. | 06:29 |
| Odd_Bloke | And in Intrepid. | 06:30 |
| gnomefreak | yeah intrepid does | 06:30 |
| gnomefreak | 1.5 | 06:30 |
| Peng_ | Should you guys be asleep yet? | 06:30 |
| gnomefreak | Odd_Bloke: would backporting 1.5 be that bad or is bzr depend on alot of other packages | 06:31 |
| gnomefreak | that would need to be backported | 06:31 |
| Odd_Bloke | gnomefreak: Well, the issue you hit here was in bzr-builddeb, not in bzr. | 06:32 |
| mwhudson | Peng: the 'bzr' in http://bzr.mattnordhoff.com/loggerhead/ | 06:32 |
| Odd_Bloke | And I have no idea about backporting, I'm not involved in Ubuntu development whatsoever. | 06:32 |
| mwhudson | in the h1 | 06:32 |
| gnomefreak | Odd_Bloke: i wasnt sure if bzr built bzr-builddeb | 06:32 |
| mwhudson | Peng_: beuno should | 06:32 |
| mwhudson | Peng_: it's only 1730 for me | 06:32 |
| Peng_ | Oh, right, that leak. I forgot. | 06:33 |
| beuno | I don't really sleep anymore | 06:33 |
| Odd_Bloke | gnomefreak: Nope, it's a separate source package. | 06:33 |
| Peng_ | I sleep occasionally; I just don't get rested. | 06:33 |
| gnomefreak | ok thanks | 06:33 |
| Odd_Bloke | gnomefreak: There has been some discussion of backporting bzr itself, but I can't remember what the conclusion was. | 06:34 |
| Odd_Bloke | Or even if there was one. | 06:34 |
| spiv | The conclusion was "backporting a couple of easy-but-important fixes to 1.3.1 (making 1.3.2?) is worthwhile" | 06:36 |
| Odd_Bloke | gnomefreak: ^ | 06:36 |
| gnomefreak | spiv: oh ok that makes sense | 06:37 |
| poolie | hello spiv, lifeless | 06:47 |
| lifeless | poolie: hi | 06:47 |
| lifeless | poolie: I tested your parameterisation thing; it worked for me | 06:47 |
| lifeless | http://rafb.net/p/J3j6NT50.html | 06:47 |
| poolie | mm i'm just looking at that | 06:47 |
| poolie | probably just user error last night | 06:48 |
| lifeless | poolie: :) | 06:54 |
| lifeless | Odd_Bloke: nice progress | 06:57 |
| lifeless | Odd_Bloke: I'll do a review-run tomorrow I think | 06:57 |
| nasloc__ | newbie question: how do you keep linux device nodes like /dev/null in bzr's repo? I want to version control /dev using bzr. | 06:59 |
| Odd_Bloke | lifeless: Thanks. :) | 07:02 |
| lifeless | nasloc__: we don't support special files sorry | 07:02 |
| lifeless | nasloc__: you'd have to write something to translate the special files into a storable form and back again (something like tar possibly) | 07:03 |
| Odd_Bloke | jml: If you could cast your eyes over the Twisted-related changes in my latest PQM patch (look under pqm/ui/), that'd be much appreciated. :) | 07:04 |
| beuno | mwhudson, you win. I'm firing up Gimp to make an "up" icon | 07:04 |
| nasloc__ | lifeless, oh I see :( | 07:05 |
| nasloc__ | lifeless, thanks anyway. is there a builtin or a standard way to do it? | 07:06 |
| nasloc__ | lifeless, like a automatic hook or some else. | 07:06 |
| lifeless | nasloc__: there are hooks, but I don't think any would be suitable for what you need | 07:09 |
| lifeless | /dev is extremely dynamic on most linux system these days | 07:09 |
| lifeless | igc: ping | 07:15 |
| nasloc__ | lifeless, oh thanks your info, what I want to do is to keep a embedded system's root filesystem, there's no devfs or udev on it anyway. I guess I'll just use a tarball to keep it. | 07:16 |
| lifeless | nasloc__: if you're maintaining a filesystem I'd definitely want something that tracks modes and owners etc | 07:23 |
| lifeless | and extended attributes | 07:23 |
| lifeless | bzr doesn't do any of these (by design, because they port badly between machines and operating systems) | 07:24 |
| matkor | olive-gtk during start: dbus_bindings.DBusException: Unable to determine the address of the message bus (try 'man dbus-launch' and 'man dbus-daemon' for help) - means I have to old dbus system ? | 07:24 |
| lifeless | all bzr tracks is the execute bit | 07:24 |
| beuno | Peng_, navigating to parent just hit trunk | 07:26 |
| Peng_ | beuno: Cool. | 07:26 |
| gour | morning, attempt to pull from desktop machine to laptop gives me: http://rafb.net/p/xmCu5Z23.html although i would swear they should be the same (desktop repo was created by pulling from laptop). anything could change in latest beta and/or how to fix it? | 07:27 |
| poolie | gour, current bzr.dev (after 1.6b3) should give you a better message | 07:28 |
| Peng_ | Wow, before refreshing the CSS, the look was really messed up. :P | 07:29 |
| poolie | could it be that you upgraded one of them to use with bzr-svn? | 07:29 |
| gour | poolie: i run b4 | 07:29 |
| gour | desktop shows: " Packs containing knits without subtree support" and laptop "Packs containing knits without subtree support" and i wonder how they're different | 07:30 |
| gour | poolie: no, i don't use (yet) bzr-svn | 07:30 |
| poolie | could you get the whole traceback from ~/.bzr.log please? | 07:30 |
| * beuno is off to bed | 07:32 | |
| beuno | g'night all | 07:32 |
| Peng_ | beuno: It seems to be working perfectly. Good work, both of you. :) | 07:33 |
| Peng_ | I think I'll go to bed too, maybe. | 07:33 |
| beuno | Peng_, thanks. I even had to pull out gimp for that one. Night! | 07:33 |
| gour | poolie: http://rafb.net/p/SgGbGp54.html | 07:34 |
| poolie | well, that is interesting | 07:35 |
| gour | i'm glad it is ;) | 07:35 |
| poolie | and if you go to gaura-nitai what is in ~/bzr/.bzr/repository/format? | 07:35 |
| lifeless | night beuno | 07:35 |
| gour | poolie: it's not shared repo, i've only branch-format "Bazaar-NG meta directory, format 1" | 07:38 |
| Peng_ | I'm writing this as a mental note, but: How does loggerhead handle it if you have a branch inside of a branch? Is the inner branch impossible to discover from browsing the website? Is that acceptable? | 07:38 |
| nasloc__ | lifeless, is there a vcs can do that? tracks modes and owners and extended attribute (just works in linux is ok for me.) | 07:39 |
| Peng_ | nasloc__: Maybe you should check out etckeeper, which builds on top of a VCS. | 07:39 |
| nasloc__ | Peng, thanks, I'll check that. | 07:46 |
| Peng_ | (OK, I'm really going to bed now. Bye.) | 07:49 |
| poolie | gour, so it seems that either there is a bug, or one of them is rich-root and the other is not | 07:54 |
| poolie | clearly the code thinks there is a difference | 07:54 |
| poolie | previously you said "desktop shows..." and i'm wondering where that came from... | 07:55 |
| gour | poolie: desktop is gaura-nitai.no-ip.org | 07:56 |
| poolie | i mean, which files are you looking at there | 07:57 |
| gour | poolie: i wanted to pull from gaura-nitai's repo to laptop's repo | 07:57 |
| poolie | gour, does it work if you try to pull over sftp rather than bzr+ssh? | 07:59 |
| gour | poolie: let me try | 07:59 |
| gour | poolie: no | 08:00 |
| gour | poolie: shall i try to upgrade the repo and then try again? | 08:01 |
| poolie | i'd like you to find the relevant repository directory for each branch | 08:01 |
| poolie | which should be shown by bzr info | 08:01 |
| poolie | and tell me the contents of .bzr/repository/format | 08:01 |
| poolie | for each | 08:01 |
| poolie | just to exclude the possiblitiy that it's some kind of bug | 08:02 |
| poolie | if you don't mind | 08:02 |
| gour | ok. | 08:02 |
| gour | poolie: laptop has "Bazaar pack repository format 1 (needs bzr 0.92)" | 08:03 |
| gour | poolie: while desktop (gaura-nitai) does not have that structure - it doe not have .bzr/repository/format only /.bzr/branch-format "Bazaar-NG meta directory, format 1" | 08:05 |
| spiv | gour: that's strange, the traceback says there is a repository on gaura-nitai | 08:16 |
| spiv | gour: i.e. I'd expect there to be a /home/gour/bzr/.bzr/repository/format based on that error message | 08:16 |
| gour | spiv: but it's branch-only | 08:16 |
| spiv | gour: what format is the branch? Is it a branch reference (i.e. lightweight checkout)? | 08:18 |
| lifeless | bzr info should help | 08:20 |
| spiv | gour: could you try repeating with -Dhpss? (i.e. bzr -Dhpss pull bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/bzr/cfgfiles) That should indirectly show in the ~/.bzr.log which repo format file it is reading from the remote end. | 08:20 |
| gour | spiv: here is info http://rafb.net/p/btLqey49.html | 08:21 |
| spiv | gour: I'd expect a branch-only bzrdir in ~/bzr/cfgfiles, and a shared repo ~/bzr | 08:22 |
| spiv | Right, bzr info says there's a shared repo in ~/bzr | 08:22 |
| gour | here is the log http://rafb.net/p/bB7YWS76.html | 08:23 |
| spiv | Right, 'get', '/home/gour/bzr/.bzr/repository/format' | 08:24 |
| spiv | Which succeeds, i.e. that file exists. | 08:25 |
| gour | yes, 'format' exists in laptop repo | 08:26 |
| spiv | That log says that file exists on gaura-nitai. | 08:27 |
| spiv | Which is your desktop, I think? | 08:27 |
| gour | right, gaura-nitai is the desktop machine from which i want to pull | 08:28 |
| spiv | Anyway, that bzr info paste says the gaura-nitai repo has rich-roots, and you earlier pasted that ''get', '/home/gour/bzr/.bzr/repository/format' | 08:28 |
| * spiv tries again | 08:28 | |
| spiv | Anyway, that bzr info paste says the gaura-nitai repo has rich-roots, and you earlier pasted that laptop has "Packs containing knits without subtree support". | 08:29 |
| gour | and format on gaura-nitai is "Bazaar pack repository format 1 with rich root (needs bzr 1.0)" | 08:29 |
| spiv | Right. | 08:29 |
| gour | and laptop repo has "Bazaar pack repository format 1 (needs bzr 0.92) | 08:30 |
| spiv | So the format is different. So there's no bzr bug here; you need to "bzr upgrade --rich-root-pack" your laptop repo. | 08:30 |
| lifeless | note that this will propogate | 08:30 |
| lifeless | if you actually have gone down this path by mistake, don't upgrade rather lets try to sort things out for you | 08:30 |
| gour | spiv: ok. clear. i just wonder how the difference was made | 08:30 |
| lifeless | bzr-svn uses rich-roots | 08:30 |
| gour | but i don't use bzr-svn | 08:31 |
| lifeless | if you did 'bzr branch svn:///' it will have made a rich-roots branch | 08:31 |
| gour | no, i didn't | 08:31 |
| lifeless | gour: someone you collaborate with might have? | 08:31 |
| spiv | gour: normally people stumble into this when they've branched from bzr-svn, or from a branch created by bzr-svn. | 08:31 |
| gour | no, my private machines and repo is handling my config files | 08:31 |
| spiv | Otherwise if you've done 'bzr init --rich-root-pack' or 'bzr upgrade --rich-root-pack' in the past. | 08:31 |
| spiv | bzr itself never defaults to this format. | 08:31 |
| lifeless | or 1.6-rich-root | 08:31 |
| lifeless | gour: this is obviously when you first noticed it ? | 08:32 |
| gour | the only thing which i do is to re-build bzr from repo | 08:32 |
| lifeless | gour: what have you done recently on your desktop ? | 08:32 |
| gour | lifeless: commit a small patch and then i wanted to pull that commit to laptop in order to have them 'in sync' | 08:33 |
| gour | ok, upgraded format, merged, committed... | 08:35 |
| gour | all is fine now. thank you for the help | 08:36 |
| gour | btw, i'm starting with the python (to help/tweak) GNUmed. which python mode you recommend for emacs-23, i.e. is the included one the best one? | 08:38 |
| spiv | gour: I'm a vim user, so I can't help much with that :) | 08:41 |
| gour | :-) | 08:42 |
| * ToyKeeper tries to find a working combination of revisions for bzr + bzr-svn | 09:27 | |
| ToyKeeper | Okay, just needed bzr 1.5; the latest lp:bzr-svn works with it, but not bzr.dev | 09:39 |
| ToyKeeper | Now to figure out how to save each feature branch rev to svn, instead of just one rev for the final merge... | 09:40 |
| awilkins | ToyKeeper: Push your feature branches to svn as branches before you merge them ? | 09:46 |
| ToyKeeper | I'm basically hoping to preserve history while dumping changes back into svn. So far, even 'bzr svn-push' seems to send only the merge. | 09:48 |
| * ToyKeeper hopes gnome gets converted to bzr soon | 09:48 | |
| awilkins | ToyKeeper: Yeah, what I'm saying is, push the branch before you merge it into trunk | 09:50 |
| ToyKeeper | Yeah. I was hoping to avoid dealing with svn "branches" at all. :) | 09:51 |
| ToyKeeper | I've figured out what I need to know, though. It just sounded like 'bzr svn-push' would automate the process for me. | 09:52 |
| === Snaggen_ is now known as Snaggen | ||
| ToyKeeper | Hmm, working with svn really makes me want URL aliases. | 11:34 |
| matid | ToyKeeper: You should be glad you got bzr-svn to work ;) I'm fighting with it for 2 days already :) | 11:38 |
| * dato uses zsh aliases for URLs in svn | 11:38 | |
| ToyKeeper | I had been thinking of making a bzr plugin for URL aliases... this is just more motivation to do it. | 11:42 |
| ToyKeeper | matid: lp:bzr-svn works okay with lp:bzr/1.5 ... just remember to run 'make' in the bzr-svn dir before using it. | 11:44 |
| ToyKeeper | Anyway, after spending an evening accessing at least two different sets of URLs per branch, I find myself longing for [paths] from .hg/hgrc | 11:45 |
| lifeless | what does that do? | 11:46 |
| lifeless | [we have a couple of similar things in plugins] | 11:46 |
| ToyKeeper | It's a simple "key = value" list, where the values are URLs. | 11:46 |
| ToyKeeper | The keys can be used anywhere an URL would go in hg | 11:46 |
| lifeless | I think the bookmarks plugin is the equivalent for bzr | 11:46 |
| ToyKeeper | So, it's easy to "hg pull fred ; hg pull sally ; hg push public ; hg push backup" | 11:47 |
| matid | ToyKeeper: Guess it depends on the operating system :) | 11:48 |
| matid | ToyKeeper: It fails for me on Mac OS X. | 11:48 |
| lifeless | matid: have you filed a bug? | 11:50 |
| ToyKeeper | The bookmarks plugin could be nice, except it doesn't work per-branch or per-repo. | 11:50 |
| matid | lifeless: Nope, not yet. | 11:51 |
| lifeless | ToyKeeper: well, repo's aren't semantic, but I could see it working per-branch or per url-prefix | 11:51 |
| ToyKeeper | If I'm working on three different projects with Fred, I can't just "bzr pull fred" in each of them. | 11:52 |
| lifeless | ToyKeeper: I believe that you can't today; I'm saying it should be possible for you tod o that | 11:52 |
| lifeless | ToyKeeper: I'd start by filing a bug asking for that... | 11:53 |
| Stavros | hello | 12:15 |
| Stavros | i have pushed to some location and don't have a wc there, how can i get it from the repo? | 12:15 |
| james_w | Stavros: "bzr help working-trees" may explain this for you | 12:16 |
| Stavros | ah co, thanks :/ | 12:17 |
| LarstiQ | matid: do you have a pastebin or some such on what your (build?) problem for bzr-svn on mac is? | 12:21 |
| matid | LarstiQ: http://gist.github.com/4052 | 12:22 |
| matid | LarstiQ: I've got lp:bzr/1.5 and lp:bzr-svn. | 12:22 |
| matid | LarstiQ: And I did run make in in ~/.bazaar/plugins/svn. | 12:23 |
| james_w | matid: can you look in your ~/.bzr.log to see why it can't load the svn plugin | 12:25 |
| LarstiQ | james_w: the traceback looks sufficient | 12:25 |
| james_w | I think the messages are in the wrong order for it to be causing the failure to load the plugin | 12:25 |
| james_w | it maybe that you have two svn plugins around | 12:26 |
| LarstiQ | oh right | 12:26 |
| james_w | LarstiQ: bzr doesn't show tracebacks from plugin loading by default | 12:26 |
| * LarstiQ nods | 12:26 | |
| LarstiQ | james_w: you are right | 12:26 |
| LarstiQ | wb Zindar | 12:27 |
| LarstiQ | matid: could you do what james_w said? If you aren't sure which part of .bzr.log is relevant, try with a fresh one and just the result of `bzr plugins` | 12:28 |
| matid | LarstiQ: This is the fresh one after bzr branch: http://gist.github.com/4053 | 12:28 |
| matid | LarstiQ: I'll post another one for bzr plugins. | 12:28 |
| matid | http://gist.github.com/4054 | 12:29 |
| matid | That's it. | 12:29 |
| LarstiQ | matid: to me, on quick glance, that looks like lp:bzr-svn is ahead of lp:bzr/1.5 (ie, better fit with 1.6) but let me check the API changes | 12:30 |
| james_w | AttributeError: 'module' object has no attribute 'properties_handler_registry' | 12:31 |
| james_w | yes, that's new in 1.6 | 12:31 |
| ToyKeeper | When I tried a few hours ago, lp:bzr-svn worked with lp:bzr/1.5, but not lp:bzr | 12:31 |
| matid | OK, will try with lp:bzr instaed of lp:bzr/1.5 | 12:31 |
| LarstiQ | matid: In general I'd say .dev matches .dev, and specific releases match (http://bazaar-vcs.org/BzrForeignBranches/Subversion mentions 0.4.10 works with 1.4 and 1.5) | 12:33 |
| LarstiQ | ToyKeeper: interesting. | 12:34 |
| ToyKeeper | ... retracing steps. | 12:34 |
| ToyKeeper | It looks like I had to back up to a non-HEAD rev to make it work. | 12:34 |
| ToyKeeper | The most recent tag in lp:bzr-svn works with lp:bzr/1.5 | 12:36 |
| matid | LarstiQ: lp:bzr with lp:bzr-svn throws a bus error at me when running bzr plugins. | 12:37 |
| LarstiQ | oh wow | 12:39 |
| LarstiQ | matid: just to be curious, did you at one point try released versions, bzr 1.5 icm with bzr-svn 0.4.10? | 12:39 |
| ToyKeeper | matid: Try tag:bzr-svn-0.4.10 in lp:bzr-svn instead. | 12:40 |
| matid | LarstiQ: Nope, I don't think so. | 12:40 |
| ToyKeeper | I had no luck getting the head rev of lp:bzr-svn to work, at all... and no success getting any rev of bzr-svn to work with bzr.dev | 12:41 |
| matid | ToyKeeper: How do I check out that taG? | 12:41 |
| gour | i'd like to provide bzr repo on LP for the cvs project. what do you recommend for CVS --> bzr conversion? | 12:42 |
| ToyKeeper | matid: bzr branch lp:bzr-svn -r tag:bzr-svn-0.4.10 bzr-svn-0.4.10 | 12:42 |
| ToyKeeper | (or the same, from your existing trunk/ branch) | 12:42 |
| LarstiQ | matid: what I'd do is `bzr revert -r tag:bzr-svn-0.4.10` | 12:42 |
| LarstiQ | or if you want to have it seperate, do what ToyKeeper said | 12:43 |
| LarstiQ | gour: is there a cvs-fastexport yet? | 12:43 |
| matid | It now says that installed subversion does not have updated Python bindings. | 12:43 |
| LarstiQ | sigh. | 12:45 |
| LarstiQ | matid: you really don't want to get into the business of building patched python bindings on OSX I think. | 12:45 |
| LarstiQ | (svn python bindings) | 12:45 |
| LarstiQ | so. | 12:46 |
| gour | LarstiQ: i'm not aware of. thinking about cvsps-import and tailor | 12:46 |
| LarstiQ | matid: our current options are, I think: 1) figure out the bus error 2) find a packaged bzr-svn + up to date bindings 3) figure out two other bzr-svn and bzr revisions that are compatible. | 12:47 |
| LarstiQ | gour: do you need it to be a continous sync, or just a one off conversion? | 12:47 |
| LarstiQ | matid: are you on 10.4/10.5? | 12:48 |
| matid | 10.5 | 12:48 |
| gour | LarstiQ: one conversion to provide 'sandbox' for devs to play with it | 12:49 |
| * gour would like to persuade them to move to bzr ;) | 12:49 | |
| LarstiQ | matid: what svn version are you using? | 12:49 |
| matid | 1.4.4 is installed by default on Leopard, I use 1.5.1 from MacPorts. | 12:49 |
| LarstiQ | matid: bzr-svn 0.4.10 uses the svn provided bindings, bzr-svn trunk (which will become 0.4.11 at some point) has it's own bindings | 12:49 |
| LarstiQ | matid: oh! 1.5 should be up to date enough I believe. | 12:50 |
| LarstiQ | matid: can bzr-svn 0.4.10 find the right libraries then? | 12:50 |
| matid | LarstiQ: I think I made some progress. | 12:50 |
| matid | LarstiQ: Now I'm on bzr-svn 0.4.10 and lp:bzr/1.5 | 12:50 |
| LarstiQ | gour: I haven't converted any cvs repository myself. For a free sofware project I'd either let launchpad do the conversion, or figure out what they are using. | 12:51 |
| matid | LarstiQ: I fixed my DYLD_LIBRARY_PATH and PYTHONPATH so that bzr sees svn 1.5.1 instead of 1.4.4 | 12:51 |
| LarstiQ | matid: right, now the combination of bzr, bzr-svn and svn sounds like it should work. | 12:51 |
| matid | LarstiQ: That's what I get now though: | 12:52 |
| matid | LarstiQ: http://gist.github.com/4060 | 12:52 |
| * gour is trying with cvsps-import | 12:52 | |
| LarstiQ | matid: aaargh, now you're running into an API change the svn developers saw fit to make. | 12:53 |
| matid | LarstiQ: What should I do then? | 12:54 |
| LarstiQ | matid: https://bugs.launchpad.net/bzr-svn/+bug/246683 | 12:55 |
| LarstiQ | matid: let me see if I can find which change fixed that, you need to have a slightly newer bzr-svn than 0.4.10 | 12:55 |
| ubottu | Launchpad bug 246683 in bzr-svn "Assertion `*path != '/'' failed" [High,Fix committed] | 12:55 |
| LarstiQ | matid: or we can just steal the patch from debian: http://ftp.de.debian.org/debian/pool/main/b/bzr-svn/bzr-svn_0.4.10-2.diff.gz | 13:03 |
| awilkins | Bindings should become a moot point when the current tip of 0.4 matures | 13:05 |
| * LarstiQ nods | 13:05 | |
| LarstiQ | matid: I'd still be interested in the bus error for ongoing development btw | 13:06 |
| awilkins | Alas, I stll have the opion that they are a little "hinky" | 13:06 |
| LarstiQ | but right now I need to get back to studying :/ | 13:06 |
| LarstiQ | awilkins: yes | 13:06 |
| awilkins | They have some catching up to do on Win32 and *nx64 | 13:06 |
| awilkins | And I have no idea about how well they work on OXS | 13:07 |
| awilkins | OXS | 13:07 |
| awilkins | Oh screw it, "those mac thingys" | 13:07 |
| dato | not thingies? :-P | 13:09 |
| gour | cvps-import failed...now trying with tailor | 13:09 |
| matid | LarstiQ: OK, seems like that debian patch did the trick. | 13:16 |
| LarstiQ | matid: does that mean your branch succeeded? | 13:17 |
| matid | It's copying revision 610/1320 as of now. | 13:17 |
| matid | It ought to succeed then. | 13:18 |
| matid | But I'm still keeping my fingers crossed. | 13:18 |
| LarstiQ | ok | 13:20 |
| LarstiQ | matid: I'll check back in a while, afk for now | 13:20 |
| matid | LarstiQ: k, thanks for your help! | 13:20 |
| jelmer | ToyKeeper, what error did you get trying to use lp:bzr-svn and lp:bzr? | 13:24 |
| matkor | What is use of dbus in olive (bzr-gtk) ? | 14:00 |
| awilkins | That's the commit notfier, no? | 14:01 |
| gour | does bzr-gtk still needs seahorse? | 14:01 |
| matkor | gour: seems so | 14:04 |
| matkor | File "/home/users/matkor/src/bzr-gtk/trunk-matkor/seahorse.py", line 32, in ? | 14:04 |
| matkor | bus = dbus.SessionBus() | 14:04 |
| gour | matkor: hmm, gpa is not enough? | 14:05 |
| matkor | gour: I do not know yet .. I just run recent bzr-gtk release and got stuck with fact that it raises exception during launch time | 14:07 |
| matkor | gour: Are you bzr-gtk developer ? | 14:07 |
| james_w | matkor: I think that part was fixed | 14:07 |
| gour | 0.95 works here | 14:07 |
| james_w | it uses it if available, but doesn't crash anymore if it isn | 14:07 |
| gour | matkor: no | 14:08 |
| matkor | james_w: For me it throws exception , I suspect I have older dbus system and situation "not available" is not recognized propertly | 14:10 |
| matkor | I even get different exception type: dbus_bindings.DBusException not as expected in code: except dbus.exceptions.DBusException, e: | 14:12 |
| pickscrape | So I did get into a bit of trouble upgrading our server from 1.5 to 1.6b3 :( | 14:14 |
| pickscrape | Any idea how long before 1.6 final is released? | 14:15 |
| awilkins | Just build your own with the version number edited in the source:-} | 14:15 |
| pickscrape | :) | 14:15 |
| pickscrape | Unfortunately I can't think of a sneaky way to get that to the 1.5 clients. | 14:16 |
| pickscrape | Problem is 1.5 is having to reconnect to the server every time, much like my 1.6 client kept having to reconnect to the 1.5 server. | 14:16 |
| awilkins | Is that bzr-search thingy any good? | 14:43 |
| jelmer | awilkins, yes | 14:59 |
| awilkins | What's the query language? | 15:04 |
| jelmer | awilkins, it's very basic - nothing boolean, just search for all words in the query I think | 15:08 |
| james_w | I think it has negations now | 15:09 |
| luks | I wonder why it doesn't use something like xapian | 15:10 |
| james_w | because xapian can't back on to bzr's transport API I believe | 15:11 |
| luks | it doesn't have to | 15:12 |
| james_w | it does for all the things Rob wanted it to do | 15:12 |
| awilkins | Hmm, I wanted to do things like "find diffs that this string was removed in" | 15:16 |
| jam | luks: http://www.advogato.org/person/robertc/diary/85.html | 15:17 |
| jam | I would imagine that xapian fails the | 15:17 |
| jam | "trivially installable" | 15:17 |
| jam | he mentions it as a candidate | 15:17 |
| jam | "xapian - it will need a custom storage backend" | 15:18 |
| luks | huh, no it doesn't need a custom storage backend | 15:18 |
| luks | it's trivially installable on any linux machine, I'm not sure about windows | 15:18 |
| luks | oh, wait, bzr-search works with indexes over bzr tranports? | 15:19 |
| jam | luks: afaik ,yes | 15:19 |
| luks | e.g. you have a branch on sftp server and bzr search will use the remote files | 15:20 |
| luks | ah | 15:20 |
| luks | but you have to copy the indexes manually, right? bzr push will not copy them? | 15:20 |
| jam | luks: I don't know | 15:20 |
| jam | I would assume that is true | 15:20 |
| jam | I don't know if you have a post-change hook on the sftp branch, if it will automatically generate them | 15:21 |
| jam | like it does locally | 15:21 |
| james_w | it installs the hook to update them, but doesn't push them around | 15:31 |
| james_w | so "bzr index" a branch and the index will always be up to date | 15:31 |
| gour | too bad, ghc decided to move to git :-( | 16:15 |
| gour | "Speed ruled out bzr" :-/ | 16:16 |
| LarstiQ | gour: actual measurements they performed, or speed myths/rumours? | 16:33 |
| awilkins | Meh, Bazaar is also the only VCS on the FreeBSD list not being evaluated actively | 16:38 |
| awilkins | I have come to the conclusion that the laptop that IT services are supposed to be upgrading me to is a myth | 16:40 |
| awilkins | They have rung me today to let me know I can take delivery of it, they know my location... but so far, no sign of it. | 16:41 |
| gour | LarstiQ: i'd say rumours only, or one benchmark mentioned on trac' wiki | 16:41 |
| gour | LarstiQ: see it at http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation | 16:41 |
| jelmer | any DD's around interested in sponsoring bzr-related packages? | 17:12 |
| evarlast | we have been working peer to peer style with some success, but as N has increased we think we need to move to a central style. Is there a way I can convert a branch to --no-trees after the fact? I'd like to take a branch and move it to a server | 17:19 |
| james_w | bzr remove-tree | 17:24 |
| james_w | if you "bzr push" to the server then the branch on the server won't have trees | 17:25 |
| james_w | whether or not you create a repo with --no-trees, but I would recommend you doing so anyway | 17:25 |
| ronny | hi | 17:28 |
| evarlast | remove-tree. thank you. I couldn't find that searching the docs. | 17:29 |
| ronny | is there a way to alter commits ? i commited changes i didnt want to by accident | 17:29 |
| andrea-bs | ronny: bzr uncommit | 17:29 |
| evarlast | I'm going to bzr push to my destination server, then I'm going to bzr remove tree from that destination. | 17:30 |
| evarlast | then I'll probably run a smart server out of that branch | 17:32 |
| ronny | thx | 17:34 |
| LarstiQ | evarlast: are you sure there are working trees on the destination server anyway? | 17:38 |
| evarlast | the destination server does not exist. | 17:40 |
| evarlast | I'm creating it. | 17:40 |
| evarlast | we had been strictly peer to peer with no server. | 17:40 |
| evarlast | my goal is to come up with a central branch. | 17:40 |
| evarlast | i'm not sure if just branching and removing the tree is what I want, or if I should init-repo and push my revs there somehow. | 17:42 |
| james_w | bzr init-repo --no-tree bzr+ssh://server/root/repo | 17:43 |
| james_w | bzr push bzr+ssh://server/root/repo/branch | 17:43 |
| james_w | should be all you need, repeat the second for as many branches as you want | 17:43 |
| LarstiQ | evarlast: pushing remotely doesn't touch the working tree, so you wouldn't have to remove working trees. | 17:44 |
| evarlast | and that push will include all my history! Awesome! that is EXACLYT what I needed. | 17:44 |
| evarlast | <3 U | 17:44 |
| evarlast | james_w: where can I send you gifts? :) | 17:44 |
| LarstiQ | evarlast: well, that is sort of the point of pushing ;) | 17:44 |
| james_w | evarlast: james_w @ my house please | 17:45 |
| Pilky | hey, does anyone know of a way to encrypt a bzr repository on a server? | 18:14 |
| jelmer | Pilky, you mean encrypt in some way that leaves it usable afterwards without unencrypting the whole repo? | 18:17 |
| dato | does somebody know if there's a standalone implementation of bram cohen's diff algorithm? (the one in bzr) | 18:17 |
| dato | standalone as in providing /usr/bin/foodiff | 18:17 |
| Pilky | jelmer: yeah, so I could still push to it/pull from it but it's stored encrypted on the server itself | 18:17 |
| Pilky | got a friend looking at bzr but wants to know about encryption | 18:18 |
| jelmer | Pilky, I think there was somebody working on a plugin for the SoC a while back | 18:18 |
| jelmer | but I'm not sure how far he got | 18:18 |
| Pilky | ok cool, I'll have a look for that | 18:19 |
| chevdor | quick one regarding translations in launchpad, some of them are flagged as "Someone should review this translation", if I review a translation and agree with it, shall I uncheck the checkbox ??? | 18:36 |
| beuno | jelmer, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/198 | 18:36 |
| chevdor | i am refering to bzr-gtk | 18:36 |
| beuno | thanks :) | 18:36 |
| beuno | chevdor, if you want someone to review it, check the box | 18:36 |
| jelmer | dato, afaik the bzr implementaiton can be run as a standalone app | 18:36 |
| jelmer | beuno, thanks | 18:36 |
| dato | jelmer: yep, somebody in other channel told me, but thanks :) | 18:37 |
| chevdor | beuno, well some of them may need another review but the question is : once I do reviesw one that needed review, is it ok to definitely untag the "need review" | 18:37 |
| beuno | chevdor, yeah, if you don't feel they don't need review anymore, you can unmark it. It depends on each translarion group, but if you're confident, IMHO it's fine | 18:38 |
| chevdor | ok, then I'll untag a bunch of them and leave the tag for those that are correct but sound a bit weird... :) | 18:38 |
| === acuster is now known as avc_lost | ||
| === mw__ is now known as mw | ||
| dakira | hi! I just read the complete user docs at bazaar-vcs.org but still have some problems setting up a central repository.. I'd be glad if someone could point me in the right direction. I documented my steps here: http://paste.pocoo.org/show/81301/ | 18:55 |
| james_w | hi dakira | 18:56 |
| james_w | dakira: your expectations were correct | 18:56 |
| james_w | what were you hoping the last command would do? | 18:57 |
| chevdor | hello, how can i actually install/run bzr-gtk ? I did branch the trunk, ran ./setup.py build, then ./setup.py install, restarted nautilus but still no icons, I can see the new items in the menu though. Pbm w/ icons ? only on my box ?? | 18:57 |
| james_w | chevdor: did you do a "nautilus -q" ? | 18:57 |
| chevdor | james_w, twice :) | 18:58 |
| james_w | I'm not sure then I'm afraid | 18:58 |
| james_w | I guess it's possible that setup.py install doesn't put the icons in the correct location | 18:58 |
| jelmer | chevdor, do you have python-nautilus installed? | 18:58 |
| dakira | james_w: I read on a blog howto that just binding would not create the working-tree at the remote location | 18:58 |
| james_w | dakira: that is correct | 18:59 |
| chevdor | jelmer, i do, I *do* see the menu entries in the nautilus context menu | 18:59 |
| james_w | dakira: if you would like to create the working tree then you need to ssh to the box and run "bzr checkout ." in that directory | 18:59 |
| jelmer | chevdor, What's not working ? | 18:59 |
| james_w | dakira: "bzr checkout sftp://server/.../branch/ sftp://server/.../branch/" might do it, I've never tried | 18:59 |
| chevdor | jelmer, i thought I'd see icons on the versioned folders, was I expected too much ? :) | 19:00 |
| james_w | dakira: note however that creating the working tree won't keep it up to date as you work. | 19:00 |
| jelmer | chevdor, you should see emblems | 19:00 |
| chevdor | jelmer, ahh that's what I thought. I do NOT see anything but the regular folder icon (i run compiz... but I don't think it gets on the way) | 19:01 |
| dakira | james_w: okay.. maybe I misunderstood the concept.. so when I want to work from a different location can I pull a branch to work on from the remote server even if there are no files in the project directory on the server? | 19:01 |
| james_w | dakira: yeah, all you need is ".bzr" to be there. If you want to grab a copy to work on locally then "bzr checkout" or "bzr branch" will create the files locally for you to edir | 19:02 |
| jelmer | chevdor, probably caused by the gnome theme you're using | 19:02 |
| dakira | james_w: great.. thx.. | 19:03 |
| dakira | james_w: I should have just started working, instead of wondering why there were no files. So I guess bazaar stores the stuff in the repository? | 19:04 |
| james_w | dakira: yeah, all of the content is stored in .bzr, just not in a way that's easily readable. | 19:05 |
| dakira | james_w: great. thx for the support and for clearing things up! | 19:05 |
| james_w | dakira: no problem, feel free to ask any other questions | 19:06 |
| chevdor | jelmer, hmmm I'll check this out but I do see emblems, but not the bzr ones | 19:08 |
| chevdor | jelmer, I am using the default one (human). Are u aware of a problem with this one ? | 19:09 |
| jelmer | chevdor, human is only the default on ubuntu I think | 19:10 |
| chevdor | jelmer, indeed I use ubuntu | 19:10 |
| chevdor | jelmer, do u recommand a specific one that works ? | 19:11 |
| jelmer | chevdor, not sure | 19:12 |
| chevdor | jelmer, I have tried a few, none works | 19:14 |
| jelmer | chevdor, are you using the ubuntu package? | 19:14 |
| chevdor | jelmer, nop, it provides 0.93 where icons were disabled I think, I am using trunk | 19:15 |
| sebp | why isn't there a deb of 1.5.0 for hardy in the ppa? | 19:34 |
| beuno | sebp, something went terribly wrong, had tobe removed. You can get the 1.6b3 from: https://launchpad.net/~bzr-beta-ppa/+archive | 19:34 |
| sebp | beuno: okay, I install from source then | 19:35 |
| evarlast | whoa, just realized I have 1.3.1 on my hardy :) | 19:35 |
| beuno | sebp, the 1.5 for Gutsy may work | 19:35 |
| beuno | (if you prefer to stick to debs) | 19:36 |
| === mw is now known as mw|food | ||
| sebp | not really, I just was wondering why it's missing | 19:37 |
| beuno | sebp, there was a problem with the packaging of 1.6b2 which superceded 1.5 | 19:38 |
| hsn_ | anybody knows how to convert CVS repo from sf.net to bzr? I tried some convertor utility and it needs local access to repo | 20:20 |
| meteoroid | i think there's a way to export | 20:21 |
| meteoroid | did you try a cvs converter, or an sf migrator? | 20:22 |
| meteoroid | you probably can migrate sf cvs to local cvs or svn and then use that to more easily get into bzr | 20:22 |
| meteoroid | also, i think SF may migrate your CVS to SVN for you, which would make it pretty easy to get at with bzr-svn plugin | 20:22 |
| fullermd | You can rsync down a sf.net CVS repo... | 20:22 |
| meteoroid | nice.. | 20:23 |
| james_w | hsn_: you can request launchpad do that for you | 20:23 |
| meteoroid | nice++ :) | 20:23 |
| hsn_ | launchpad can do CVS import from sf? | 20:28 |
| lifeless | hsn_: it can import MAIN from CVS on sf | 20:36 |
| lifeless | hsn_: to do a migration, if you want to move the project to bzr; you should rsync the repo down and run the cvsps-importer | 20:37 |
| === mw|food is now known as mw | ||
| * beuno hits revno 200 in Loggerhead's trunk and celebrates | 20:55 | |
| pickscrape | beuno: nice work! | 20:56 |
| * pickscrape updates | 20:56 | |
| beuno | pickscrape, thanks :) | 20:57 |
| alefteris | what option I must use with setup.py to install an extension to .bazaar/plugins? | 20:57 |
| lifeless | alefteris: if you are installing a plugin to your home dir, just copy the directory there | 20:59 |
| lifeless | then do ./setup-py build_ext -i | 21:00 |
| alefteris | thanks a lot lifeless :) | 21:03 |
| alefteris | lifeless, updated http://bazaar-vcs.org/UsingPlugins, hope its ok | 21:11 |
| malept | hi, I found some rather odd behavior in 1.6b3...it seems that I cannot run `python -c 'from bzrlib import merge'`, throws an ImportError. I can successfully run that command, however, on 1.5 and 1.6b2. | 21:12 |
| malept | traceback: http://paste.ubuntu.com/34519/ | 21:14 |
| luks | looks like a circular import | 21:15 |
| luks | or not | 21:15 |
| lifeless | likely is | 21:15 |
| lifeless | lazy_import hides these | 21:15 |
| lifeless | malept: try importing one of the things it wants first | 21:15 |
| lifeless | malept: e.g. from bzrlib import branch, merge | 21:16 |
| malept | lifeless: that works. | 21:16 |
| malept | lifeless: shall I file a bug? | 21:17 |
| malept | (I actually hit this while running cmd_merge().run() in a small script I'm writing, the python one-liner is just the testcase) | 21:18 |
| lifeless | sure | 21:18 |
| rockstar | beuno, hi | 21:26 |
| meteoroid | so, i am branching from an svn repo which houses many projects, e.g. repo/project/trunk repo/project2/branches etc.. | 21:28 |
| meteoroid | bzr branch doesn't seem to detect the branching pattern, though it looks perfectly sensible for me, or, at least, there is a trunk and there are tags.. | 21:28 |
| meteoroid | i recall in the past that svn-import was better at this, but it only grabs an entire repo, not just a path | 21:29 |
| lifeless | meteoroid: svn-import was better when you branched the root | 21:30 |
| lifeless | meteoroid: if you're not branching from the root, AIUI svn-import and bzr branch should do the same thing | 21:30 |
| meteoroid | so, my concern is that each tag / branch will be an entire full copy in bzr instead of a proper branch, as i observed last night.. | 21:31 |
| meteoroid | hm, actually it doesn't look too bad.. okie doke. | 21:32 |
| meteoroid | guess ill just have to learn about this by performing lots of tests | 21:32 |
| elmo | lifeless: http://voi.aagh.net/bzr-fetch.log | 21:33 |
| elmo | lifeless: that's from LP bzr mirroring a branch | 21:34 |
| elmo | lifeless: is the repeated 200-ing expected? I don't have the http mavenry to know off hand if bzr's range requests would generate a 206 or 200 response | 21:34 |
| lifeless | 206's are partials | 21:38 |
| lifeless | and there are 206's there | 21:38 |
| elmo | right | 21:38 |
| elmo | but a lot of repeated 200s too | 21:38 |
| lifeless | thats a knit repository | 21:38 |
| lifeless | upgrade it to packs; it will be a lot happier | 21:39 |
| elmo | lifeless: sure, but, err, is LP doing this to all knits repositories? | 21:39 |
| elmo | 21:38 < lifeless> thats a knit repository | 21:42 |
| elmo | 21:39 < lifeless> upgrade it to packs; it will be a lot happier | 21:42 |
| elmo | Freaky: ^-- | 21:42 |
| mwhudson | beuno: you rock | 21:43 |
| Freaky | ah | 21:43 |
| lifeless | elmo: probably yes | 21:44 |
| lifeless | I smell a bug though | 21:44 |
| lifeless | elmo: ah yes | 21:44 |
| lifeless | 1.63 | 21:44 |
| lifeless | 1.6b3 | 21:44 |
| lifeless | 1.6b4 has my updated fetch code | 21:44 |
| lifeless | so update launchpads bzr, it will also make things more kumtreya | 21:45 |
| Freaky | no no, you're supposed to blame me, call me an idiot and then ban me, not fix it before I've even said anything, sheesh, haven't you worked on OSS before? | 21:46 |
| elmo | mwhudson: that was the sound of the bzr team knocking the ball back into your side of the court, just fyi ;-) | 21:46 |
| jelmer | lifeless: Any chance you can sponsor uploads of bzr-email and trac-bzr ? They're already in the archive but don't have DM-Upload-Allowed: yes set yet | 21:48 |
| elmo | jelmer: I can if you like, it's not my working day anymore | 21:49 |
| jelmer | elmo: Thanks | 21:49 |
| * mwhudson mutters something about the 1.6 release | 21:49 | |
| jelmer | elmo: The packages are uploaded to mentors.debian.net, let me dig up the links.. | 21:50 |
| jelmer | http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=trac-bzr | 21:50 |
| jelmer | http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=bzr-email | 21:50 |
| elmo | gah | 21:50 |
| elmo | that's trying to make me log in | 21:50 |
| elmo | jelmer: do you have the packages somewhere public? | 21:51 |
| elmo | (if not, I can create an acount, I guess) | 21:51 |
| jelmer | try http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=bzr-email | 21:51 |
| jelmer | (that's from the list for sponsors rather than the list for maintainers) | 21:52 |
| elmo | aha, yep, that works, thanks | 21:52 |
| elmo | will it makes things hard for you if I don't use this mentors.d.n ...interestingness? | 21:52 |
| jelmer | no | 21:53 |
| rocky | is there an easy way to query my main branch to see the commit msgs of the other branch i'm about to merge? (for whatever revisions the merge will figure out to do?) | 21:56 |
| jelmer | mentors.d.n is mainly just a ftp server with a fancy web frontend added to track the progress of a package in Debian | 21:56 |
| fullermd | rocky: missing maybe? | 21:56 |
| rocky | ah yes... that seems to do it | 21:57 |
| * pickscrape would like to see something like bzr log --include-pending | 21:57 | |
| * fullermd has occasionally thought that stat --show-ids should show the revids of the pending merges... | 21:58 | |
| james_w | I tried to implement a revspec the other day to allow you to specify these revisions, but our current revspec code isn't very amenable to it | 21:58 |
| elmo | jelmer: bzr-email seems to have lost the NMU? | 21:59 |
| jelmer | elmo: Whoops, I must have forgotten to import that | 22:00 |
| elmo | +Depends: bzr (>= 1.0~), | 22:00 |
| elmo | looks a little odd - any reason for the '~'? | 22:00 |
| rocky | ok, next question ... i can't seem to find docs on the --log-format switch for "bzr missing" ... it's not in the man pages or user guide... any suggestions? | 22:01 |
| jelmer | elmo: I used to build with a pre-release version of bzr, that must be how it got in there | 22:01 |
| jelmer | elmo: I'll remove it now that I'm importing the NMU entry | 22:01 |
| === sabdf1 is now known as sabdfl | ||
| elmo | +has a pricate address (e.g. bzr+ssh but anonymous access might be bzr:// or | 22:04 |
| elmo | ^-- speeling (private) | 22:04 |
| fullermd | rocky: It's the same as the options for 'log' | 22:04 |
| elmo | jelmer :not sure if that's actually your change or not ;-) | 22:04 |
| fullermd | rocky: (Actually, it lists them in missing too...) | 22:04 |
| jelmer | elmo: Whoops, that's from upstream | 22:05 |
| * jelmer files a bug | 22:05 | |
| jelmer | elmo, I've uploaded a new version with the NMU changelog entry imported and dependency on bzr (>= 1.0) to mentors.d.n | 22:06 |
| rocky | fullermd: ok... why can't i seem to find what you'er talking about? :) | 22:07 |
| fullermd | rocky: Right below that line, it lists the three. | 22:08 |
| rocky | fullermd: oh... --log-format=ARG means line, long, or short? i assumed it took a much more flexible format | 22:09 |
| fullermd | No, just one of the pre-defined names. | 22:10 |
| === cprov1 is now known as cprov-out | ||
| mwhudson | jelmer: i'm tempted to post to the 'the list is too busy' discussion | 22:12 |
| mwhudson | to say "bazaar-commits is too high volume too, jelmer should stop working so hard" | 22:12 |
| mwhudson | :-p | 22:12 |
| jelmer | mwhudson, :-) | 22:14 |
| elmo | jelmer: blink | 22:26 |
| elmo | jelmer: does mentors.d.n allow you to just overwrite the files with same name, different contents? | 22:27 |
| jelmer | elmo, yes | 22:27 |
| jelmer | elmo, I think the idea is that since review sometimes takes so many iterations, you wouldn't want to have to end up incrementing the debian reversion each time | 22:28 |
| dato | aah, that old discussion. | 22:37 |
| dato | pops back in the most unexpected places :-P | 22:37 |
| lifeless | dato: so, did you read that thread? | 22:37 |
| dato | not yet, sorry, work is leaving me with much-less-than-before free time. | 22:38 |
| lifeless | thats ok | 22:38 |
| Necoro | anyone here having a linux box with 2.6.25 kernel (or later) and a vfat partition at hand? | 22:42 |
| Necoro | hmm ... nevermind *tries something different* | 22:47 |
| ToyKeeper | If I were to modify bzr's config loader so it checked .bzr/branch/branch.conf first, then checked ~/.bazaar/bazaar.conf if no result was found... is that likely to be accepted? | 22:47 |
| ToyKeeper | That would allow any setting to be per-branch. | 22:47 |
| lifeless | branches aren't trusted data | 22:48 |
| lifeless | its inappropriate for every setting to be per-branch | 22:49 |
| ToyKeeper | No, not every setting should be per-branch. This would just make it possible. | 22:49 |
| lifeless | that said we already have cascading configs so that a setting in | 22:49 |
| lifeless | any file can be found from the branch config object | 22:49 |
| elmo | + "smtp_password" is not, you will be prompted for a password.S | 22:50 |
| ToyKeeper | Does the code grabbing the setting need to check that explicitly? | 22:50 |
| elmo | jelmer: ^-- another trivial/minor typo (end-of-line) | 22:50 |
| lifeless | ToyKeeper: only in that it needs to use branch.get_config() | 22:51 |
| lifeless | rather than asking for a url config or a global config | 22:51 |
| jelmer | elmo: Thanks, fixed (upstream) | 22:51 |
| ToyKeeper | And, if the branch has no config, branch.get_config() will return the global setting? | 22:52 |
| lifeless | branches always hasve configs | 22:52 |
| ToyKeeper | If the branch doesn't have the requested item configured... | 22:52 |
| lifeless | it will cascade | 22:52 |
| lifeless | through locations.conf and bazaar.conf | 22:53 |
| lifeless | and any others a plugin might have wedged in | 22:53 |
| ToyKeeper | But it's normal to not check the branch, because the branch might have malicious settings? | 22:53 |
| lifeless | it depends on the option | 22:55 |
| lifeless | if its an option that is fine to have in a branch just check the branch | 22:55 |
| lifeless | options that wouldn't be fine would be e.g. 'download this plugin from this url automatically' :) | 22:55 |
| lifeless | and hook code - arbitrary code execution is not a win :) | 22:56 |
| ToyKeeper | I'm curious because I was trying to find a way to do per-branch bookmarks, and it occurred to me that the per-branch bit is probably not something the plugin should need to re-implement. | 22:56 |
| lifeless | elmo: was the smtp password reference for me ? | 22:56 |
| elmo | lifeless: I dunno, it's bzr-email thing, but jelmer said he fixed it | 22:56 |
| lifeless | ToyKeeper: right, you don't have to implement anything for something like that; just use branch.get_config().set_user_option | 22:56 |
| lifeless | elmo: ah, ok | 22:57 |
| ToyKeeper | It looks like it'll be easy to change, then. :) | 22:57 |
| lifeless | you might need to do some fiddling | 22:59 |
| lifeless | I imagine that this use case makes sense: | 22:59 |
| lifeless | when updating a bookmark, save it to the place it was read from | 22:59 |
| Rhamphoryncus | Is it possible to rename a branch? Why do I get the feeling it's quite easy.. | 23:00 |
| lifeless | mv | 23:00 |
| ToyKeeper | I usually use a config library which has a list of places to look... it loads them in generic-to-specific order so the last one 'wins', and saves in reverse order, so it's saved to the most specific place available. | 23:01 |
| ToyKeeper | Rhamphoryncus: bzr nick new-branch-name | 23:02 |
| ToyKeeper | Rhamphoryncus: It's also usually helpful to rename its dir to match the nick. | 23:02 |
| Rhamphoryncus | nick? | 23:02 |
| ToyKeeper | Rhamphoryncus: Or, if you haven't set a nick, renaming the dir is sufficient. | 23:03 |
| Rhamphoryncus | so just renaming the dir in the repository will "just work"? No weird errors? | 23:03 |
| ToyKeeper | Yeah. | 23:03 |
| ToyKeeper | You can verify the new name by running 'bzr nick' in the branch. | 23:04 |
| ToyKeeper | ('nick' as in 'nickname') | 23:04 |
| * Rhamphoryncus will just tarball the repository first.. just in case ;) | 23:05 | |
| luks | Rhamphoryncus: the branch knows about it's repository, not the other way around | 23:07 |
| lifeless | ToyKeeper: thats what our config module does | 23:07 |
| luks | so if you move a branch within the repository, nothing will change from that point of view | 23:07 |
| lifeless | ToyKeeper: the only thing I was noting is that when you set a key it goes to the top of the stack - so to the branch, but if a user is updating a bookmark they had set globally they probably want it saved globally | 23:08 |
| pickscrape | Anyone know why bzrlib.transport.get_transport() might be returning me a readonly transport? | 23:09 |
| pickscrape | The transport in question is bzr+ssh | 23:10 |
| lifeless | thats not normally readonly, but you might just not have permission to write? | 23:10 |
| pickscrape | Normal bzr operations work fine. | 23:10 |
| pickscrape | I'm trying to use delete_tree(). | 23:11 |
| spiv | Ah, that's a bug. | 23:11 |
| pickscrape | I am passing a possible_transports list: I wonder if something I did earlier created a readonly transport. | 23:11 |
| spiv | RemoteTransport doesn't actually implement delete_tree. | 23:12 |
| pickscrape | How are remote branches normally deleted? | 23:12 |
| spiv | Or more exactly, it's hard-coded to raise TransportNotPossible('readonly transport'). | 23:12 |
| pickscrape | spiv: ah, so it's surprising error then | 23:12 |
| spiv | Well, it's ok for a transport not to implement delete_tree (according to our test suite) | 23:13 |
| pickscrape | Yes, but the error message doesn't exactly tell the truth | 23:14 |
| spiv | Though it is a bit funny; I think the other transports that don't support that are either readonly or don't support list_dir. | 23:14 |
| pickscrape | This one definitely supports list_dir: I've been using that already | 23:14 |
| spiv | Right. | 23:14 |
| pickscrape | So how do remote branches normally get deleted? | 23:14 |
| spiv | And as you say, the error message is pretty misleading. | 23:14 |
| pickscrape | I'm writing this to provide a 'safe' way for our developers to delete branches that are finished with | 23:15 |
| pickscrape | But this is something of a barrier :) | 23:15 |
| spiv | Instead of "remote_transport.delete_tree(...)", you might be able to do "bzrlib.transport.Transport.delete_tree(remote_transport, ...)" | 23:17 |
| pickscrape | spiv: sneaky... I'll try it | 23:17 |
| spiv | I think remote branches are normally deleted by hand; I usually do it from a shell prompt on the remote server. Branches hosted on LP can be removed through the web UI. | 23:18 |
| spiv | Typically I just ignore them though, they don't take up much space, so there's not benefit to deleting them. | 23:18 |
| pickscrape | Other than seeing the woods for the trees | 23:19 |
| pickscrape | If we just leave them we will end up with a *lot* of branches in no time. | 23:19 |
| spiv | Yeah. | 23:19 |
| spiv | In my case I don't expect people to be browsing my repos directly, though. | 23:19 |
| Rhamphoryncus | luks: ahhh | 23:19 |
| spiv | BundleBuggy and Launchpad keep track of the interesting work. | 23:19 |
| pickscrape | My other alternative is to add a trac plugin that deletes the branch, but since I'm doing so much else in the bzr plugin I'd rather keep it all in the same place. | 23:21 |
| spiv | Using the hosting area as a listing of interesting/active branches isn't a bad idea though. (Just explaining why it hasn't mattered in my case) | 23:21 |
| * spiv nods | 23:21 | |
| pickscrape | The other thing is the code I've got does checks to make sure the branch in question has been merged before deleting it (idiot proof) | 23:21 |
| pickscrape | People wandering on the server could accidentally delete the entire shared repo :) | 23:22 |
| spiv | It should be possible to remove a branch easily via the smart protocol, so if that isn't possible yet then that is something we ought to fix. | 23:22 |
| spiv | And "we" == "me", probably :) | 23:22 |
| pickscrape | spiv: in any case, you are a sneaky genius. It worked! | 23:23 |
| Rhamphoryncus | thanks y'all, seems to be working fine | 23:23 |
| spiv | pickscrape: have you seen https://edge.launchpad.net/bzr-removable, btw? | 23:23 |
| spiv | pickscrape: it can scan your branches to check that they have been merged, and don't have uncommitted changes, and don't have code shelved, etc. | 23:24 |
| pickscrape | Hehe, nice. | 23:24 |
| spiv | pickscrape: i.e. it can find the branches that are safe to remove. | 23:24 |
| pickscrape | What would be good for our developers to use as well. | 23:24 |
| pickscrape | We're strictly using bound checkouts right now, what I've written is to check for sideways merging, if you know what I mean. | 23:25 |
| pickscrape | I might add that one to the list of plugins that our plugin checks out automatically. | 23:25 |
| pickscrape | In case you can't tell I have to do a lot of hand holding where version control is concerned... | 23:25 |
| pickscrape1 | Note to self: don't kick the UPS power button... | 23:29 |
| davidstrauss | pickscrape: Did you discover that the power is, indeed, interruptible? | 23:31 |
| pickscrape1 | I did, and it was remarkable just how quickly the interruption took effect. | 23:31 |
| * pickscrape1 wonders why they put the button at the front... | 23:32 | |
| * davidstrauss thinks he's not going to merge in the changes to the universe created in pickscrape1's branch of reality. | 23:32 | |
| lifeless | pickscrape1: so that it can be kicked | 23:33 |
| pickscrape1 | They've diverged too much anyway: too many conflicts | 23:33 |
| pickscrape1 | Hmm, I appear to be here twice. | 23:34 |
| Peng_ | I guess the old one hasn't pinged out yet. | 23:34 |
| === pickscrape1 is now known as pickscrapeX | ||
| Peng_ | If you nick is registered, you can ghost it, or you can just wait. | 23:35 |
| pickscrapeX | I am registered. How do you ghost it? | 23:35 |
| Peng_ | /msg nickserv help ghost, I think. | 23:35 |
| pickscrapeX | Peng_: cool, thanks | 23:36 |
| pickscrapeX | \o/ | 23:36 |
| pickscrapeX | Good one to remember that, thanks. | 23:36 |
| jelmer | elmo, still there? | 23:36 |
| elmo | jelmer: yeah sorry, the Ubuntu CC meeting I was waited for started. I'll get to the upload after that, if that's OK? otherwise, feel free to bypass me if you have another DD handy | 23:37 |
| Necoro | lifeless: remember the issue with branching/initializing repos failing on vfat? | 23:38 |
| jelmer | elmo: No hurry, thanks :-) | 23:38 |
| lifeless | Necoro: yah | 23:39 |
| Necoro | lifeless: seems to be a kernel issue - works in 2.6.24 - but not in 2.6.25 | 23:39 |
| lifeless | Necoro: ah interesting | 23:40 |
| Necoro | (haven't tested 2.6.26) | 23:40 |
| lifeless | Necoro: if you can get a detailed cause we might be able to work around, or if its delibrate and not a bug I guess we'll have to change somehow | 23:40 |
| beuno | rockstar, hey! | 23:43 |
| beuno | mwhudson, :) | 23:43 |
| Necoro | lifeless: it seems like it is only possible now to toggle the "write" flags ... "r" and "x" can't be changed | 23:43 |
| beuno | I want 1.6 out the door! | 23:43 |
| rockstar | beuno, I'm packaging loggerhead | 23:43 |
| beuno | rockstar, you way want to take a look at: https://code.edge.launchpad.net/~jelmer/loggerhead/debian | 23:45 |
| rockstar | Hrm, that's close, but not what we really want. | 23:47 |
| * rockstar looks around for jelmer | 23:47 | |
| jelmer | rockstar, hi! | 23:47 |
| rockstar | jelmer, hi! | 23:47 |
| rockstar | It doesn't look like your package ships with a default conf, just the example. | 23:47 |
| elmo | bzr 1.6 is in danger of becoming the DukeNukemForever of VCS | 23:47 |
| rockstar | +1 elmo | 23:47 |
| jelmer | rockstar: it ships with an example configuration | 23:47 |
| jelmer | rockstar: the package is not ready yet though, because loggerhead insists on loading the configuration from the same directory as it itself lives in (e.g. /usr/lib/python2.5/site-packages/loggerhead) | 23:48 |
| rockstar | jelmer, shoot, I didn't notice that. Probably wouldn't have until I actually got the package created | 23:49 |
| beuno | jelmer, I'll be happy to fix that and shove it into /etc/*, but I don't really know what the best way to do that is. I'm guessing hard-coding the path isn't one of them | 23:49 |
| beuno | I absolutely want 1.6 to be easily installable, above all | 23:49 |
| nailor1 | i've got some issues with the olive-gtk gui. where would i discuss them | 23:50 |
| rockstar | beuno, if you hard code it, my diff for the package will change it. | 23:50 |
| jelmer | rockstar: I'm happy to work together on Debianizing loggerhead further, seems pointless to have two efforts | 23:50 |
| rockstar | jelmer, absolutely. | 23:50 |
| rockstar | I guess I didn't look hard enough when I looked for any started efforts. | 23:51 |
| beuno | so, if you guys can figure out the config file bit, I'll keep on smashing the remaining bugs | 23:51 |
| rockstar | beuno, I'm sure we can get something figured out. | 23:51 |
| beuno | jelmer has already been sending great patches to make the package as "debianizable" as possible | 23:51 |
| beuno | on a happy note, as of today, "setup.py install" actually works :) | 23:52 |
| rockstar | jelmer, the basic premise for all of this is that we want people to be able to apt-get install bzr-codehosting, and have all the tools up and running, similar to installing trac, ViewVC, etc. | 23:52 |
| jelmer | rockstar, ah, cool | 23:53 |
| rockstar | beuno, that's what I saw. That makes packaging easier, but it looks as if jelmer already knew that. | 23:53 |
| beuno | rockstar, you can usually asume jelmer knows everything :p | 23:54 |
| rockstar | so, jelmer == God? :) | 23:54 |
| fullermd | Hm. If that's so, I've got a *LONG* list of things to talk to him about... | 23:55 |
| jelmer | Aren't most rockstars gods as well ? ;-) | 23:55 |
| rockstar | jelmer, I'm more of a wannabe rockstar | 23:57 |
| jam | rockstar: so sort of : http://en.wikipedia.org/wiki/Rockstar_(Nickelback_song) | 23:58 |
| jam | (good song, by the way :) | 23:59 |
| * rockstar cringes at Nickleback. :) | 23:59 | |
| jam | at least, a fun music video | 23:59 |
| jam | lifeless: we should chat sometime when my power isn't fluctuating about your "reachability" stuff | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!