[00:40] <igc> bbiab
[00:45] <mubasher> hi
[02:14] <mrbig> Is there any mechanism for handling hook script in bzr? For example: I want bzr send me a email when somebody commits his change. ( same function as CVSROOT/loginfo or commitinfo)
[02:15] <beuno> mrbig, there is a plugin that does that in: http://bazaar-vcs.org/BzrPlugins
[02:16] <mrbig> beuno: thx, I check it now
[02:16] <beuno> mrbig, :D
[02:16] <mrbig> ;)
[02:59]  * igc lunch & some xmas shopping - bbl
[03:19] <bac> mrbig: hi nhan!
[04:01] <mrbig> opps
[04:01] <mrbig> Hi bac
[04:01] <mrbig> :)
[04:01] <bac> mrbig: i just came here to find an answer for you but saw you had already done so.  i hope one of those plugins works for you.
[04:02] <mrbig> bac: I'm playing with this
[04:02] <mrbig> bac: bzr is really cool
[04:03] <bac> mrbig: great!  i hope it works out for you!
[04:05] <mrbig> bac: yeah, I've told my team try to use it already. We'll have a small internal presentation about bzr tomorror
[04:06] <bac> mrbig: i look forward to hearing how that goes.  will you be at the LUG dinner tomorrow night?
[04:08] <mrbig> bac: I don't know about it, it's a weekly cafe I guess
[04:11] <mrbig> bac: ah just got email, sure I'll come
[04:16] <ubotu> New bug: #177592 in bzr "Commit fails after reconfiguring from light- to heavy-checkout" [Undecided,New] https://launchpad.net/bugs/177592
[05:12] <poolie> http://sourcefrog.net/tmp/bzrsite-draft/
[05:12] <poolie> hi bac
[05:12] <poolie> retro r us
[05:13] <jml> quick, publish it!
[06:01] <ubotu> New bug: #177605 in bzr-cvsps-import "module help too bare bones" [Undecided,New] https://launchpad.net/bugs/177605
[06:01] <ubotu> New bug: #177606 in bzr-cvsps-import "no install guide" [Undecided,New] https://launchpad.net/bugs/177606
[06:06] <ubotu> New bug: #177607 in bzr-cvsps-import "no setup.py" [Undecided,New] https://launchpad.net/bugs/177607
[06:45] <thumper> can someone tell me a more friendly name for branch format: Bazaar Knit Repository Format 4?
[06:45] <bac> poolie: hi
[06:47] <abentley> thumper: It's the repository format used in "rich-root".
[06:48] <thumper> abentley: ah, thanks, is this provided through a plug-in?
[06:48] <abentley> No, it's in Bazaar 1.0
[06:48] <spiv> thumper: no, it's part of 1.0
[06:49] <thumper> thanks
[06:49]  * thumper expects LP errors to go away then
[06:49] <thumper> abentley: isn't it almost 2am for you?
[06:50] <abentley> Yep.  Just off to bed.
[06:50] <thumper> :)
[06:50] <thumper> night
[07:15] <ubotu> New bug: #177613 in bzr "Crash when merging" [Undecided,New] https://launchpad.net/bugs/177613
[07:19] <poolie> ok, i'm going away for a while
[07:19] <poolie> see you later
[07:20] <bac> poolie: hi...
[07:20] <bac> poolie: give me a shout when you get back. i see you pinged when i was out for lunch
[07:21] <poolie> mm
[07:21] <poolie> not that i remember
[07:21] <poolie> i'm leaving for the holidays tomorrow
[07:21] <poolie> have a good holiday
[07:21] <bac> poolie: 00:12:39 hi bac
[07:21] <poolie> i was just saying hello
[07:22] <bac> ah, ok.  hello and good bye.  :)
[09:02] <igc> poolie: if you're still online, have a good holiday, xmas and New Year.
[09:02]  * igc dinner
[09:14]  * quicksilver thinks everyone should have a good holiday xmas and new year, including but not restricted to poolie 
[09:15] <fullermd> Sorry, there's only one good holiday to go around this year, and it's already been assigned to poolie...
[09:17] <quicksilver> ah well, I'm off to poolie house to bask in reflected happiness, then
[09:39] <mwhudson> do tracebacks like
[09:39] <mwhudson>   File "<string>", line 4, in set_last_revision_info_write_locked
[09:39] <mwhudson>   File "/srv/sm-ng/production/launchpad/sourcecode/bzr/bzrlib/branch.py", line 1412, in set_last_revision_info
[09:39] <mwhudson>     assert len(history) == revno, '%d != %d' % (len(history), revno)
[09:39] <mwhudson> AssertionError: 1368 != 1370
[09:39] <mwhudson> look familiar to anyone here?
[09:40] <jelmer> I've seen it before, yes
[09:40] <jelmer> not sure what causes it though
[09:42] <mwhudson> it is currently screwed up mirrored branches on launchpad
[10:59] <spiv> jelmer: I can reproduce it with: http://pastebin.com/m189c0ec9
[11:00] <jelmer> that branch may have been modified by .dev versions of bzr
[11:02] <spiv> Reconciling the local copy and reconciling the source to pull --overwrite from doesn't fix it.
[11:05] <spiv> Upgrading the local branch to rich-root format fixes the problem.
[11:10] <mwhudson> spiv: upgrading to dirstate-tags is enough
[11:10] <mwhudson> i really think it must be revision-history vs last-revision
[11:11] <spiv> Right
[11:11] <mwhudson> and so it's probably not as bad as i thought: it's only breaking mirroring of all dirstate branches on lp
[11:14]  * spiv wonders why _lefthand_history is disagreeing with revision_history
[11:14] <mwhudson> oh, it's not even that bad
[11:14] <spiv> jelmer@samba.org-20051106183643-4864eee4ce83e874 is the revision it's omitting.
[11:14] <mwhudson> although there are 2278 failures today
[11:15] <mwhudson> it is actually only 13 branches that are failing
[11:16] <mwhudson> for some reason they are not being marked as failing, and are being attempted every time the puller runs
[11:21] <spiv> Hmm!:
[11:21] <spiv> $ bzr revno
[11:21] <spiv> 37
[11:21] <spiv> $ bzr revision-history | wc -l
[11:21] <spiv> 36
[11:21] <mwhudson> well, that looks bad
[11:21] <spiv> Indeed.
[11:22] <spiv> That's after upgrading to dirstate-tags.
[11:22] <mwhudson> i suspect that we're hitting an old, maybe unreleased, bzr bug that's lead to bogus data
[11:22] <spiv> If I leave it in the original format, they're both 37.
[11:22] <spiv> Yeah.
[11:22] <mwhudson> does 'bzr check' pass in both branches?
[11:23] <spiv> The disagreement is basically that jelmer@samba.org-20051106183643-4864eee4ce83e874 is sometimes in the revision-history, and it shouldn't be, because it's not a mainline revision I think.
[11:24] <spiv> mwhudson: it does in the original
[11:24] <spiv> It also passes in the dirstate-tags branch
[11:24] <mwhudson> feh
[11:24] <spiv> (despite "45 inconsistent parents", which reconcile can fix)
[11:32] <spiv> jelmer: deleting jelmer@samba.org-20051106183643-4864eee4ce83e874 from your .bzr/branch/revision-history corrects the problem
[11:32] <spiv> jelmer: I think...
[11:32] <spiv> jelmer: I'm fairly sure that's correct.
[11:33] <spiv> Current bzr probably ought to give a better error than an assert for this case.
[11:33] <jelmer> ok
[11:34] <spiv> mwhudson: I need to stop for the night, can you file a bug and make sure jam knows about it
[11:34] <spiv> mwhudson: maybe even mail the list.
[11:34] <spiv> jelmer: Please keep a copy of the branch as is, though :)
[11:34] <jelmer> ok, I'll just leave ti for now
[11:34] <spiv> jelmer: thanks!
[11:35] <jam> mwhudson: bzr pull --overwrite . should fix it
[11:35] <jam> What is happening is that history was not normalized on one side
[11:35] <spiv> We should make "bzr check" check that .bzr/branch/{revision-history,last-revision} is correct
[11:35] <spiv> jam: great timing
[11:36] <jam> spiv: you pinged my name :)
[11:36] <mwhudson> hello jam!
[11:36] <spiv> jam: it's amazing what technology can do :)
[11:36] <jam> It used to happen in bzr pre 0.8 or so
[11:36] <jam> and it just sort of stayed there for a long time
[11:36] <mwhudson> 'bzr.dev pull --overwrite .' crashes too
[11:36] <spiv> (And we should make "bzr reconcile" fix it)
[11:37] <jam> well, internally it is
[11:37] <jam> b = bzrlib.branch.Branch.open('.')
[11:37] <spiv> Anyway, that's it for me for the night.
[11:37] <jam> b.generate_revision_history(b.last_revision())
[11:38] <jam> spiv: good night
[11:38] <jam> mwhudson: it happened in a recent patch to just call "set_last_revision"
[11:38] <spiv> jam: sounds like an easy thing to teach bzr check/reconcile... ;)
[11:39] <jam> spiv: should be fairly trivial
[11:39]  * spiv -> zzz
[11:39] <jam> part of the problem is that we are trusting the source branch to have the correct revno and last revision
[11:40] <jam> But there seem to be a lot of Branch5 out there with incorrect revision-history
[11:40] <mwhudson> anyway, the problem is nowhere near as bad as i feared
[11:40] <jam> yeah, we just used to allow you to pick any path through history you wanted
[11:40] <jam> but we moved away from that
[11:41] <jam> mwhudson: are you willing to put together a patch for check & reconcile?
[11:41] <mwhudson> jam: not right now
[11:41] <fullermd> Speaking of reconcile, there's something there that bugs me...
[11:41] <fullermd> It seems like 'reconcile' always takes longer than 'check', even when there's nothing to do.
[11:41] <mwhudson> jam: i want to fix the two problems that made this so scary for me
[11:45] <jam> fullermd: really? in what repository format?
[11:45] <jam> I've always found "check" to take longer
[11:45] <jam> because it checks all texts match their sha1sum
[11:46] <fullermd> All knit, probably.
[11:46] <jam> reconcile doesn't, because at the moment, there isn't really anything you can do if there is a mismatch
[11:46] <fullermd> Don't remember runs back in weave days.
[11:49] <fullermd> (And I've not had the time/adventuresomeness to try pack)
[11:49] <lifeless> knit reconcile << pack reconcile. pack reconcile is very fast, according to the intel users.
[11:49] <lifeless> night all
[11:49]  * fullermd gets whiplash watching the drive-by.
[11:50] <Peng> Knit and pack reconcile both do the same thing, right?
[11:51] <fullermd> The end result is the same, presumably, but the mechanics are probably a lot different.
[11:55] <jam> Peng: they work very differently
[11:55] <jam> IIRC knit reconcile is a bit more brute force
[11:56] <Peng> Is that good or bad?
[11:57] <jam> Peng: well it makes knits slower
[11:57] <jam> knits extract all inventories and work out what files have changed, etc.
[11:57] <jam> packs do a similar action, but without having to extract all fulltexts
[12:00] <Peng> If I'm converting from knits to packs, would it be a good idea to reconcile both, just to be careful?
[12:11] <ubotu> New bug: #177643 in bzr "http auth pycurl is broken" [Undecided,New] https://launchpad.net/bugs/177643
[12:30] <jam> Peng: you could, though I don't think the final effect is any different
[12:34] <TeTeT> is there a way to purge a version of a file from a repository? I hold some sample media files in bzr and would like to keep the version overhead small
[12:35] <TeTeT> I'm aware that this goal conflicts with having a file under version control at all
[12:36] <TeTeT> use case here would be 'I'd like to have the latest 3 versions of this audio files available, but not all of them'
[12:39] <jam> TeTeT: generally, no
[12:39] <jam> for referential integrity we don't yet allow removing nodes
[12:39] <TeTeT> jam: ok
[12:40] <jam> TeTeT: you might be able to put something together with 'rebase' but it would get pretty clumsy
[12:40] <jam> You can also look forward to
[12:40] <jam> http://bazaar-vcs.org/HistoryHorizons
[12:40] <TeTeT> ok
[12:40] <jam> which should allow people to do partial downloads
[12:40] <jam> sorry the correct link is: http://bazaar-vcs.org/HistoryHorizon
[12:40] <jam> I expect them to be finish in the first quarter next year
[12:41] <TeTeT> for projects like the desktop training where graphics go through 2-4 versions each easily I guess it's best to split the media files from the text files
[15:45] <wharp> Can someone give me some pointers.  I'm getting an error when I do bzr launchpad-login username
[15:46] <wharp> specifically bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))
[15:46] <mwhudson> wharp: are you a launchpad beta tester?
[15:46] <mwhudson> (very random guess)
[15:46] <wharp> don't think so
[15:46] <wharp> is it possibly a problem with my key?
[15:47] <fullermd> No, it's pycurl not being able to verify the chain to LP's cert.
[15:47] <mwhudson> no, it sounds like pycurl being a pain
[15:47] <wharp> well from what i can tell I don't have pycurl
[15:48] <wharp> or is it not a package?
[15:48] <fullermd> It's just hiding 'cuz it knows you're pissed.
[15:48] <mwhudson> python -c 'import pycurl'
[15:48] <wharp> Where's my trout.
[15:49] <wharp> tried that, still nothing
[15:49] <wharp> do I possibly need to remove curl?  I did install that
[15:50] <mwhudson> if that didn't fail, then you have pycurl installed
[15:50] <wharp> it didn't fail
[15:51] <wharp> at least, it didn't return anything
[15:51] <wharp> is there a way to test?
[15:51] <mwhudson> do you have the 'ca-certificates' package installed?
[15:51] <wharp> i do now
[15:51] <mwhudson> does it help?
[15:52] <wharp> yep, sure does
[15:52] <wharp> thanks, nothing I'd read mentioned that
[15:52] <mwhudson> just another piece of random knowledge floating around
[15:52] <wharp> just out of curiosity, should I have known I needed that?
[15:52] <mwhudson> wharp: probably not
[15:52] <wharp> lol
[15:53] <mwhudson> well, put another way: yes, but it's our fault not yours that you didn't :)
[15:53] <wharp> I'll blame it on Mr. Shuttleworth
[15:54] <fullermd> If only we had a FAQ where we could list such things...
[15:54] <wharp> I really didn't see that error mentioned anywhere.
[15:54] <wharp> Is the FAQ a wiki?
[15:55] <wharp> Another question.  It's adding bazar.launchpad.net, etc to the host....should it do something after that or will that take a while?
[15:56] <mwhudson> embarrassingly, given this is my area of the code, i don't really know what it does
[15:56] <wharp> lol
[15:57] <mwhudson> but basically it just sets a configuration option, it shouldn't take very long
[15:58] <wharp> yeah, palintheus is getting a timeout so I think there might be an issue network wise
[15:58] <Palintheus> Im geting: ssh: connect to host bazaar.launchpad.net port 53000: Connection timed out
[15:59] <mwhudson> port 53000 ??
[15:59] <Palintheus> thats what Isaid
[16:00]  * Palintheus double checks /etc/ssh/ssh_config
[16:00] <mwhudson> well, that makes sense on one level:
[16:00] <mwhudson> there's nothing listening on bazaar.launchpad.net:53000
[16:03] <wharp> now when it's pulling something down, is there a progress bar or anything?
[16:11] <Palintheus> gah! had remnants of an old work-around I needed, now its just sitting there, hope its working
[17:39] <zekel> Is there a way to get `bzr st` relative to your current directory? I.e., not show anything in parent folders, and show all paths relative to the current directory?
[17:39] <mwhudson> bzr st . ?
[17:39] <zekel> That shows all the changes in the whole tree.
[17:39] <zekel> And all paths are relative to the top most directory.
[17:40] <mwhudson> er no
[17:40] <mwhudson> it show only changes below the cwd
[17:40] <mwhudson> but it does show paths relative to the root
[17:40] <mwhudson> which is a bug, i guess
[17:40] <zekel> Ah.
[17:41] <zekel> It makes it really tough to look down the st list and type the paths.
[17:42] <vila> what pycurl version is running on pam ? I have a test involving http proxy failing in a rather strange way
[17:42] <vila> s/pam/pqm/ ghaa
[17:44] <mwhudson> vila: whatever's in dapper i'd guess
[17:45] <vila> wow, how do I find what version of pycurl is in dapper ? ;-)
[17:45] <mwhudson> packages.ubuntu.com ?
[17:46] <vila> excellent, thanks
[17:46] <vila> 7.15.0
[17:51] <mwhudson> vila: yes, 7.15.0-1ubuntu1 according to the sysadmins
[18:17] <orospakr> will bazaar look into shipping some of the more popular plugins, like git, svn, and bisect along with the standard source distribution?
[18:17] <orospakr> because that would be pretty awesome.
[18:37] <radix> rebase is tooootally confusing.
[18:42] <mgedmin> bzr: ERROR: dirstate: inconsistent delta, with tree 0. 'fbreader/qvfb/fbreader.desktop' 'fbreader.desktop-20071220183852-09pyx75ogdtn8vpl-6' :(
[18:42]  * mgedmin has the ability to break software
[18:43] <mgedmin> what I did: took my old bzr repositories (that could very well have internal inconsistencies in their data structures), ran bzr upgrade, then tried to remove, replace and add some files
[18:43] <mgedmin> the old repositories were created with an ancient version of bzr that didn't support symlinks, and my source tree had symlinks
[18:45]  * mgedmin wonders if "101 inconsistent parents" in the output of bzr check is bad
[18:46]  * mgedmin assumes that BzrCheckError: Internal check failed: Mismatched basis inventory content. is bad
[18:47] <luks> to fix the dirstate you can try 'bzr branch broken new'
[18:47] <luks> but I have no idea about the output from bzr check
[18:48]  * mgedmin should probably just rm the old history
[18:51] <fullermd> That check error is probably from the broken dirstate.
[18:52] <mgedmin> no, that's in a different repo
[18:52] <mgedmin> er. branc
[19:10] <vila> mwhudson: thanks for the confirmation (was dining)
[19:17] <brilliantnut> Hi, deepjoy and myself are trying to integrate WebDAV with a bzr centralized server.. Could we get some help?
[19:18] <jelmer> brilliantnut, using the webdav plugin?
[19:19] <brilliantnut> yes, or trying to.. :)
[19:19] <jelmer> vila is the person you'd want to talk to
[19:20] <vila> brilliantnut: what bzr version are you using ?
[19:20] <deepjoy> 1.0
[19:20] <deepjoy> :-)
[19:21] <vila> Are you server's admins ?
[19:21] <brilliantnut> yeah,.
[19:21] <vila> use bzr+http then ;-)
[19:22] <deepjoy> We have an ldap server we set up for other authentication
[19:22] <vila> the plugin doesn't support bzr-1.0 until one bug is fixed and you'll get far better results with smart server anyway
[19:22] <deepjoy> so Apache is able to authenticate against it for other use
[19:22] <deepjoy> we're running a smart server right now
[19:22] <vila> deepjoy: you can still use that
[19:22] <deepjoy> performance seems good
[19:23] <vila> with the webdav plugin ?!?!?
[19:23] <vila> sry, miss one line
[19:23] <brilliantnut> no, we haven't been able to integrate the webdav plugin yet.
[19:23] <brilliantnut> we've set up the bzr:// smart server, and its working cool for us.
[19:24] <brilliantnut> Never mind webdav, could you point us to some documentation for setting up bzr+http
[19:24] <brilliantnut> using ldap?
[19:25] <vila> bzr+http with use http authentication, if your Apache is configured to use ldap, there should be nothing to do
[19:25] <deepjoy> so we put the bzr repository directory to be authenticated against
[19:25] <vila> I think so
[19:26] <deepjoy> and the the bzr client should work with the bzr+http:// protocol?
[19:26] <vila> that's the idea ;)
[19:26] <deepjoy> cool
[19:26] <deepjoy> we'll give it a try
[19:26] <deepjoy> :-) thanks a ton
[19:26] <brilliantnut> thanks vila
[19:26] <vila> have you read doc/en/user-guide/http_smart_server.txt
[19:27] <vila> deepjoy, brilliantnut: happy to help (TM)(jam)
[19:27] <jam> well, modulo spiv's recent patch to make it all work smoothly
[19:29] <vila> jam: I can't remember if it was server-side client-side or both ?
[19:29] <jam> I see a change to SmartClient
[19:29] <jam> and one to SmartWSGIApp
[19:29] <jam> so it looks like both
[19:29] <jam> http://bundlebuggy.aaronbentley.com/request/%3C20071214015112.GC14963@steerpike.home.puzzling.org%3E
[19:29] <jam> and
[19:29] <jam> http://bundlebuggy.aaronbentley.com/request/%3C20071214011937.GA26039@steerpike.home.puzzling.org%3E
[19:30] <jam> vila: I'll try to get them reviewed today
[19:30] <jam> which would mean they get merged for 1.1
[19:30] <vila> ok, thks for that
[19:32] <phanatic> jelmer: hey, could you have a look at bzr-gtk bundlebuggy? i get a 503 http error...
[19:32] <jelmer> phanatic, sure, will do
[19:33] <jelmer> abentley: Any specific reason rich-root-pack is still marked as experimental ?
[19:33] <phanatic> jelmer: thanks. i'd like to go through the pending stuff...
[19:35] <jelmer> phanatic: fixed
[19:35] <phanatic> jelmer: cool, thanks :)
[19:42] <CardinalFang> Hi.  I'm having trouble writing a plugin hook, or rather, I have a plugin written and I think I found a bug.
[19:42] <jelmer> phanatic: can you also merge the two requests you've just approved?
[19:43] <jelmer> hi CardinalFang
[19:43] <CardinalFang> """bzrlib.errors.UnknownHook: The Hooks hook 'post_commit' is unknown in this version of bzrlib."""
[19:43] <phanatic> jelmer: sure
[19:44] <jelmer> phanatic, I think it would be nice to maintain the same policy as core bzr: if the original author is a team member, they do the merge, if the original author isn't, the second approver does
[19:45] <jelmer> CardinalFang: What are you calling to install the hook?
[19:45] <phanatic> jelmer: okay :)
[19:49] <CardinalFang> jelmer,   hooks = bzrlib.branch.Hooks(); hooks.install_hook("post_commit", foo)
[19:50] <jelmer> CardinalFang, You don't have to create an instance of hooks
[19:50] <CardinalFang> Ah.
[19:50] <jelmer> just something like this should do:
[19:50] <jelmer> Branch.hooks.install_hook('post_commit', branch_commit_hook)
[19:51] <CardinalFang> jelmer, TypeError: unbound method install_hook() must be called with Hooks instance as first argument (got str instance instead)
[19:53] <jelmer> CardinalFang: What are you calling exactly now?
[19:53] <jelmer> note that hooks is with a lowercase h
[19:55] <CardinalFang> jelmer, Yes.  install_hooks() is a method of a Hooks class.  Calling it as a class method causes that error.
[19:55] <CardinalFang> (My first way was where I roamed after this error message.)
[19:55] <jelmer> CardinalFang: sorry, I should've been a bit clearer
[19:56] <jelmer> there's no need to create your own instance of hooks
[19:56] <jelmer> rather, use the one in the Branch class
[19:56] <jelmer> see my example
[19:57] <CardinalFang> jelmer, I think I know the problem.  I was testing my code my running it standalone.   $ python .bazaar/plugins/foo.py
[19:57] <CardinalFang> "by running"
[19:58] <jelmer> no, standalone should work as well
[19:58] <phanatic> jelmer: patches applied...
[19:58] <jelmer> yep, does here
[19:58] <jelmer> phanatic, Thanks!
[20:39] <brilliantnut> hi vila, this is brilliantnut, and deepjoy, back with some questions.
[20:40] <vila> brilliantnut: pong
[20:40] <brilliantnut> in bzr-smart.py, what should we set the root and prefix parameters to?
[20:41] <brilliantnut> ..
[20:41] <brilliantnut> smart_server_app = wsgi.make_app(
[20:41] <brilliantnut>     root='/srv/example.com/code',
[20:41] <brilliantnut>     prefix='/code/',
[20:41] <brilliantnut> ..
[20:42] <brilliantnut> so, our repository is rooted at /home/vcs/bzr/ , and the trunk  is at /home/vcs/bzr/branches/HEAD
[20:42] <brilliantnut> so, what do we set root and prefix in this configuration to, and what is the significance..
[20:43] <brilliantnut> BTW, we have apache 2.2, and the <Location> is /bzr
[20:43] <brilliantnut> and we don't have any rewrite rules defined.. is that required?
[20:44] <vila>  /bzr points to /home/vcs/bzr/ ?
[20:45] <deepjoy> in the file-system or in the apache conf?
[20:45] <vila> :) Whatever
[20:46] <deepjoy> I guess I'll try both
[20:46] <deepjoy> :-)
[20:47] <vila> I'd say root='/bzr' prefix='/bzr' but you may be hitting bugs recently fixed by spiv, in which case you'll need to update to bzr.dev or wait for bzr 1.1
[20:47] <vila> prefix='/bzr/'
[20:48] <brilliantnut> hmm.
[20:48] <vila> have you read doc/en/user-guide/http_smart_server.txt
[20:48] <brilliantnut> yes, I was quoting that earlier.
[20:49] <vila> ok, just making sure, in the urls mentioned by jam earlier, spiv said: This, combined with the small change to fix the client-side path calculations
[20:49] <vila> I've posted separately, makes bzr+http actually work in non-trivial situations.

