[00:02] <RenatoSilva> verterok: currently to_file expects str, if we change it with codecs.getwriter, it would now expect unicode
[00:03] <RenatoSilva> verterok: btw, why do you use xml-rpc in java plugin? why not talk directly with xmloputput?
[00:04] <verterok> RenatoSilva: I got lost :)
[00:05] <verterok> RenatoSilva: directly how?
[00:05] <RenatoSilva> verterok: currently to_file expects str, if we change it with codecs.getwriter, it would now expect unicode, and that py2 auto ascii encode/decode thing would get place, and would raise errors for non-ascii stuff...
[00:05] <RenatoSilva> verterok: I mean for example
[00:06] <RenatoSilva> verterok: you want to pull branch's log, then why not you run bzr locally and parse the XML response? why do you have to send an xml-rpc call to a local server, then get the response and parse it?
[00:06] <RenatoSilva> verterok: the server runs bzr locally anyway
[00:06] <verterok> RenatoSilva: mainly for performance reasons
[00:07] <verterok> RenatoSilva: the startup time in windows is terrible
[00:07] <RenatoSilva> verterok: you mean xml-rpc server keeps the executable in memory?
[00:07] <verterok> RenatoSilva: I'll take a look to the codecs.getwritter, don't have the code fresh enough in my head
[00:08] <verterok> RenatoSilva: right, only oone bzr process
[00:08] <verterok> *one
[00:08] <RenatoSilva> verterok: there isn't a way to do this in java?
[00:08] <RenatoSilva> verterok: if python does, java does it too ^^
[00:09] <verterok> RenatoSilva: hmm...what?
[00:09] <RenatoSilva> verterok: the plugin could load bzr.exe into memory
[00:09] <verterok> RenatoSilva: we need to use bzrlib API
[00:10] <RenatoSilva> verterok: oh I see, bzr-java-lib...
[00:10] <verterok> RenatoSilva: I'm missing something, could you extend? :)
[00:11] <RenatoSilva> verterok: you mean start bzr.exe every time you need to run a command is too slow, so you put xml-rpc server in scene for keeping one executable in memory, and run the commands faster, right?
[00:12] <verterok> RenatoSilva: yeap, exactly
[00:12] <verterok> RenatoSilva: take a look to the different *Runner's in bzr-java-lib
[00:13] <RenatoSilva> verterok: I don't have the code right now...
[00:13] <verterok> RenatoSilva: the XMLRpc extends the CommandLine
[00:14] <RenatoSilva> verterok: my idea was, when the plugin is loaded, it loads the executable into memory.When it wants to run something, then it activates bzr-java-lib, and passes the cached executable, so that bzr-java-lib does not have to start the proccess.
[00:14] <RenatoSilva> verterok: both bzr-eclipse and bzr-java-lib would need changes in the code to achieve this
[00:15] <RenatoSilva> verterok: however I'm not sure if you can do this kind of thing in Java
[00:15] <verterok> RenatoSilva: how would you load the executable into memory and use it several times?
[00:15] <RenatoSilva> verterok: I'm guessing: if python can, then yes java can!
[00:15] <verterok> RenatoSilva: I think it could be possible with JNI...but you know...JNI
[00:16] <RenatoSilva> verterok: and how python does?
[00:17] <RenatoSilva> verterok: how does the xml-rpc server loads and keeps the executable in memory?
[00:17] <verterok> RenatoSilva: bzr-java-lib executes: bzr start-xmlrpc in a subprocess
[00:17] <RenatoSilva> verterok: also, maybe bazaar should have some kind of "daemon" mode
[00:21] <RenatoSilva> verterok: oh I see, the server is a bzr instance itself + xmlrpc plugin. When you send a command, the server is "inside bzr", so it does not need to run bzr.exe. I thought for a moment that run_bzr was running the process...
[00:21] <verterok> RenatoSilva: there is the bzr-serivce plugin
[00:21] <verterok> RenatoSilva: right
[00:21] <verterok> :)
[00:22] <RenatoSilva> verterok: nice
[00:23] <RenatoSilva> verterok: how does it work? you send raw arguments to a net socket?
[00:23] <verterok> RenatoSilva: the bzr-service plugin? or the xmlrpc service?
[00:23] <RenatoSilva> verterok: or do you have a formal protocol?
[00:23] <RenatoSilva> verterok: bzr-service
[00:24] <verterok> RenatoSilva: jam wrote it, I think it send the command args via the socket
[00:25] <RenatoSilva> verterok: hum, what do you think is simpler code, talking with xmlrpc or bzr directly?
[00:25] <verterok> RenatoSilva: bzr via bzrlib?
[00:27] <RenatoSilva> verterok: ok, but you're the bzr-java-lib developer too, right? :)
[00:27] <RenatoSilva> verterok: not talking about xmloutput anymore hehe
[00:27] <verterok> RenatoSilva: xmlrpc is more flexible in that you can talk to it from almost every language
[00:27] <lifeless> one issue with xml though
[00:27] <RenatoSilva> verterok: every language?
[00:27] <lifeless> not all bzr commit data can be put into xml now
[00:28] <poolie> lifeless: hi
[00:28] <RenatoSilva> lifeless: yeah, xml is maybe an unecessary middleware
[00:28] <verterok> RenatoSilva: bzrlib is only usable from python
[00:28] <lifeless> hi poolie
[00:29] <poolie> what did you mean by "guess-good"?
[00:29] <lifeless> that it had tried to help you ;)
[00:29] <RenatoSilva> lifeless: also, things get weird when you send xmloutput stuff through xml-rpc: xml inside xml...
[00:30] <poolie> and "it" is?
[00:30] <verterok> RenatoSilva: the current xmlrpc service is a sort of a hack :)
[00:30] <lifeless> bzr-guess
[00:30] <lifeless> 're bzr-guess helping you that is good to know'
[00:30] <RenatoSilva> verterok: sorry I read bzrlib as "bza-java-lib"
[00:31] <RenatoSilva> verterok: what I mean with " hum, what do you think is simpler code, talking with xmlrpc or bzr directly?" is
[00:31] <RenatoSilva> verterok: from java code
[00:31] <RenatoSilva> verterok: in bzr-java-lib
[00:31] <poolie> oh ok
[00:33] <verterok> RenatoSilva: currently there is no way to talk to bzrlib directly from Java, I'm trying to implement OSLocks in Java, in order to use Jython
[00:33] <RenatoSilva> verterok: maybe being able to directly send arguments to bzr, but having the process chached in memory, maybe it would be eassier to java code...
[00:33] <RenatoSilva> verterok: I'm talking about service plugin
[00:34] <verterok> RenatoSilva: xmlrpc is quite simple, you just send basic data types and receive the same (Strings, int, HashMap, Arrays)
[00:35] <RenatoSilva> verterok: imagine  in java code something like Bazaar bzr = Bazaar.getServiceInstance(); then you bzr.run('log -r 10..12') ro so, instead of building an XML and send as xml-rpc
[00:36] <RenatoSilva> verterok: what would be easier, that's what I mean
[00:36] <RenatoSilva> s/ro/or
[00:36] <verterok> RenatoSilva: that's the way bzr-java-lib is sending the command :)
[00:37] <RenatoSilva> verterok: anyway, would  the plugin work if bzr.exe is in another host and you don't have one locally?
[00:37] <verterok> RenatoSilva: but it's wrapped in IBazaarClient interface
[00:38] <mwhudson> jelmer: we preserve the sha1 cache between runs now
[00:39] <poolie> lifeless: quick call?
[00:40] <RenatoSilva> verterok: that's the way bzr-java-lib is sending the command ---> bzr-java-lib could implement the cached process then, using the service plugin, so that users won't need xml-rpc anymore to run bzr faster...
[00:41] <RenatoSilva> verterok: users could choose between xml-rpc or direct talk
[00:42] <lifeless> poolie: sure
[00:43] <RenatoSilva> .
[00:46] <verterok> RenatoSilva: there is no cached process, it's just a python subprocess running a server
[00:46] <verterok> RenatoSilva: the advantage of xmlrpc is that's more standard vs a custom socket service
[00:47] <RenatoSilva> verterok: by cached process I just mean the service plugin
[00:47] <verterok> RenatoSilva: in any case, the big plan is to have a more flexible xmlrpc service, using methods instead of running bzr commands
[00:48] <verterok> RenatoSilva: and avoiding to send xml in xml ;)
[00:48] <RenatoSilva> ok :)
[00:49] <verterok> RenatoSilva: also I thinked a *lot* about using other protocol insted of xmlrpc, but the main issue are the dependencies
[00:50] <verterok> RenatoSilva: e.g: using google protocol buffers
[00:50] <verterok> RenatoSilva: the other option is to use bzr smart server
[00:50] <RenatoSilva> verterok: the protocol could be just command line arguments
[00:51] <RenatoSilva> verterok: Bazaar.getServiceinstance().run("--version")
[00:51] <verterok> RenatoSilva: yes, but we need a way to receive the information, and possibly streaming it ;)
[00:51] <RenatoSilva> verterok: through a socket
[00:52] <verterok> RenatoSilva: I mean the format of this info
[00:52] <RenatoSilva> verterok: you receive the response throught the socket, then you parse the xmloutput output
[00:52] <RenatoSilva> verterok: format = keep using xmloutput
[00:53] <verterok> RenatoSilva: with the current xmlrpc service in xmloutput (or with any other transport, e.g: socket) we need to send the whole info back
[00:54] <verterok> RenatoSilva: e.g: bzr log -v of bzr trunk is going to take a while, and it's a lot of info kept in memory (in the case of xmlrpc+xmloutput)
[00:54] <RenatoSilva> verterok: List<IBzrLog> logs = XMLLogParser.parse(Bazaar.getServiceInstance(BZR_PORT).run('xmllog'))
[00:54] <verterok> RenatoSilva: we could stream with a custom socket server
[00:54] <verterok> RenatoSilva: but why reinvent the wheel ;)
[00:56] <RenatoSilva> verterok: what are you planning to do to stream it?
[00:56] <verterok> RenatoSilva: also, using commands isn't such a good idea, in the case of bzr-java-lib it works, but it would be a lot better if we have custom service methods to call
[00:57] <RenatoSilva> verterok: ok a more computer-friendly protocol, cmd line is mostly user-friendly, I agree
[00:58] <verterok> RenatoSilva: I think that the first step could be to implement the method to replace the xmllog command, and customize the xmlrpc server to stream the response
[00:58] <RenatoSilva> verterok: doesn't bzr-service stream the response too?
[01:05] <RenatoSilva> verterok: I've heard it's mature...or would that be JRuby?
[01:05] <verterok> RenatoSilva: I'm started a little experiment, write a Java version of the OSLocks, to be used with Jython
[01:06] <RenatoSilva> verterok: what's OSLocks?
[01:06] <verterok> lifeless: do you think that ^ might work? :)
[01:07] <RenatoSilva> verterok: doesn't Jython gives you full access to python code from java?
[01:07] <RenatoSilva> verterok: what is OSLocks and why do you need it
[01:07] <verterok> RenatoSilva: bzr grabs a lock (read and/or write) on some files, it uses fctnl module or pywin32 to do that
[01:08] <verterok> RenatoSilva: as the code is C, Jython don't have access to those modules
[01:08] <verterok> RenatoSilva: Jython only can use pure python modules
[01:09] <RenatoSilva> verterok: and you have something in python to access the C code, doesn't bzrlib do this for you?
[01:09] <RenatoSilva> verterok: shouldn't all bzr C code be wrapped to python for proper third-party access?
[01:10] <verterok> RenatoSilva: you can write python modules in C, but you can use those in Jython
[01:10] <verterok> RenatoSilva: yes, but Jython can't import the required modules
[01:10] <RenatoSilva> verterok: I see
[01:11] <RenatoSilva> verterok: then Jython is not a full python VM right?
[01:11] <verterok> RenatoSilva: it's
[01:11] <RenatoSilva> verterok: environment I mean
[01:11] <verterok> RenatoSilva: but it can't use C extensions
[01:12] <verterok> RenatoSilva: some C extension are already ported to Java
[01:12] <RenatoSilva> verterok: as it does not behave as a complete python vm (containing the c access module)
[01:13] <RenatoSilva> verterok: if python itself can use C extensions, then Jython should be able too maybe
[01:13] <verterok> RenatoSilva: because the "system" langauages are different, some python C extensions were ported to Java, so Jython can take advantage of it's speed
[01:14] <verterok> RenatoSilva: not really, there is some related work in progress in JRuby using JNA, but not in Jython...yet
[01:14] <RenatoSilva> verterok: ok
[01:16] <wgrant> RenatoSilva: It's not a matter of having a "c access module". CPython extensions use the CPython C API, which a Java implementation of Python obviously doesn't have.
[01:16]  * verterok --> dinner, bbl
[01:17] <thumper> jelmer: lots of kudos to you, bzr-git imports working well now thanks to mwhudson's recent work to remember the sha1 cache
[01:17] <thumper> jelmer: can we do the kernel yet?
[01:17] <thumper> jelmer: mwhudson requested vlc which worked taking 13 or so hours, with 34k mainline revisions
[01:19] <RenatoSilva> wgrant: I see
[01:20]  * RenatoSilva --> go home
[01:20] <RenatoSilva> thanks everybody
[01:20] <wgrant> thumper: Now that you've perfected bzr-git imports, can we get bzr-svn too?
[01:21] <lifeless> verterok: sorry was on a call
[01:21] <lifeless> verterok: whats the question in short?
[01:21] <thumper> wgrant: we are trying
[01:21] <thumper> wgrant: but it has issues with python 2.4 right now
[01:21] <thumper> wgrant: and our migration to python 2.5 took a hit with the developer working on it being sick for a week
[01:21] <wgrant> thumper: Well, I see a solution to that that you need to implement in a few months...
[01:21] <wgrant> Oh, so you're actually doing it>
[01:21] <thumper> wgrant: but it is very much in the "near future"
[01:22] <wgrant> But why only 2.5? Because Hardy doesn't have 2.6?
[01:22] <mwhudson> thumper: https://code.edge.launchpad.net/~vcs-imports/wine/git-trunk still not happy :(
[01:22] <thumper> wgrant: because we need to migrate zope through 2.5 first
[01:22] <thumper> wgrant: we aren't jumping two versions at once
[01:22] <mwhudson> wgrant: because going 2.4 -> 2.5 -> 2.6 is going to be easier than 2.4 -> 2.6
[01:23] <wgrant> I guess so.
[01:23] <thumper> mwhudson: -> #launchpad
[01:24] <lifeless> mwhudson: !assertion
[01:28] <mwhudson> lifeless: it's an opinion but a pretty firmly held one
[01:29] <lifeless> mwhudson: yeah, I realise.
[01:29] <lifeless> I hold the contrary position. Also fairly firmly ;)
[01:31] <mwhudson> well it's not either of us doing the work, so i guess it doesn't matter very much
[01:43] <poolie> thumper: were you going to  or did you propose an lca miniconf?
[01:50] <thumper> poolie: thanks for reminding me, I'll talk to the people this afternoon
[01:50] <verterok> lifeless: np
[01:51] <poolie> jam, hello, if you're still here
[01:52] <verterok> lifeless: it wasn't a question actually :), I'll try to add an OSLock implementation for Jython, using java FileLock class
[01:53] <verterok> lifeless: is there any specific issues I should take care of?
[01:53] <verterok> lifeless: FileLock docs: http://java.sun.com/javase/6/docs/api/java/nio/channels/FileLock.html
[01:54] <lifeless> verterok: not really
[01:54] <lifeless> the main thing would be to test interactions with python bzr oslocking of the dirstate file
[01:54] <lifeless> make sure they mutex properly
[01:55] <lifeless> (read locks sharable, write locks exclude all readers and writers)
[01:55] <verterok> lifeless: ok, thanks for the tips :)
[02:20] <krisfremen> hi all, i have a repo that i made weird changes to, how can i just make one directory go back to the last comit?
[02:20] <lifeless> bzr revert -r -2 directoryname
[02:21] <krisfremen> thanks lifeless
[02:31] <garyvdm> I found a class that tests PyQt models. I'm using it now in qbzr.
[02:31] <garyvdm> http://paste.ubuntu.com/213349/
[02:32] <garyvdm> But it use assert(). How important is it to use TestCase.assert*()?
[02:33] <poolie> garyvdm: the main difference is that assert is skipped when run with python -O
[02:33] <poolie> so
[02:33] <poolie> we ban its use in the main codebase
[02:33] <poolie> in tests, it's ok
[02:33] <poolie> but not great
[02:34] <garyvdm> poolie: So do you think I should customize it?
[02:34] <poolie> hm
[02:35] <poolie> well, what are you going to do with it?
[02:35] <poolie> copy it into qbzr?
[02:35] <garyvdm> Yes - I have copied it into qbzr because it is not installed with pyqt
[02:36] <garyvdm> And I call it from qbzr's tests
[02:37] <poolie> i wouldn't stress about it
[02:37] <garyvdm> Ok
[02:38] <poolie> hope that helps :)
[02:39] <poolie> for inconclusive advice :)
[02:39] <garyvdm> lol
[03:03] <garyvdm> Hmm - I can get a new test to run.
[03:04] <garyvdm> This is qbzr/lib/tests/test_annotate.py : http://paste.ubuntu.com/213366/
[03:05] <garyvdm> bzr selftest -s bp.qbzr.lib.tests.test_annotate = Ran 0 tests
[03:06] <garyvdm> *cant get a new test...
[03:07] <lifeless> bzr selftest qbzr.*annotate
[03:07] <garyvdm> Ran 0 tests in 0.149s
[03:07] <lifeless> its not being found then
[03:07] <lifeless> hav you added the file to the qbzr test list?
[03:08] <garyvdm> Ah
[03:08] <garyvdm> No
[03:08] <garyvdm> Thank lifeless.
[03:16] <lifeless> poolie: ping; a) hunger, b) you'll need time to get home for your call
[03:16] <poolie> lifeless: btw did you file a bug for the unstacking issue with inventories?
[03:16] <poolie> well
[03:16] <poolie> if you didn't it's ok, and i might just comment on 391411
[03:18] <lifeless> I hadn't no
[03:18] <lifeless> I was going to, but your adding a comment would be great
[03:18] <lifeless> I've isolated my machine turn offs
[03:18] <poolie> spiv, are you here?
[03:18] <lifeless> if I hold the left side of my laptop and press firmly (key press firmness) on the top right, it turns off.
[03:19] <poolie> that's handy
[03:19] <poolie> much better than needing all that clicking through menus :)
[03:20] <lifeless> ctrl-left click when the right edge is on my knee is enough
[03:26] <MT-> How hard is it to create a bzr repository? Is there any simple guide?
[03:29] <lifeless> bzr init-repo DIRECTORY
[03:29] <lifeless> but you may not mean what you think you mean
[03:29] <lifeless> what do you want to achieve, in nontechnical terms
[03:31] <MT-> Me make pushy wordy stuff to metal box thingy and have wordy stuff in metal box thingy to get later :P
[03:31] <MT-> I had to have fun with that
[03:31] <lifeless> :)
[03:31] <MT-> I want to create the repository on the server that was freshly installed with Ubuntu
[03:33] <jam> poolie: I'm around for a bit now
[03:34] <poolie> jam, was just going to say hi
[03:34] <poolie> so "hi'
[03:34] <poolie> lifeless, leaving now
[03:34] <jam> hi poolie
[03:35] <lifeless> MT-: sure; but I mean - do you want to put a new project under bzr control? or package trees, or ..?
[03:36] <MT-> lifeless: I'll eventually want to put projects in it, I just want the repo available to do things with, fresh installation all the way to having groups of users that can edit specific branches
[03:37] <lifeless> MT-: so, bzr doesn't really get organised that way :)
[03:37] <lifeless> and the very question led me to suspect you were starting off oddly ;)
[03:37] <lifeless> MT-: what VCS are you most familiar with?
[03:38] <MT-> lifeless: bzr, but using with launchpad
[03:38] <lifeless> ok
[03:38] <lifeless> so on launchpad each branch is in its own repo
[03:38] <MT-> I've setup svn before and had it running over http[
[03:38] <MT-> oh
[03:38] <lifeless> and bzr will create a repo automatically when you push if there isn't one
[03:40] <spiv> poolie: I am, yeah.
[03:41] <lifeless> MT-: if you want http/s hosting, you can set that up now
[03:41] <MT-> I'd prefer only ssh
[03:41] <lifeless> in which case you're already setup:)
[03:42] <MT-> not yet :P
[03:42] <MT-> I need to find the IP of the server so I can install bzr
[03:46] <lifeless> MT-: oh, well thats entirely different :)
[03:46] <lifeless> anyhow, use unix permissions to manage access
[03:47] <lifeless> try to keep the permissions for an entire repo the same
[03:47] <lifeless> (by which I mean *keep them the same*)
[03:47] <lifeless> just create as many repos as you need
[03:48] <lifeless> and for single-shot things, just use 'bzr push bzr+ssh://host/...foo' to push up a branch
[03:48] <MT-> Can I set where the repos get created?
[03:48] <lifeless> when bzr automatically creates one, its inline with the branch
[03:49] <lifeless> otherwise they are all manually created
[03:54] <MT-> lifeless: I just meant, can I tell bzr that whenever somebody tried to do bzr push bzr+ssh://server/blah, blah is created within /bzr
[03:55] <lifeless> that would push to /blah
[03:55] <lifeless> so its very easy, don't give them permission to write to / :)
[03:56] <lifeless> what I mean is bzr+ssh://server/ == / on the filesystem (unless you've chrooted your ssh environment)
[03:58] <spiv> Another option is to configure a different bzr serve command line in your ~/.ssh/authorized_keys.
[03:58] <spiv> See e.g. contrib/bzr_ssh_path_limiter \
[03:58] <lifeless> spiv: bzr on the client won't run that though
[03:58] <lifeless> spiv: isn't the result a permission error ?
[03:59] <spiv> lifeless: you can create a key that always runs a specified command no matter what the client asks for
[03:59] <MT-> I just found the IP
[03:59] <lifeless> fooding
[03:59] <spiv> lifeless: (and that command can then inspect an env variable to get the command client asked for)
[04:03] <MT-> So what I need to do is create a bzr group, add myself to the group, then set the group to own the directory where branches can be created in
[04:12] <MT-> lifeless: does that sound like what you were saying?
[04:17] <MT-> it didn't like that
[04:44] <poolie> spiv, so, i'm ready when you are
[05:11] <spiv> poolie: ok
[05:22] <MT-> When I try to push, I'm getting this error - bzr: ERROR: Unsupported protocol for url "sftp://bzr@208.107.52.90/bzr/tmp": Unable to import paramiko (required for sftp support): No module named paramiko
[05:22] <MT-> lovely that I pasted my ip...
[05:26] <MT-> ok, I figured it out
[05:29] <MT-> YES! I pushed it - although it still needs proper permission setup
[05:57] <lifeless> MT-: use bzr+ssh rather than sftp
[05:57] <lifeless> MT-: its a lot faster
[05:59] <MT-> lifeless: I was just working off a guide online. I think I'm readdy to tackle loggerhead now but I'm not fully sure how
[05:59] <MT-> looks like it defaults to port 8080
[06:00] <MT-> ssh seems to work exactly the same except as you said, much faster :)
[06:02] <MT-> I need to wait for the guy to get home and forward the port. We don't have a decent router setup yet.
[06:32] <poolie> ok, back into 391411
[06:47] <MT-> lifeless: you still around?
[06:47] <lifeless> by accounts
[06:47] <lifeless> though I'm working on shrinking
[06:50] <MT-> lifeless: When I create a branch by pushing it, the branch is owner/group is me, so other users can't access it. How can I make it so the owner is bzr and the group is the top level directory of the files? If I just push a random branch the group is bzr for all files and if I push to a branch I set the group to devs the files group is devs.
[06:50] <MT-> hopefully that's easy to deal with. I'm probably thinking wrong too
[06:51] <MT-> if I do bzr initi-repo it's root:root, I imagine just changing that to bzr:devs would be easiest
[06:52] <MT-> looks like I should justuse mkdir instead of init-repo instead though, maybe
[06:52] <poolie> lifeless: filed bug 397286 from our call
[06:52] <lifeless> poolie: thanks
[06:53] <lifeless> MT-: set the sticky bit
[06:53] <MT-> ?
[06:55] <lifeless> MT-: unix permissions
[06:56] <MT-> I've never heard of that..
[06:56] <vila> hi all
[06:56] <MT-> hi
[06:56] <poolie> hey vila
[06:56] <lifeless> actually, its not the sticky bit thats needed.
[06:56] <lifeless> one sec
[06:57] <MT-> lifeless: +t ?
[06:57] <MT-> or apparently 1000
[07:00] <MT-> lifeless: whenever you know, I'm all eyes :)
[07:00] <MT-> s/know/remember/
[07:04] <lifeless> set the group on the dir; oh, and the umask needs to be altered to preserve g+w in new subdirs
[07:04] <lifeless> that should be all thats needed
[07:04] <MT-> looks like +s on the parent directory
[07:05] <MT-> hrm, that preserved the group
[07:06] <MT-> shouldn't that inheret user too?
[07:07] <MT-> or is that not possible?
[07:14] <lifeless> you'd need everyone to be the same user for that to happen :P
[07:15] <MT-> that's ok then :P
[07:18] <MT-> I love how loggerhead is breaking... oh well
[07:18] <MT-> not important atm :P
[07:19] <MT-> lifeless: I'm confused though.. I add a file to the branch, push the branch, and then no files show up in it
[07:20] <MT-> I guess it mush just be a server thing. I pull it and it shows up. Where does bzr keep the files?
[07:21] <lifeless> MT-: compressed in a database in .bzr/repository
[07:21] <MT-> oh
[07:22] <MT-> wow... I'm learning a LOT today
[07:25] <MT-> lifeless: thanks for all the help :
[07:25] <MT-> :)*
[07:26] <lifeless> anytime
[07:27] <MT-> probably ina few minutes :P
[07:34] <lifeless> EOD
[07:34] <MT-> You mean F?
[07:34] <MT-> oh - day
[07:36] <MT-> lifeless: does that mean you're gone or here for a few minutes?
[07:36] <poolie> night
[07:57] <fullermd> I'm pretty sure bzr takes care of preserving the g+w if it's set on <mumble>.  I don't believe it tried to explicitly set the group though.
[07:57] <fullermd> Depending on FS semantics, it'll inherit automatically all the time (BSD) or when the setgid bit is set on the dir (SysV)
[07:59] <MT-> I think bzr is working perfect now - but loggerhead is irritating me
[08:23] <poolie> vila: bzr-gtk release woo-hoo!
[08:23] <vila> poolie: <cough> yeah ! First release ! :-/
[08:23] <poolie> mm, why first release?
[08:23] <poolie> your first one?
[08:23] <vila> Hopefully someone can populate the PPAs from there
[08:23] <vila> poolie: yes :)
[08:26] <MT-> I'm trying to setup loggerhead. I have no idea what I'm doing... I installed it and I have no idea where to go from here. There doesn't seem to be any apache config created for it
[08:26] <vila> MT-: Good idea ! You should file a bug asking for one
[08:26] <MT-> vila: idk if I screwed up or not
[08:27] <MT-> vila: Do you know what I'm supposed to do?
[08:27] <poolie> i think there's a readme file describing what to do
[08:28] <vila> MT-: no, but I know that you shouldn't have such doubts as a newcomer, so filing a bug right now, before getting your hands dirty will help make future newcomers experience better :)
[08:28] <vila> MT-: try pinging beuno / mwhudson as the usual suspects
[08:29] <MT-> vila: I already screwed with too much stuff. If I file a bug on it, It'll be on a fresh system. I did have it working for a short while before I did something stupid (following a random guide)
[08:30] <MT-> I'll try to flush everything about loggerhead off this sytem
[08:31] <MT-> vila: it's supposed to open port 8080 for it, right?
[08:32] <vila> MT-: sorry, I never installed loggerhead myself so I can't really help here :-/
[08:32] <MT-> oh
[08:33] <vila> I kind of understood at one point that the http server was talking to the loggerhead one but even that bit may be outdated
[08:34] <MT-> poolie: can you save my sanity?
[08:34] <MT-> I fucked this up and idk how to get it back
[08:35] <MT->  ^ I think that sums it up. I broke it
[08:35] <poolie> you're not giving us much to go on there...
[08:36] <spiv> MT-: can you be more specific?
[08:38] <MT-> I tried following this guide - http://wiki.flexion.org/LoggerheadServer.html - Then tried aptitude install loggerhead over top of it. It kinda worked but it crashed some so I tried to finish the process. That wouldn't work so I went back the the loggerhead package. I realized how screwed up I made it so I tried to purge apache2 and loggerhead. I searched the system for files named loggerhead and removed them. I tried to them reinstall apache
[08:39] <MT-> actually, now I'm getting this error - sh: getcwd() failed: No such file or directory
[08:42] <spiv> Getting that error in what context?
[08:42] <MT-> root@carpo:/etc/apache2# /etc/init.d/loggerhead start
[08:42] <MT-> sh: getcwd() failed: No such file or directory
[08:43] <MT-> start and stop are the exact same message
[08:43] <bialix> have a question about API versioning
[08:44] <bialix> developers/api-versioning.html said: In the plugin foo exporting the API (in __init__.py):
[08:44] <bialix> version_info = (0, 0, 1, 'beta', 1)
[08:44] <bialix> api_version = (0, 0, 1)
[08:44] <bialix> what if my plugin don't have qpi_version declaration?
[08:45] <bialix> does bzr will use just version_info?
[08:45] <MT-> spiv: dpkg-reconfigure loggerhead and dpkg-reconfigure bzr-search show those messages too
[08:45] <MT-> even /etc/init.d/apache2 stop is doing it too....
[08:46] <MT-> I have a knack for destroying a system I guess
[08:47] <spiv> MT-: if /etc/init.d/apache2 is doing that too then it sounds like you've somehow overwritten something pretty crucial in the system.  Hm..
[08:47] <spiv> MT-: or,
[08:48] <spiv> MT-: perhaps the shell you are invoking them from is running from a deleted directory?
[08:48] <spiv> MT-: if you do "cd /" before running those commands, does that help?
[08:48] <MT-> doesn't help
[08:49] <spiv> It's certainly a misfeature of python on debian/ubuntu that "python setup.py install" of random projects tends to clash badly with OS-installed files.
[08:49]  * MT- sucks at computers
[08:49] <spiv> bialix: I don't know, sorry :(
[08:49] <spiv> glyph: hey
[08:49] <poolie> bialix: no,
[08:50] <spiv> glyph: nice to see you in here :)
[08:50] <poolie> i think it should just assume nothing about what api you need
[08:50] <poolie> ie we don't know if you'll work with the current bzrlib or not
[08:50] <bialix> wait
[08:50] <bialix> it's about compatibility between plugins
[08:51] <bialix> e.g. bzr-explorer requires qbzr >= 0.11
[08:51] <poolie> spiv can i ask you about test_unstack_fetches in branch_implementations
[08:51] <poolie> oh right, this is your api, not the required api
[08:51] <bialix> but qbzr has no api_version declaration in old versions
[08:51] <spiv> poolie: you can ask ;)
[08:51] <poolie> spiv, i think it ends up with the stacked branch being a local one
[08:51] <bialix> so now I'm checking qbzr version manually
[08:51] <poolie> even when it's an iteration that's meant to be testing remote objects
[08:52] <spiv> Without looking, that sort of test bug isn't unheard of...
[08:53] <spiv> poolie: because of the sprout('newbranch') ?
[08:53] <spiv> rather than sprout(self.get_url('newbranch')) ?
[08:53] <spiv> That looks likely to me.
[08:53] <poolie> spiv, yeah
[08:54] <poolie> also, i really want to change get_transport and get_url to something like
[08:54] <poolie> get_test_url
[08:54] <spiv> I'm pretty sure I've seen (and corrected) that exact error in other tests.
[08:54] <poolie> to make it more clear it's going to be parameterized depending on the test context
[08:54] <spiv> It's probably not hard to grep for.
[08:54] <spiv> Hmm, I think asking "self.get_url" where self is TestCase is pretty clearly doing that already.
[08:54] <MT-> spiv: can you tell me what shoudl be in /etc/apache2/envvars ?
[08:55] <lifeless> poolie: I don't see it being any more clear, and think that sort of naming is an antismell
[08:55] <poolie> why?
[08:55] <spiv> MT-: mine has http://pastebin.com/mfdeb8df, I haven't edited it since install.
[08:56] <glyph> spiv: I'm in here quite a bit :)
[08:56] <spiv> glyph: and it's nice to see you every time :P
[08:57] <glyph> spiv: Well, then!  You too! :)
[08:57] <poolie> oh, i guess an antismell would be a good thing?
[08:57] <MT-> spiv: what file permissions?
[08:57] <glyph> spiv: sadly I am not here for an awesome reason.
[08:57] <lifeless> poolie: I mean 'foo.get_transport' is clearly parameterised already
[08:57] <lifeless> by foo
[08:57] <lifeless> ditto foo.get_url
[08:57] <MT-> spiv: nvm...
[08:57] <MT-> spiv: how do I get a scratch install of apache?
[08:58] <spiv> MT-: you might want to try apt-get --reinstall
[08:58] <glyph> I still use Hardy on most of my machines.  But, the bzr-gtk packages are broken there.  Are those packages in the PPA supported for Hardy any more, or is it just bzr itself?
[08:59] <MT-> spiv: didn't do it..
[09:03] <poolie> lifeless: well, that's just it, i think it's not clear
[09:03] <poolie> the difference between self.thing and thing is not very large
[09:06] <vila> poolie: I found it unclear for quite some time, but now that I've use get_transport and get_url quite a lot, I can't see how you can change them without massive disruption in the existing tests grep says 726 matches for get_transport and 475 for get_url...
[09:07] <vila> There mat be places where one or the other miss a relpath parameter, but most of the time (at least in the tests *I* encounter) they seem fine
[09:07] <vila> s/mat/may/
[09:08] <poolie> well, i realize most of the tests mostly work
[09:08] <vila> And I fixed a couple of bugs where the test were wrongly calling get_transport() instead of self.get_transport()
[09:08] <spiv> poolie: I think with get_transport vs. self.get_transport it can be unclear, but there's no non-test equivalent of get_url.
[09:08] <poolie> that's true
[09:08] <poolie> and that there are many calls
[09:09] <spiv> Or not so much unclear as easy to forget to use the self. version, and easy to miss when reading/reviewing.
[09:09] <MT-> OK! Apache is back running... now back to figuring out loggerhead
[09:10] <spiv> Actually, when I phrase it like that, that's the same sort of thing as this test bug -- it's easy to call sprout with a string that will implicitly use a local URL, rather than with a URL.
[09:10] <spiv> If you had to give it a URL, that test error would be much less likely.
[09:11] <poolie> that's what reminded me
[09:11] <poolie> "it's possible to use it correctly" is not very convincing
[09:11] <spiv> Right, too far down rusty's list.
[09:12] <vila> well, if we could make get_transport() private, it makes me more happy :)
[09:12] <spiv> It's easier to misuse than use correctly, at least in the context of testing.
[09:12] <spiv> (It's convenient in ad hoc scripts though...)
[09:12] <poolie> vila: which get_transport?
[09:12] <poolie> :)
[09:12] <poolie> presumably you mean the factory function
[09:13] <vila> poolie: yes :D
[09:13] <poolie> actually maybe tests for remote objects should have something to prevent them using the temporary directory unless they really want to
[09:13] <poolie> i bet if we did that it would find some bugs
[09:15] <poolie> spiv, have you thought at all about having a common base class between Repository and RemoteRepository?
[09:15] <poolie> some things might like to live there
[09:15] <spiv> A little.  It would probably be nice.
[09:15] <poolie> like has_same_location etc
[09:15] <poolie> i realize it probably can't share much actual implementation
[09:15] <poolie> or shouldn't
[09:16] <spiv> It could perhaps share some stuff like write group managment.
[09:17] <spiv> glyph: wb
[09:17] <MT-> oh....
[09:17] <glyph> spiv: pro tip: fscking 3 terabytes takes a while, and probably shouldn't be done mid-conversation.
[09:18] <spiv> glyph: I haven't looked at the state of PPA lately, but I see that bzr-gtk finally cut a release today
[09:18] <glyph> ooh.
[09:18] <glyph> spiv: well in that case I'll write a shell script to apt-get update in a tight loop :)
[09:18] <spiv> glyph: I think the PPA package was probably broken due to lack of a release compatible with current bzr, so with that fixed hopefully someone will update the package soon.
[09:19] <glyph> by the way
[09:19] <glyph> I have I mentioned that I love bzr?
[09:19] <vila> glyph: no, do you love it ?
[09:19] <glyph> Because I do.  I love it.  I have a natural tendency to be biased towards it, of course, because all you fine folks work on it and I like you so much
[09:19] <glyph> but every time I have to interact with git, darcs, or even hg (and I've been trying out a lot of software recently, so I've been doing a lot of that) I find myself thinking that it would be a lot nicer if it were bzr.
[09:20] <MT-> spiv: ok... so loggerhead will load once. If I reload the page or click anythin the daemon dies... -_-
[09:20] <spiv> glyph: btw, a test conversion I did of Twisted's trunk into the 2a format is only 20M.
[09:21] <glyph> spiv: !!!!
[09:21] <glyph> oh, just trunk.
[09:22] <glyph> Still, I'm pretty sure that's smaller than the SVN equivalent export.
[09:22] <spiv> Yeah, although I don't imagine a bunch of branches is going to explode it that much, the compression is pretty sexy.
[09:23] <glyph> It took a minute, but 'du' reports the current repository is about half a gig.
[09:23] <glyph> if trunk is only 20M in 2a, I bet that it will be a looot smaller than that.
[09:23] <spiv> I'm sure it will be smaller than that!
[09:23] <awilkins> I've done conversions and just as 1.14-rich-root the whole history of all repositories in the project list comes out smaller than a single export of one of the branches
[09:24] <spiv> ISTR the last time I did a full conversion into an earlier format it was under 80M, and 2a is typically much much better...
[09:24] <awilkins> A working copy would be huuuuge in comparison- 1.7 GB x2 is much bigger than 700MB (the bzr repo packs)
[09:24] <awilkins> I converted it to 2a and only got a 50MB reduction from 700MB though
[09:24] <spiv> It's a bit confusing because Twisted's repo has some 'branches' that aren't actually branches that confuses bzr-svn a little into making some garbage branches.
[09:27] <glyph> spiv: I am 90% sure that the only 'branch' like that is actually 'releases/'
[09:27] <poolie> spiv, lifeless, vila, how do we feel at the moment about having eq methods on things like Repository
[09:27] <glyph> spiv: so if you could special-case that directory via some configuration...
[09:27] <poolie> that check if they have the same format and location etc
[09:27] <poolie> i have mixed feelings
[09:27] <glyph> poolie: better make sure you have __ne__ methods too!  and __gt__ and __lt__ and __ge__ and __le__ and ... ;-)
[09:27] <poolie> but if the checks are cheap and well defined it's probably food
[09:28] <poolie> yeah, well, at least ne
[09:29] <spiv> poolie: probably food indeed ;)
[09:29] <spiv> I'm -0 I think.
[09:30] <vila> poolie: I don't have good feeling about it, there equality concept between repository is not that obvious to me, I can easily imagine people considering repositories with the same *content* to be equal
[09:30] <spiv> I think for something as complicated and general-purpose as a Repository "equality" has several possible meanings.
[09:30] <vila> urgh, forget my typos, what spiv says ;)
[09:30] <spiv> Which tends to mean that blessing just one meaning with __eq__ is asking for bugs.  Hence why we have has_same_location.
[09:31] <poolie> it would have just been nice to compare x.fallback_repositories == y.fallback_repositories
[09:31] <poolie> obviously you can write it out
[09:31] <MT-> This is ALL I can get for error logs http://bzr.pastebin.com/m6d8b2cbb
[09:31] <poolie> it's a bit longwinded in 2.4
[09:31] <MT-> error.log is empty
[09:32] <glyph> IMHO (not that anyone asked me, I just happen to be paying attention) equality checks should only be on objects which are "values", i.e. are trivially possible to serialize and unserialize.  Things like a "Point" with x, y numbers or "EmailAddress" with description/localpart/domain
[09:32] <glyph> I don't even know enough about bzr's internals to know what a "Repository" is but it sounds big and mutable and scary.
[09:32] <vila> and operator overloading is evil :)
[09:32] <glyph> operator overloading is great!  everybody should do it all the time.
[09:33] <MT-> loggerhead is dying after every single page load - AH!
[09:33] <vila> It was evil back in the days where C++ wasn't even standardized, I think it's still evil, far too easy to abuse and leading to some of the most obscure bugs I  ever seen :D
[09:34] <spiv> glyph: yes, a Repository is all of the above :)
[09:37] <MT-> spiv: Does this look decent or very wrong? http://bzr.pastebin.com/ma4b26c3
[09:37] <poolie> yeah, generally i agree with glyph too
[09:37] <poolie> i was just tempted to sin
[09:37] <spiv> MT-: no idea, sorry, I haven't actually set up loggerhead myself
[09:38] <MT-> Can anybody tell me if this file looks right? I'm guessing it's probably why this is breaking? http://bzr.pastebin.com/ma4b26c3
[09:38] <spiv> Ah, you need #confessional, not #bzr :P
[09:42] <MT-> this is about to make me freak out...
[09:42] <MT-> it should be a drop in thing...
[09:44] <poolie> MT-: seriously, you can't just say "it's breaking"
[09:44] <poolie> what's that meant to mean?
[09:44] <poolie> MT- read this sometime -> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
[09:46] <MT-> poolie: I pasted log files and explained what happens.
[09:47] <MT-> I run /etc/init.d/loggerhead, I load ope page, and it stops running.
[09:47] <MT-> no errors
[09:47] <poolie> one page?
[09:47] <poolie> hm, that's not so good
[09:47] <poolie> so the process exited?
[09:48] <MT-> odd... I just tried running it in the foreground and it keeps running fine
[09:49] <MT-> This keeps working perfect -> start-loggerhead -f -c /etc/loggerhead.conf
[09:50] <MT-> Without -f, it dies after the first page load
[09:51] <MT-> poolie: Does that sound odd enough??
[09:54] <poolie> that's a bit strange
[09:55] <poolie> what is -f meant to do?
[09:55] <mwhudson> MT-: serve-branches is easier to use that start-loggerhead
[09:55] <mwhudson> (though not packaged as neatly yet)
[09:55] <MT-> poolie: keeps it int he foreground
[09:56] <MT-> mwhudson: would you please be willing to walk me through setting that up? I think my mind is gone
[09:57] <mwhudson> MT-: well, it's reasonably easy, you run ./serve-branches <where the branches are>
[09:57] <mwhudson> it doesn't daemonize or anything though, so if you want to manage it with initscripts there will be some messing about to do
[09:57] <MT-> I got an error :) _ http://bzr.pastebin.com/me75ca2d
[09:58] <mwhudson> ehh
[09:58] <MT-> wow, it's already 0400
[09:58] <mwhudson> MT-: do you have loggerhead installed system-wide?
[09:58] <mwhudson> MT-: and what version are you running?
[09:58] <mwhudson> (must be fairly new)
[09:58] <MT-> mwhudson: I did aptitude install loggerhead on 9.04
[09:59] <MT-> !info loggerhead
[09:59] <mwhudson> MT-: can you run dpkg -l loggerhead?
[10:00] <MT-> ii  loggerhead                                     1.10-1                                         Web viewer for Bazaar
[10:00] <poolie> try 'debsums loggerhead'?
[10:00] <poolie> you might need 'sudo apt-get install debsums' first
[10:01] <mwhudson> then i'm really confused, because loggerhead 1.10 doesn't have a main module
[10:01] <mwhudson> which is what the error is saying i guess, but also serve-branches from that version shouldn't be trying to import it
[10:01] <MT-> all OK
[10:02] <mwhudson> hang on
[10:02] <mwhudson> /usr/local/bin/serve-branches
[10:02] <poolie> run 'which serve-branches' ?
[10:02] <MT-> http://bzr.pastebin.com/m48a81032
[10:02] <mwhudson> that's not from the package
[10:03] <MT-> /usr/local/bin/serve-branches
[10:03] <MT-> hrm...
[10:03] <mwhudson> MT-: did you or someone else run 'python setup.py install' perhaps?
[10:03] <poolie> 17:38 <MT-> I tried following this guide - http://wiki.flexion.org/LoggerheadServer.html -
[10:03] <MT-> yup...
[10:03] <poolie>             Then tried aptitude install loggerhead over top of it. It kinda worked but it
[10:03] <poolie>             crashed some so I tried to finish the process. That wouldn't work so I went back
[10:03] <poolie>             the the loggerhead package. I realized how screwed up I made it so I tried to
[10:03] <poolie>             purge apache2 and loggerhead. I searched the system for files named loggerhead
[10:04] <poolie>             and removed them. I tried to them reinstall apache
[10:04] <MT-> mwhudson: Does that exist in any package from the repos?
[10:04] <mwhudson> ah
[10:05] <MT-> root@carpo:/bzr# find / -name serve-branches
[10:05] <MT-> /usr/bin/serve-branches
[10:05] <MT-> /usr/local/bin/serve-branches
[10:05] <mwhudson> MT-: i guess you should remove the one in local/bin
[10:06] <MT-> :)
[10:06] <poolie> ok i might call it a night
[10:07] <poolie> spiv, i think the unstacking thing is now all working, except that I'm getting TooManyConcurrentRequests
[10:07] <poolie> for the first time in my experience i think this is actually because there really are too many concurrent requests :)
[10:07] <poolie> not that there's an earlier error and it's failing to unwind
[10:08] <poolie> http://bzr.pastebin.com/m6fe21766  <-- like so
[10:08] <MT-> mwhudson: is there any easy way to run that from a daemon?
[10:08] <poolie> anyhow i'll look tomorrow at how to tastefully make it create a new medium
[10:08] <poolie> if there's no better way
[10:08] <poolie> good night all
[10:08] <spiv> poolie: :)
[10:09] <mwhudson> MT-: nohup serve-branches ?
[10:09] <mwhudson> MT-: basically, no
[10:09] <mwhudson> MT-: we need to fix that
[10:09] <MT-> ok
[10:09] <poolie> mm
[10:10] <poolie> surely there's something in the normal initscripts framework to do this?
[10:11] <MT-> so for now it's just serve-branches /bzr &
[10:11] <MT-> mwhudson: is there any way to make it hide directories?
[10:12] <mwhudson> MT-: not with 1.10
[10:12] <MT-> theres a lost+found showing up..
[10:12] <mwhudson> MT-: with loggerhead trunk you can set http_serve = false in locations.conf
[10:13] <MT-> bzr is still a baby, isn't it?
[10:13] <mwhudson> loggerhead is, at least
[10:13] <MT-> err - that*
[10:14] <MT-> mwhudson: could you help me switch to trunk?
[10:15] <mwhudson> MT-: sure, bzr branch lp:loggerhead loggerhead-trunk
[10:15] <mwhudson> MT-: i wouldn't bother installing it system wide, just run it from the directory you branch into
[10:16] <MT-> ok
[10:18] <MT-> what does serve-branches run as?
[10:18] <MT-> I wanna kill that service first :P
[10:19] <mwhudson> i don't understand
[10:19] <MT-> I started serve-branches /bzr &, now idk how to kill it...
[10:20] <LarstiQ> jml: you mentioned a fixed .gdbinit, but I forgot where it lives
[10:22] <vila> poolie: g'night
[10:25] <MT-> THERE!
[10:25] <MT-> mwhudson: sorry, I had to remember how to use netstat - and the command name
[10:26] <vila> MT-: surely, if you used '&' the pid has been displayed
[10:26] <MT-> vila: it wasn't
[10:26] <vila> or is it just the job number ?
[10:27] <vila> try 'fg'
[10:28] <MT-> heh... I shoulda thought of that too - but anyway, I found it with netstat
[10:28] <MT-> it was running as python
[10:43] <MT-> mwhudson: thanks, :D
[10:43] <MT-> mwhudson: one last question... Is there any easy way to make loggerhead private?
[10:44] <mwhudson> MT-: run it behind apache using proxypass (and a firewall to stop people getting to the port loggerhead is listening on)
[10:44] <MT-> heh... how do I run it behind apache?
[10:45] <mwhudson> i think there is actually some documentation on this in the README file
[10:53] <MT-> !info python-pastedeploy
[11:02] <MT-> mwhudson: I purged the package
[11:03] <MT-> oops
[11:05] <MT-> mwhudson: anyway... I created that in conf.d/loggerhead and it didn't work. I don't have a /branches/ so I just left that part out
[11:05] <MT-> replaced with /bzr/ *
[11:06] <mwhudson> right, it's only meant to be an example
[11:07] <MT-> the branches are located in /bzr
[11:09] <MT-> mwhudson: it the directoy I'm putting the proxy on the loggerhead directory or the branch directory? I assumed branches
[11:10] <mwhudson> branches
[11:19] <mwhudson> heh, trying to browse laconica's source is being very slow
[11:19] <mwhudson> (it's on gitorious)
[11:19] <mwhudson> makes me feel a bit better
[11:20] <fullermd> Well, you'd expect it to be laconic, now wouldn't you   :p
[11:26] <MT-> mwhudson: am I at lesat close here? I'm at least getting 403's now...
[11:26] <mwhudson> that does sound like it might be progress
[11:27] <MT-> it I go to :8080 now it still works fine but I get the hint that I just close off :8080 to the outside world
[11:27] <MT-> http://bzr.pastebin.com/m79213860
[11:28] <MT-> or do I want that as a directory now...
[11:30] <MT-> I was hopeing to have this runnign before nappy time - it's 0530 already :P
[11:30] <MT-> I get up at 1200 at the latest
[11:33] <MT-> I guess it just doesn't like the documentroot
[11:33] <MT-> that's teh reason for the 403's
[11:38] <MT-> Closer!
[11:38] <MT-> Now I log in and get a 500 error
[11:44] <MT-> Ok... so when I try to login I get this error - (13)Permission denied: Could not open password file: /bazaar/lh-users
[11:44] <MT-> I know that file is readable...
[11:45] <MT-> mwhudson: you have any of those really smart ideas?
[11:46] <mwhudson> well it sounds like an apache problem i guess
[11:47] <MT-> it is now, I'm making progress :D
[11:47] <MT-> root@carpo:/var/log/apache2# ls -l /bazaar/lh-users
[11:47] <MT-> -rwxrwxr-- 1 www-data www-data 22 2009-07-09 05:12 /bazaar/lh-users
[11:48]  * MT- wants sleep and broblem solved
[11:48] <michaelforrest> hi - would anybody be able to help me come up with a good repository structure for a project I'm working on..?
[11:49] <michaelforrest> I have already started with a single branch and have the project on Launchpad, but now I want to have lots of different branches with different feature variations
[11:51] <michaelforrest> I've read through http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#advanced-shared-repository-layouts but I'm still not sure how to approach it
[11:54] <fullermd> michaelforrest: Well, for one thing, realize you don't want to approach it as "choosing _A_ repository structure".
[11:55] <fullermd> You want a repository structure for a given place (and time).  Your repository structure in your workspace needn't (and probably doesn't or shouldn't) bear much resemblance to the structure in mine, and neither need be much related to the structure on the central server.
[11:55] <fullermd> (of course, that holds double when the central server is LP, since you don't get to do anything with repo structure there  ;)
[11:55] <michaelforrest> fullermd: ok so.....
[11:56] <michaelforrest> fullermd: say I want to branch locally but keep some of those branches on launchpad
[11:56] <fullermd> Remember, repositories aren't semantic units, they're just storage spaces.  Perhaps you mean more project structure than repo structure...
[11:56] <michaelforrest> fullermd: argh. I like hierarchy in these things, so I'm looking at the --no-trees stuff, but I think I'll want a working tree for each branch on my local filesystem
[11:57] <michaelforrest> fullermd: I want to be able to merge across branches so that .. arg. it seems complicated.
[11:57] <MT-> GAHH!!!! If I remove the proxy lines, it works like it should, if I leave them it, it all of a suddent can't read from the password file
[11:57] <michaelforrest> fullermd: plus I'm used to git, where I'd only see one branch at a time
[11:57] <fullermd> Well, don't mix up problems   :)
[11:57] <michaelforrest> fullermd: yes well - I'm trying to get it straight. hence asking for help.
[11:58] <fullermd> First, forget about repos for the moment.  You'll definitely want to make use of them, but they won't change anything about how you work, so at least for mental modelling purposes forget they exist.
[11:59] <fullermd> (e.g., if you have two branches project/a and project/b, working with them would be _exactly_ the same if they shared a repo at project/, versus each having separate internal repos.  So, what you do with repos doesn't affect how you work with stuff like it does in $OTHER_SYSTEM)
[12:01] <fullermd> There's a large historical bias toward workflows where your branch and working tree are 'together'.  You can still work with a lot of treeless branches and a single checkout you switch among them (or multiple checkouts you switch among them, for that matter).
[12:01] <fullermd> It's just not as polished; requires a bit more manual setup.
[12:01] <MT-> I've had enough - g'night all
[12:02] <MT-> mwhudson: poolie: others: thanks for the help
[12:03] <fullermd> michaelforrest: (does any of that help at all, or am I speaking Greek, or belaboring the painfully obvious?   ;)
[12:03] <michaelforrest> fullermd: if I use --no-trees will it behave the same way as git?
[12:04] <michaelforrest> fullermd: I could live with that and then use export to output different versions
[12:04] <fullermd> Not exactly.  You can setup an analogous workflow, with one WT switch'd among branches.  Various things won't be as polished, though.
[12:04] <michaelforrest> but then I have to synchronise other aspects of the codebase at different points
[12:05] <fullermd> Basically, the difference is that in git, the repository is the addressable unit, and branches are named within that.  In bzr, the branches are themselves the addressable unit, and identified purely by their location (URL/path/etc).
[12:05] <michaelforrest> ok
[12:05] <michaelforrest> that is a useful distinction
[12:05] <fullermd> Some commands (like 'switch', to change the branch your WT is on) do some internal magic so you can ACT like you're addressing sibling branches by name.  But it turns it into paths underneath.
[12:06] <fullermd> Other commands don't.  'branch', for instance, to create a new branch; I don't think it does, so to create a new branch you have to specify something like a path, not just a name.
[12:06] <fullermd> (there are some tools like 'cbranch' in bzrtools that can help automate that too.  I've never used them.  Glancing at the docs, they will take a little config'ing to how your workspace is setup)
[12:07] <michaelforrest> maybe I'd be able to visualise things easier if I installed some of these gui plugins
[12:08] <michaelforrest> I tried to install one the other day but it didn't seem to work
[12:08] <fullermd> I believe abentley works heavily in that fashion (one tree switch'd among branches).  So he might have some better advice on setting up that workflow; he should be around in a couple hours.
[12:08] <michaelforrest> is there a bzr install plugin command?
[12:08] <michaelforrest> or something like that?
[12:08] <LarstiQ> michaelforrest: no. I do: `cd ~/.bazaar/plugins; bzr get lp:bzr-pluginname pluginname` usually
[12:09] <fullermd> No, nothing builtin.  You can just stick plugins in ~/.bazaar/plugins/.  But that doesn't necessarily help with things like plugins' dependancies, like py-gtk or py-qt or the like.
[12:09] <michaelforrest> LarstiQ: that sounds easy enough
[12:10] <michaelforrest> fullermd: I think the key is that I will be doing bzr merges as part of my routine build process
[12:10] <vila> LarstiQ: eerk, better do: cd ~/.bazaar ; bzr branch lp:bzr-pluginname plugins/pluginname
[12:11] <fullermd> Not sure how much structure a GUI will make visible, though.  Like, things like 'branch layout' don't make the same sorta sense in bzr as they do in git.
[12:11] <michaelforrest> so there will be a central branch driving global functionality forward but will occasionally be little 'leaves' with feature variations that need to stay in sync with main app head
[12:12] <LarstiQ> vila: hmm, how much does that differ, and why not go `bzr branch lp:bzr-pluginname ~/.bazaar/plugins/pluginname` in one go?
[12:12] <vila> even better !
[12:13]  * vila searching the bug #
[12:14] <michaelforrest> small step from 'bzr branch lp:bzr-pluginname ~/.bazaar/plugins/pluginname' to a bash command bzr-plugin-install pluginname ;)
[12:15] <vila> well, you're not wrong here :-) While the bzr- prefix is more a social thing than a technical one, I can't think about a case where it will fail...
[12:16] <LarstiQ> there are plugins on BzrPlugins not on launchpad
[12:16] <fullermd> qbzr   :p
[12:16] <vila> lol, yeah, right, I just 'bzr  pull -v' for qbzr for too long :)
[12:16] <fullermd> bzrtools too...
[12:17] <LarstiQ> so yeah, plugin registry and dependency information, then we're good to go
[12:17] <fullermd> Also, a pony.
[12:24] <vila> Ha ! Finally, LarstiQ, I was refering to bug #304891
[12:43] <vila> james_w: ping
[12:47] <james_w> hi vila
[13:23] <LarstiQ> vila: why is that not fixed?
[13:23] <LarstiQ> other than apathy I don't see a reason
[13:23] <vila> :-/
[13:23] <fullermd> Who wants to lose a bug with a nice palindromic number?
[13:23] <vila> lack of time ?
[13:23] <vila> and that too of course :)
[13:24] <vila> even if, really, a small palindrom ...
[14:00] <intellectronica> aloha
[14:01] <intellectronica> bzr dropped to the debugger in the middle of reconciliation of a v2 repo with some old branches
[14:02] <intellectronica> very frustrating, but since i now have a debugger prompt in front of me, is there anything i can do to help figure out what the problem is?
[14:04] <james_w> intellectronica: is it a stray "pdb" in the code
[14:04] <james_w> ?
[14:04] <james_w> or are you running under BZR_PDB?
[14:05] <intellectronica> i don't know what BZR_PDB is (an environment variable?) so i'd say the former
[14:07] <james_w> yeah, environment variable that causes pdb to start if there is an unhandled exception
[14:07] <james_w> if you "list" does it point at pdb.set_trace()
[14:07] <james_w> ?
[14:08] <intellectronica> yeah
[14:08] <intellectronica> http://pastebin.ubuntu.com/213609/
[14:11] <james_w> ah, it's the SIGQUIT handler
[14:12] <james_w> did you try and kill the process?
[14:12] <james_w> the paste suggests you typed ^\ :-)
[14:12] <intellectronica> i didn't, and from the debug listing it looks like bzr sent it, no?
[14:13] <james_w> ^\** SIGQUIT received,
[14:13] <james_w> signal.signal sets signal handlers, not sends signals
[14:14] <james_w> anyway, typing "c" should make it continue
[14:14] <intellectronica> oh well. who knows, maybe i somehow accidentally typed ^\
[14:14] <intellectronica> thanks!
[14:15] <james_w> np
[14:15] <james_w> let us know if it happens again
[15:03] <RainCT> Hey
[15:03] <RainCT> «bzr hooks» crashes here, http://paste.ubuntu.com/213639/plain/
[15:30] <rockstar> jam, you are freakin' awesome!  Thanks for trying Tarmac on Windows.
[15:33] <jam> rockstar: I'm working on making it *work* there
[15:33] <jam> if you give me a few more minutes :)
[15:35] <rockstar> jam, that's awesome!
[15:37] <jam> rockstar: I just got to the point of it popping up a Launchpad window
[15:38] <jam> asking for me to authorize access
[15:38] <jam> what should I do at this point?
[15:38] <jam> For now, I suppose I could set it to read-only
[15:38] <rockstar> So, you could allow it and continue.  It'll save the token it gives you.
[15:38] <rockstar> Readonly is good enough.  There's only one thing that writes now, and that's only if you have a test failure.
[15:39] <jam> well, at this point... it is crashing with:
[15:39] <jam>   File "build\bdist.win32\egg\httplib2\__init__.py", line 972, in request
[15:39] <jam> AttributeError: 'unicode' object has no attribute 'get'
[15:39] <jam> However, it is getting close
[15:39] <jam> And that at least looks like it is failing in launchpadlib
[15:39] <jam> and not tarmac
[15:46] <intellectronica> abentley: is reconcile atomic? what's the risk if i stop in the middle?
[15:46] <abentley> intellectronica: There's no risk, but it won't pick up where it left off.
[15:47] <intellectronica> abentley: cool, thanks. i'm not worried about that
[15:51] <jam> rockstar: I'm pushing up a patch, and submitting a merge request
[15:52] <jam> rockstar: It still doesn't work, but that seems to be a launchpadlib issue
[15:52] <jam> and not a tarmac one (yet)
[15:52] <rockstar> jam, hooray!  Thanks a ton!
[16:25] <jam> rockstar: any idea why launchpadlib seems to be using: build\bdist.win32\egg\httplib2\__init__.py ?
[16:25] <jam> is it using a custom httplib library?
[16:26] <jam> rather that the one in python's stdlib?
[16:26] <rockstar> jam, it might.  I know there was a bug about it recently.
[16:26] <rockstar> jam, it's probably a question better aimed at leonardr
[16:27] <jam> sure, I just don't know any launchpadlib devs, especially ones that are awake right now
[16:27] <jam> I know jml and you :)
[16:27] <rockstar> jam, :)
[16:29] <jam> argh
[16:29] <jam> it seems they are doing:
[16:29] <jam> cache = tempfile.mkdtemp()
[16:29] <jam>             atexit.register(shutil.rmtree, cache)
[16:30] <jam> and then "cache" is the path to a cache directory
[16:30] <jam> which is just a string
[16:30] <jam> oh, I guess they try to do:
[16:30] <jam> cache = MultipleRepresentationCache(cache)
[16:30] <jam> I wonder if "cache" is a Unicode object on Win32
[16:31] <jam> yep
[16:31] <jam> ugh
[16:32] <jam> rockstar: so I got it to stop crashing with an exception
[16:33] <jam> what should I expect its output to be?
[16:33] <jam> ooop, new exception
[16:33] <jam> it seems to assume "/tmp/bzr" is available
[16:33] <jam> bad tarmac
[16:33] <jam> no cookie
[16:33] <rockstar> jam, there's a new patch for /tmp/bzr, but I haven't landed that yet.
[16:34] <jam> rockstar: Shouldn't it just be part of the Config class?
[16:35] <rockstar> jam, it's not right now.
[16:35]  * rockstar looks sheepishly
[16:35] <jam> rockstar: .... *I'm* trying to get things to work on win32, and I'm trying to get info from you as to what I can do to make that happen
[16:35] <jam> If you feel that I'm correct that "$TMP" should be in Config
[16:35] <jam> I'll put it there
[16:35] <rockstar> Ah, okay.  Yea, that makes sense to be in Config.
[16:41] <jam> rockstar: what do you think about making it "tempfile.mkdtemp" ?
[16:41] <jam> Do you prefer not to because it would leave trash around?
[16:41] <jam> (as in, you always want to leave 1 directory around, but not 10?)
[16:41] <rockstar> jam, that's fine with me.  Trash in the temp dir is pretty standard.
[16:41] <jam> or do you even want to leave 1 copy
[16:42] <jam> For example, Launchpadlib does "temp = tempfile.mkdtemp()
[16:42] <jam> atexit.register(shutil.rmtree, temp)
[16:42] <rockstar> jam, I think I'm already doing something similar, so that would be okay.
[16:42] <jam> rockstar: it *is* likely to leave trash in temp, but downloading 100MB projects and leaving them around is a bit ugly
[16:43] <jam> rockstar: you seem to do "shutil.rmtree()" if it exists when you go to create it
[16:43] <jam> but not otherwise
[16:43] <jam> however, I'm still wondering if this is the best solution
[16:43] <jam> considering that we still need to download a lot of data to get "create_checkout" to work
[16:43] <jam> not to mention, you aren't doing "light=True"
[16:43] <jam> so it downloads the whole branch
[16:43] <jam> fresh
[16:43] <jam> every time
[16:43] <rockstar> jam, light=True would be hard on a patch that's about to come in that needs the parent graph.
[16:44] <rockstar> Downloading it every time is actually a feature.  I want it to be fresh.
[16:44] <jam> rockstar: it *doesn't* scale well to projects like MySQL where you have 600MB to download...
[16:44] <jam> (or the old Launchpad which had... 1+GB)
[16:45] <rockstar> jam, yeah, that's a good point.
[16:45] <jam> Heck, bzr in 1.9 format now has >100MB
[16:45] <rockstar> Hm, I'll file a bug on that.  We're Tarmac mini sprinting tomorrow.
[16:46] <jam> rockstar: ok. I'll let you think about that. I'll just try to get something working, and I'll submit it
[16:46] <rockstar> jam, thanks!
[16:47] <jam> rockstar: there seems to be "tempfile.gettempdir()" which should probably give /tmp on Linux and $TEMP on windows
[16:47] <jam> so I'll go ahead and just to the simple change to that
[16:48] <jam> rockstar: how do you run your test suite?
[16:48] <rockstar> jam, yeah, I figured there'd be some weirdness in small things like that.  I tried to use os.path.join where I could, but I'm not surprised that I missed some places.
[16:50] <jam> your .cleanup() is a bit strange, too. Given that it ends up checking out the tree a second time
[16:54] <rockstar> jam, really?  I hadn't noticed that.
[16:54] <rockstar> jam, Could you file a bug with the details?
[16:54]  * rockstar facepalms
[17:04] <lamalex> is there any way to find out why bzr thinks this merge is a criss-cross merge?
[17:04] <lamalex> it shouldn't be afaik
[17:16] <jam> rockstar: so it seems to work, except I believe it is paramiko which is hanging indefinitely when the tarmac script exits
[17:17] <jam> bzr doesn't notice because we explicitly use
[17:18] <jam> os._exit() when we are done
[17:18] <jam> (i think)
[17:18] <rockstar> jam, you don't have a specific config do you?  I noticed it hangs trying to comment with the test failures.
[17:18] <jam> rockstar: So it works to the point of "no candidates to land"
[17:18] <jam> and then that "return" triggers
[17:18] <jam> and it exits the script, and just hangs
[17:18] <rockstar> jam, ah, so it's not the issue I know about.
[17:18] <jam> then again, I just removed the os._exit for bzr, and we still work just fine
[17:18] <jam> so I need to probe deeper
[17:19] <jam> probably an atexit() function is being naughty
[17:19] <rockstar> jam, that's also a possibility.
[17:19] <jam> I swear I've seen in with paramiko, though
[17:20] <jam> because if in the interpreter I run paramiko, I'll get it to hang sometimes
[17:20] <jam> hmm... lets see
[17:22] <jam> rockstar: the crummy thing is that not even ^C works at that point
[17:22] <rockstar> jam, ouch.
[17:22] <rockstar> Why would paramiko even get imported?
[17:23] <jam> rockstar: when you download the development target
[17:23] <jam> see bug #397486
[17:24] <jam> ahh, I have a workaround
[17:24] <jam> it seems that if you call "sys.exitfunc()" before you actually exit your script
[17:24] <jam> things are happy
[17:24] <dash> tarmac? is that an archive tool for OSX
[17:24] <jam> the issue is probably that GC is happening in a weird order
[17:24] <jam> dash: Think airports
[17:24] <jam> it is a tool for "landing" code
[17:24] <jam> (similar to PQM)
[17:25] <jam> but more integrated with Launchpad
[17:25] <rockstar> dash, Tarmac is the new hotness.
[17:25] <rockstar> sabdfl said so.
[17:34] <jam> rockstar: so... a few patches up for your review. And with those *and* the launchpadlib ones, I at least get "No branches for landing"
[17:35] <rockstar> jam, we're doing the launchpadlib ones right now actually.
[18:47] <npoektop> yo! is there a way to ignore executables in my code repository other than marking them with .exe (or smth) extension?
[18:50] <sidnei> jam: thanks for the review! how do i get authorization to submit to bzr's pqm?
[19:47] <garyvdm> Hi all
[20:07] <jam> sidnei: we'll generally ask for a second review, and then the reviewer will submit it
[20:08] <sidnei> jam: cool. i didn't know that. should it be explained in http://bazaar-vcs.org/BzrDevelopment ?
[20:08] <sidnei> oh i guess it's in HACKING
[20:12] <sidnei> uhm, nada. it only says 'someone with PQM access'
[20:42] <malept> vila: ping
[20:42] <vila> malept: pong
[20:43] <malept> vila: I don't think credits.pickle is in bzr-gtk-0.96.1.tar.gz
[20:43] <vila> malept: :-(
[20:45] <vila> malept: you think right :-( The release roadmap is *really* wrong
[20:48] <vila> jelmer: I did my best from your pointer but I'm afraid you'll have to give more precise info... How come credits.pickle is in .bzrignore ? Talk about a trap...
[20:49] <malept> vila: build_credits should be in MANIFEST.in?
[20:49] <malept> er
[20:49] <malept> credits.pickle.
[20:49] <malept> two different thoughts there
[20:52] <vila> http://bazaar-vcs.org/bzr-gtk/releasing says: 'Build tarball (bzr export bzr-gtk-0.XX.Y.tar.gz) ', but since credits.pickle is ignored, of course it's not exported
[20:52] <malept> ah...
[20:52] <vila> build_credits *did* build it
[20:52] <malept> vila: perhaps you should add credits.pickle to MANIFEST.in and then use `python setup.py sdist` to create the tarball?
[20:53] <malept> although I'd do a diff between the 0.96.1 tarball and the sdist tarball to see what got lost, if anything
[20:54] <malept> a filelist diff*
[20:54] <vila> malept: I think deleting credits.pickel from .bzrignore and redoing bzr export is less risky
[20:54] <malept> vila: is that how bzr export works?
[20:55] <malept> vila: doesn't credits.pickle need to be versioned, too?
[20:56] <vila> malept: it exports all versioned files, I don't know the previous tarballs were done, yes of course, I need to bzr add it.
[20:59] <malept> vila: ok, just checking
[20:59] <vila> malept: I'm glad you did :)
[21:00] <vila> malept: this release is long overdue, at least let's make it right, who knows how long it will last :-D
[21:00] <malept> vila: indeed :)
[21:06] <vila> malept: see my pm ?
[21:07] <malept> vila: yes, sorry about that
[21:15] <garyvdm> Hi vila. Can bug you for some help with tests?
[21:16] <vila> garyvdm: sure, I'm trying to release bzr-gtk *properly* so I may suffer some interruptions :)
[21:17] <vila> err, I mean, let's talk about your tests, but I may be lagging a bit at some points
[21:17] <garyvdm> vila: I found a class in the PyQt source that can be used to test a custom qt model.
[21:18] <garyvdm> It attaches it's self to some signals (events), and runs a test when that signal is fired.
[21:19] <vila> nice, and is there some standard way to store the test result ?
[21:19] <garyvdm> If that fails though, it stops all the tests, rather than reporting that the test failed, and continuning.
[21:20] <vila> failing or erroring ?
[21:20] <garyvdm> Whats the differenc?
[21:20] <garyvdm> diference
[21:21] <vila> ERROR or FAIL in selftest -v output
[21:22] <vila> FAIL is when a specific asertXXX fails and throw a specific exception while ERROR is when a different exception is thrown and not caught
[21:23] <vila> So a typo in test for example will error out
[21:24] <garyvdm> Neither (and it should be an error). There is an exception raised in the test that is fired from a signal. The stack of this exception is written to the console by the std python exception handler, and all other tests are not run.
[21:25] <vila> hmm, strange, are there threads involved ?
[21:25] <vila> can you pastebin the traceback ?
[21:25] <garyvdm> No threads - pastebin on the way.
[21:27] <garyvdm> http://paste.ubuntu.com/213912/
[21:27] <garyvdm> vila ^^^
[21:28] <vila> you're not using --parallel ?
[21:28] <garyvdm> No
[21:28] <vila> Try running only the failing test
[21:28] <vila> this traceback is too short, it makes no sense
[21:29] <garyvdm> So maybe I need to overwrite sys.excepthook, capture the exception. And in the test, check if there have been any exception caught by the excepthook, and raise those.
[21:31] <garyvdm> http://paste.ubuntu.com/213917/
[21:31] <garyvdm> vila ^^^^ running only 1 test
[21:31] <garyvdm> bbl
[21:31] <Imperion> does Bazaar have that binary bug search functionality like git bisect?
[21:31] <vila> garyvdm: no idea, but now you can set a breakpoint and do bt
[21:35] <garyvdm> vila: Thanks - I think I need to do what I suggested above. I just wanted to check that there is not a built in way to do that.
[21:35] <vila> Oh, I didn't see that,
[21:36] <vila> try to understand why the exception is not caught by the test framework first, there is something weird here, working around it may not be the best long term solution
[21:43] <garyvdm> vila: Exceptions that are raised by code called from a signal don't get caught by the bzr error handler. So in qbzr, we overwrite sys.excepthook to be able add information to the error report.
[21:44] <garyvdm> I think the same thing happens with gtk.
[21:45] <vila> haa
[21:45] <vila> no matches for grep excepthook in bzr-gtk though...
[21:46] <vila> I remember that in perl-gtk there was various ways to catch the errors though (including ignoring them)...
[21:48] <Imperion> does Bazaar have that binary bug search functionality like git bisect?
[21:48] <LarstiQ> Imperion: yes, bisect plugin
[21:48] <dash> Imperion: there's a bisect plugin
[21:48] <Imperion> thanks
[21:49] <LarstiQ> though likely not as polished
[21:53] <garyvdm> vila: I did a test with gtk, and it behaves the same. If I add "raise Exception("test")" to line 83 of branchview/graphcell.py, The stack of the error it written to the console hundreds of times, but it's not written by the bzr exception handler., e.g.: this is bit of that is written to the console: http://paste.ubuntu.com/213931/
[21:53] <vila> garyvdm: If everything else fails, you can still use a dedicated mainloop
[21:54] <vila> yeah, I'm reading stuff on this subject to refresh my memory,
[21:55] <vila> the idea is that once you called mainloop.run(), all exceptions happening inside that call are caught, displayed and ignored ;0
[21:55] <garyvdm> And if you want to have a global handler for them, you overwrite sys.excepthook
[21:56] <vila> There may be a way to do the same with qt or as I said, for tests, use a specific mainloop that will fire one event at a time, you may get your hands on the exception that way
[21:56] <vila> but adding a global handler will not allow you to re-reraise
[21:58] <garyvdm> But I can get the exc_info (type, value, traceback).
[21:58] <vila> and then ? call quit and re-raise but from where ?
[21:59] <garyvdm> Thats what I'm going to figure out :-)
[22:02] <vila> :)
[23:13] <lifeless> moinmoin