[20:50] <jam> brilliantnut: I think before Andrew's patches, you have to set "root = /path/to/repo" and that must line up with "http://host/"
[20:50] <vila> spiv is the definitive reference on these problems anyway
[20:51] <jam> In other words, you set root to the location that is the root of public space
[20:51] <vila> spiv == Andrew
[20:51] <jam> After spiv's patches land (I'm just finishing a review of one)
[20:51] <brilliantnut> Is he here?
[20:51] <jam> brilliantnut: he is, but is in Australia
[20:51] <jam> so we won't be online for at least another hour
[20:51] <jam> anyway, after spiv's patches land, you can do:
[20:51] <jam> root = /path/to/repo
[20:52] <jam> prefix = '/repo/'
[20:52] <jam> And have that exported as
[20:52] <jam> http://host/repo
[20:52] <jam> brilliantnut: am I making sense?
[20:52] <brilliantnut> you are, but would this also require some special handling in httpd.conf?
[20:53] <brilliantnut> or a blind redirect for everything in the /bzr context to the bzr-smart.py would do?
[20:53] <brilliantnut> the latter is what we have set up.
[20:53] <jam> brilliantnut: I *think* a blind redirect works
[20:54] <CardinalFang> I can't manage to get hooks to work.  Can someone give me a dummy "pass" example?
[20:55] <brilliantnut> jam: before Andrew's patches, (i.e. on 1.0), if we set root = /path/to/repo, what should we set prefix to?
[20:55] <jam> It has been a *long* time since I set that up, give me a sec
[20:55] <jam> CardinalFang: what hook
[20:55] <jam> (just to give you an example you want)
[20:57] <deepjoy> FYI we keep getting
[20:57] <deepjoy> bzr: ERROR: Not a branch: "bzr+http://user%40comain.com@dev.domain.com/bzr/branches/HEAD/"
[20:57] <brilliantnut> when we try a checkout or a branch or a bind to that url
[20:58] <jam> brilliantnut: so I set it up to be
[20:58] <deepjoy> if we add or subtract from the URL we get 404's
[20:58] <jam> root = '/home/jameinel/dev/bzr'
[20:58] <jam> prefix='/bzr/'
[20:58] <jam> and in http.conf
[20:58] <jam> I have
[20:58] <jam> Alias /bzr /home/jameinel/dev/bzr
[20:59] <CardinalFang> $ cat dummy.py
[20:59] <CardinalFang> def notify_list(local, master, old_revno, old_revid, new_revno, new_revid): pass
[20:59] <CardinalFang> import bzrlib.branch
[20:59] <CardinalFang> bzrlib.branch.hooks.install_hook("post_commit", dummy)
[20:59] <CardinalFang> $ bzr plugins
[20:59] <CardinalFang> Unable to load plugin 'dummy' from '/home/cmiller/.bazaar/plugins'
[21:00] <jam> brilliantnut: do you have "GET" and "POST" installed
[21:01] <brilliantnut> yes
[21:01] <jam> CardinalFang: check ~/.bzr.log
[21:01] <jam> it should explain why it is failing
[21:01] <jam> but you should do
[21:01] <jam> bzrlib.branch.Branch.hooks.install_hook...
[21:01] <jam> bzrlib.branch
[21:01] <jam> is a module
[21:01] <jam> bzrlib.branch.Branch
[21:01] <jam> is the class
[21:01] <jam> brilliantnut: make sure this works
[21:01] <jam> echo "hello" | POST http://localhost/path/.bzr/smart
[21:01] <jam> It should return something like "ok2"
[21:02] <jam> Technically, it returns
[21:02] <jam> ok\012\n
[21:02] <jam> well, ok\0x012\n
[21:02] <jam> depending on how you want to escape "\001"
[21:04] <jam> brilliantnut: also, at least the way I configured apache, I can browse to: 'http://localhost/bzr/'
[21:04] <jam> just to make sure my Alias is correct
[21:04] <deepjoy> http://localhost/bzr returns a blank page
[21:05] <deepjoy> there are no errors in the apache logs
[21:05] <jam> deepjoy: not an index?
[21:05] <deepjoy> no
[21:07] <jam> deepjoy: try http://localhost/bzr/.bzr
[21:07] <brilliantnut> errorincomplete request
[21:07] <jam> I assume deepjoy and brilliantnut  are working together?
[21:07] <brilliantnut> oh yes, we are.
[21:07] <deepjoy> yes we are. I repeat we did not set up Apache with a rewrite rule.
[21:07] <brilliantnut> in fact, we're sitting in the same cubicle currently.
[21:08] <jam> deepjoy: I think you need to...
[21:08] <deepjoy> <Location /bzr>
[21:08] <deepjoy>    SetHandler mod_python
[21:08] <deepjoy>    PythonInterpreter main_interpreter
[21:08] <deepjoy>    PythonHandler bzrlib.bzr-smart
[21:08] <deepjoy>    AuthType Basic
[21:08] <deepjoy>    AuthName "Bazaar"
[21:08] <deepjoy>    AuthBasicProvider ldap
[21:08] <deepjoy>    Order Allow,Deny
[21:08] <deepjoy>    Allow from All
[21:08] <deepjoy>    AuthLDAPURL "ldap://localhost:389/ou=People,dc=domain,dc=com?mail"
[21:08] <deepjoy>    AuthzLDAPAuthoritative off
[21:08] <deepjoy>    Require valid-user

[21:08] <deepjoy> inside a virtual host
[21:09] <jam> deepjoy: http://rafb.net/p/H0rAE268.html
[21:09] <jam> is my configuration
[21:09] <jam> that said, echo "hello" | ... works
[21:09] <jam> but "bzr log http://localhost/path" does not
[21:09] <jam> it gives me
[21:09] <jam> bzr: ERROR: Not a branch: "bzr+http://localhost/".
[21:10] <jam> (And I can't help but notice it is using the root path, and not the localhost/path)
[21:10] <CardinalFang> jam, that was it, module/class .
[21:10] <jam> "bzr log http://localhost/path" works
[21:10] <jam> but that is because of our default (non-smart) code
[21:11] <brilliantnut> jam: We'll try out your configuration and get back?
[21:11] <jam> sure
[21:11] <jam> I'll be around for a bit
[21:12] <jam> I could have sworn my config used to work, and I obviously can see the smart server
[21:12] <jam> it may just need Andrews patches, I might play with it in a second
[21:14] <brilliantnut> I'm hoping to find a solution without requiring to move to bzr.dev, because it will be harder to sell to the team.. :( deepjoy and myself are already struggling hard against organizational inertia.
[21:14] <jam> brilliantnut: would it be sufficient to have bzr.dev on the server?
[21:14] <jam> And 1.1 should be out Jan 4 or so
[21:15] <brilliantnut> yeah, that might work, we just won't tell anybody about the server  ;)
[21:15] <brilliantnut> but no clients
[21:18] <jam> ... unfortunately my quick test shows that both patches are needed ...
[21:18] <jam> If I have them both, "bzr log bzr+http://localhost/bzr/bzr.dev" works
[21:19] <jam> interesting, it almost seems like only the client patch is needed
[21:21] <brilliantnut> right, so when can we try out the client patch?
[21:22] <brilliantnut> alternatively, could you suggest alternatives to add an authentication layer on top of bzr://
[21:22] <vila> bzr+ssh://
[21:23] <brilliantnut> thats where we started the day..
[21:23] <jam> brilliantnut: bzr+ssh:// possibly using 'bzr_access' on the server to use a single logon with multiple ssh-keys
[21:23] <deepjoy> :-)
[21:24] <jam> brilliantnut: what was the reason not to use bzr+ssh?
[21:24] <deepjoy> we have to eventually auth against ldap
[21:24] <brilliantnut> we have sshd running separately on the server
[21:25] <deepjoy> and since it's a remote machine we'd have to set up a chrooted ssh server with PAM against ldap
[21:25] <deepjoy> so we thought we'd give this a try :-)
[21:25] <brilliantnut> actually, we first arrived on #bzr looking for assistance with the WebDAV plugin :)
[21:26] <brilliantnut> and vila deflected us onto this
[21:26] <deepjoy> didn't think of doing what you just suggested
[21:26] <deepjoy> but makes a lot of sense
[21:26] <brilliantnut> but we didn't consider ssh-keys, maybe we'll look into that option..
[21:27] <deepjoy> thanks a ton guys but it's 3 am in India we gtg get some sleep before a 9 am
[21:27] <jam> deepjoy: sleep well, though spiv should be on in about 1 hour :)
[21:27] <deepjoy> btw BZR is amazing
[21:27] <brilliantnut> gnite.. and thanks for all the fish.
[21:31] <abadger1999> Anyone tested out bzrweb against pack repos?
[21:32] <abadger1999> bazaar-webserve tracebacks and I wanted to see if it was a general problem or something specific.
[21:37] <jam> abadger1999: it sounds like a case of a function not calling "branch.lock_read()" when it should
[21:37] <jam> Knit repositories had a few more "automatic lock" functions
[21:37] <abadger1999> That sounds right.
[21:38] <jam> But they are actually usually a bit harmful because people don't realize that all caches are thrown away at unlock time.
[21:53] <abadger1999> jam: Is it safe to call lock_read() and unlock() even if it's a knit repository?  Or do I need to test for that first
[21:53] <jam> abadger1999: it is always safe
[21:53] <jam> even for weaves
[21:53] <abadger1999> Cool.  Thanks
[22:12] <i386> lifeless: ping
[22:16] <jam> i386: he may show up, but he is technically still on vacation
[22:18] <i386> jam: ahh
[22:18] <i386> Im having dinner with him tonight :)
[22:18] <i386> So I wanted to see if it was all still happening
[22:19] <jam> Well, I couldn't tell you that :)
[22:19] <jam> He just sent an email to the ML, so I believe he is awake.
[22:20] <Solarion> I think bzr horked my svn repo
[22:20] <Solarion> svn: 'Field/.svn/tmp/text-base/makefile.svn-base' has unsupported special file type ''
[22:22] <jelmer> Solarion, is this using bzr-svn?
[22:22] <jelmer> or plain bzr?
[22:22] <Solarion> jelmer: sorry, bzr-svn, to my knowledge
[22:22] <Solarion> I didn't knwo that bzr had builtin svn support
[22:23] <Solarion> I mean, this is using bzr {push,pull}
[22:23] <lifeless> i386: hi
[22:23] <jelmer> Solarion: It doesn't, but you may've simply "bzr add"-ed a .svn directory
[22:23] <jelmer> Solarion: Please file a bug
[22:23] <Solarion> jelmer: I sent the stacktrace from trying to pull it to bazaar@lists.ubuntu.com like a good buy
[22:24] <Solarion> until then, I need to figure out how to unhork the repo so I can use it.  :)
[22:24] <jelmer> Solarion, the error suggests this is a working copy, not a repository
[22:25] <Solarion> jelmer: what do you mean?
[22:26] <jelmer> Solarion: You say there is corruption in the svn repository, but the path (.svn/tmp/text-base/...) is a working copy path.
[22:27] <Solarion> jelmer: this is from a straight svn checkout, with nothing existing.
[22:27] <jelmer> Solarion, What were you doing before this error occurred?
[22:27] <Solarion> jelmer: I had bzr push'ed it from a different computer (sitll ubuntu gutsy)
[22:30] <jelmer> Solarion, How do you mean? You ran bzr push /to/ the svn working copy?
[22:30] <Solarion> jelmer: I have an svn repo at svn+ssh://host/dir
[22:30] <Solarion> I used bzr pull to get it on my notebook (having bzr push'ed it from the workstation).
[22:31] <Solarion> I made huge changes, then push'ed them back up from the laptop.
[22:31] <Solarion> I now cannot check out from the repository using either bzr nor using svn.
[22:31] <Solarion> bzr gives me a backtrace; svn gives me the error I mentioned here.
[22:31] <jelmer> Solarion: something like "svn co svn+ssh://host/dir" breaks?
[22:32] <Solarion> yes
[22:32] <Solarion> with the error I specified.
[22:32] <jelmer> Solarion: Please post the backtrace of "bzr co" as well
[22:32] <Solarion> jelmer: I've sent it to the bazaar list; are you a moderator on it?
[22:32] <Solarion> it's awaiting moderation, since I'm not on the list
[22:33] <jelmer> no
[22:33] <jelmer> Solarion: what version of bzr-svn/bzr?
[22:33] <Solarion> http://pastebin.com/d58f43fd4
[22:34] <Solarion> whatever's in ubuntu gutsy (bzr 0.90.0, bzr-svn 0.4.1-1
[22:35] <jelmer> ah, looks like it breaks on a symlink
[22:35] <Solarion> I told the boss man that he should use bzr, but he wanted to stay with svn because it's better supported by Apple
[22:36] <Solarion> (though he's not opposed to bzr)
[22:36] <jelmer> Please try running bzr pull again, but with the BZR_PDB=1 environment variable set
[22:36] <jelmer> that should get you into a debugger
[22:36] <Solarion> ok
[22:36] <jelmer> please print the contents of the following variables:
[22:36] <Solarion> what is the syntax for printing the variables?
[22:37] <jelmer> print lines
[22:37] <jelmer> print path
[22:37] <Solarion> (Pdb) print lines
[22:37] <Solarion> []
[22:37] <Solarion> (Pdb) print path
[22:37] <Solarion> Field/makefile
[22:38] <Solarion> jelmer: are you the bzr-svn guy?
[22:38] <jelmer> Solarion: yup, I'm the main author
[22:38] <Solarion> jelmer: congrats; it's awesome stuff
[22:38] <jelmer> did you add a file called "Field/makefile" from bazaar that is a symlink?
[22:38] <Solarion> not knowingly, but possibly; I did a bulk add
[22:40] <jelmer> Solarion, in the original tree, what does Field/makefile link to?
[22:40] <Solarion> I dunno; I'm not on my notebook atm
[22:41]  * Solarion starts up his notebook
[22:45] <Solarion> ok, it is a symlink to makefile.subdir
[22:46] <Solarion> what do I need to do?
[22:52] <Solarion> jelmer: still there
[22:52] <Solarion> ?
[22:53] <jelmer> yeah, I'm just checking how this bug could ever occur
[22:54] <Solarion> jelmer: it's a symlink to a file in the parent directory, if that's any help
[22:55] <Solarion> makefile is a symlink to ../makefile.subdir
[22:58] <igc> morning all
[22:59] <jelmer> Solarion: has the type ever changed? I.e. was Field/makefile ever a regular file?
[23:01] <Solarion> jelmer: don't think so
[23:05] <jelmer> what were the changes to this file as reported by `svn log' ?
[23:05] <jelmer> In particular "svn diff -c <rev> svn+ssh://host/../Field/makefile" may be interesting
[23:06] <Solarion> I can't get a full checkout because of this problem
[23:06] <jelmer> Solarion, You can run svn log and svn diff directly against the repository
[23:07] <Solarion> log says "Added non-object files.
[23:07] <Solarion> which is true
[23:08] <jelmer> Solarion: and diff for that particular file?
[23:09] <Solarion> svn diff -r 5:6 svn+ssh://host/path/to/file states nothing
[23:10] <Solarion> before 5, it says "Unable to find <file> in revision <revisions>'
[23:10] <jelmer> hmm
[23:12] <Solarion> bzr (in the copy I pushed from) says "[23:13] <Solarion> notebook has same versions of bzr and bzr-svn
[23:15] <Solarion> I tried to push a new version with the symlink blown away, and I was able to but it still chokes
[23:16] <jelmer> both svn and bzr?
[23:17] <Solarion> yes
[23:18] <Solarion> well, sorta
[23:19] <Solarion> apparently, with the file gone, svn only chokes *after* everything's been checked out
[23:19] <jelmer> what error?
[23:19] <Solarion> actually, hold on.
[23:20] <Solarion> if I remove the symlink, svn no longer chokes there.
[23:21] <Solarion> yes, svn no longer chokes now that I've removed the symlinks
[23:21] <Solarion> bzr, however, still chokes
[23:22] <Solarion> even when doing a fresh branch
[23:23] <Solarion> jelmer: any idea what's going on yet?
[23:24] <jelmer> Solarion: I'm still not sure why it's setting the symlink correctly
[23:24] <jelmer> It's easy to make the error on bzr go away
[23:24] <vila> wow, lp is making use of --fix lp:nnnn !!
[23:24] <vila> congrats to lp guys :)
[23:24] <jelmer> but I'd rather fix the problem that's causing it
[23:24] <jelmer> vila: how?
[23:25] <Solarion> yes, me too, since it prvents others from checking things out.
[23:25] <vila> look at bug #176643
[23:25] <ubotu> Launchpad bug 176643 in ubuntu "SoundBlater 5.1 digital soundcard doesn't work all the time" [Undecided,Incomplete] https://launchpad.net/bugs/176643
[23:25] <vila> errr bug #177643 ;-)
[23:25] <ubotu> Launchpad bug 177643 in bzr "http auth pycurl is broken" [High,Fix released] https://launchpad.net/bugs/177643
[23:25] <Solarion> jelmer: it's definitely in the symlink adding code; I cannot add a symlink from bzr and push it to svn and have svn not ide.
[23:25] <Solarion> I just tried, and now things are horked again
[23:26] <Solarion> bbiab
[23:28] <spiv> vila: I think jml is the one to thank for that
[23:29] <vila> jml: very nice Christmas gift, thanks :)
[23:29] <jml> my pleasure
[23:30] <Solarion> back
[23:30] <jelmer> Solarion, I'm trying to reproduce it here
[23:30] <Solarion> jelmer: are you sure you're looking at verion 0.41?
[23:30] <Solarion> 0.4.1, rather
[23:32] <jelmer> no, I'm at 0.4.6
[23:32] <jelmer> but I don't recal fixing it
[23:33] <Solarion> if you can't reproduce it in 0.4.6...  :)
[23:35] <Solarion> does 0.4.6 work iwth bzr 0.90?
[23:38] <jelmer> yep, I can reproduce it
[23:38] <jelmer> Solarion, no, it requires 1.0
[23:39] <Solarion> heh
[23:39] <Solarion> maybe i should re-install bzr-svn then.  :)
[23:40] <Solarion> jelmer: so we're halfway there, eh?
[23:40] <jelmer> yep
[23:41] <Solarion> anything I can help with?
[23:42] <jelmer> nope, just need a few minutes to write a testcase and get this fixed
[23:42] <jelmer> it should be fairly trivial
[23:42] <Solarion> found the bug?
[23:43] <Solarion> trivially-fixed bugs are the best oens
[23:46] <Solarion> hey jamesh
[23:48] <jamesh> hello
[23:56]  * Solarion wonders if jelmer is still around.  :)
[23:57] <Solarion> right, I'm off then.  :)