[00:03] <poolie> dhi
[00:56] <schierbeck> jelmer: still awake?
[01:06] <schierbeck> hey guys, is anybody besides me having trouble opening the bzr mainline with the viz in bzr-gtk trunk?
[01:07] <fullermd> It does seem to be working very hard at doing nothing...
[01:07] <fullermd> No CPU, no IO...
[01:08] <fullermd> Oh, wait.
[01:08] <fullermd> That may be that error in bzr with ghosts; not bzr-gtk.
[01:09] <schierbeck> okay
[01:09]  * fullermd doesn't really know; just guessing.
[01:09] <schierbeck> well, i'm hoping :)
[01:09] <schierbeck> i've got enough work already!
[01:10] <fullermd> It works on other trees, and the backtrace looks like a place a ghost could cause cliff-off-falling.
[01:12] <schierbeck> in Repository.sign_revision(), what the heck does gpg_strategy mean?
[01:12] <schierbeck> can i just leave it as None? it's not documented at all...
[01:36] <mw-home> I just install bzr-svn by running bzr branch in my home plugins dir.  Now bzr won't do anything.  Keeps complaining about cannot import CachingParentsProvider.
[01:37] <mw-home> Do I need to run sudo python setup.py install first?
[01:37] <mw-home> cd -
[01:38] <lifeless> mw-home: I think you have a version mismatch
[01:38] <mw-home> lifeless: between the plugin and my base bzr?
[01:39] <lifeless> yes
[01:39] <mw-home> I'm running bzr 1.0 and bzr-svn 0.4.10dev0.
[01:40] <lifeless> mw-home: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show#releases
[01:44] <mw-home> so i clearly need something different than bzr 1.0.  lifeless, thanks for straightening me out.
[01:45] <fullermd> Trunk bzr-svn generally goes with trunk bzr.dev.  It may still work with 1.3 currently, but 1.0 is back far enough now that it's not too surprising.
[01:45] <lifeless> igc: ping
[01:45] <lifeless> mw-home: or an older bzr-svn :)
[01:46] <igc> hi lifeless
[01:46] <lifeless> igc: I really want to nuke that cache
[01:46] <lifeless> igc: our discussion seems to have petered out
[01:46] <igc> the one in fastimport for the inv_vf?
[01:46] <lifeless> yes
[01:46] <igc> no problem
[01:47] <justdave> so maybe I'm just completely blind, but I'm not finding what I'm looking for in the docs...  if I want to update a working directory to a revision that's older than the head of the branch, what do I do? (equiv of cvs/svn up -rREVSPEC)
[01:47] <justdave> bzr up doesn't seem to take a revision as an argument
[01:47] <lifeless> justdave: revert
[01:47] <igc> lifeless: as long as you're aware that it was helping, I'm ok with it going ...
[01:47] <justdave> that works going forward I assume, too?
[01:47] <mw-home> do most people in here use a distribution pkg for bzr, or download some other way?
[01:47] <lifeless> igc: it doesn't seem to help enough to justify its existence to me.
[01:48] <justdave> like if my working directory is on r5179 and I want to update it to r5185, while the repository I'm pulling from is actually on r5190...
[01:48] <fullermd> justdave: bug 45719
[01:48] <fullermd> https://bugs.launchpad.net/bzr/+bug/45719
[01:48] <justdave> yeah, looks like that does work. :)
[01:49] <justdave> the name of the command just makes it confusing :)
[01:49] <igc> lifeless: understood. I think the stuff you're doing is more important than the short term gain I'm getting
[01:50] <fullermd> Name of the command?
[01:51] <fullermd> Oh, you mean using revert?
[01:51] <justdave> so if I'm updating a website based on a tag that gets moved periodically to the revision that we want to be live on the site, my cron job needs to do "bzr revert -rtag:production"
[01:52] <fullermd> Well, not really.  It needs to update -r.  The option just doesn't exist.
[01:52] <fullermd> Of course, if it's a branch by itself, you can use pull -r; that may be the best solution in that case.
[01:53] <justdave> using pull just tells me "No revisions to pull."
[01:53] <justdave> no matter what revision I specify
[01:53] <mw-home> thanks for all the help.
[01:53] <fullermd> Well, if that rev is already the head, that's what you expect.
[01:54] <igc> lifeless: removed and pushed to lp
[01:54] <justdave> doesn't seem to matter.
[01:54] <justdave> I can bzr revert -r(older rev), and then bzr pull -r(current) and it still says that
[01:55] <fullermd> Don't do the revert beforehand.
[01:56]  * fullermd sighs.
[01:56] <fullermd> Pulling 1 rev of bzr.dev:
[01:56] <fullermd> Now on revision 3320.
[01:56] <fullermd> 5.352u 0.434s 1:29.75 6.4%      114+147k 274+19io 7pf+0w
[01:56] <fullermd> Pulling 4 months of mutt changes (hg):
[01:56] <fullermd> added 199 changesets with 417 changes to 121 files
[01:56] <fullermd> 119 files updated, 0 files merged, 10 files removed, 0 files unresolved
[01:56] <fullermd> 5.813u 0.396s 0:12.90 48.0%     124+161k 459+32io 0pf+0w
[01:57] <justdave> # bzr up
[01:57] <justdave> Tree is up to date at revision 5181.
[01:57] <justdave> # bzr pull -r5179
[01:57] <justdave> No revisions to pull.
[01:57] <fullermd> You need --overwrite to step backward.
[01:57] <fullermd> (or sideways)
[01:57] <justdave> bingo
[01:57] <justdave> All changes applied successfully.
[01:57] <justdave> Now on revision 5179.
[01:58] <fullermd> (of course, that pull if you had the files reverted might do some wacky things...)
[01:58] <justdave> ok, so "bzr pull --overwrite -rtag:production" is what I want on my cron job then
[01:58] <sssslang> hi there, could some one give me an advise about which gui to use under windows. i'm a newbee, thanks.
[01:58] <fullermd> Noop pull on bzr.dev takes as long as that whole hg pull.  Sigh.
[01:58]  * fullermd wants smarts.
[01:59] <fullermd> sssslang: I think the main choices are bzr-gtk and qbzr.  bzr-gtk is more complete and seems to be a bit more work to get installed.  qbzr looks more native.
[02:01] <fullermd> (all that AIUI; I don't really use either one)
[02:02] <sssslang> fullermd: thanks. what about TortoiseBzr? i heard of it before when using cvs.
[02:03] <fullermd> I think it's still more "proof of concept" than "use this to get work done".
[02:03] <sssslang> i don't use gui, but i just want to select one for my partner.
[02:04] <sssslang> i see. thank you.
[02:05] <fullermd> (though again, I don't use either the GUI's or Windows, so I may be wrong.  That's just what I've picked up watching IRC/mail)
[02:57] <mwhudson> is there bzrlib for 'delete the branch at this url' ?
[03:00] <mwhudson> i guess i want transport.rmtree, which doesn't seem to exist
[03:08]  * igc lunch
[03:09] <lifeless> mwhudson: there is
[03:09] <lifeless> mwhudson: delete_tree
[03:10] <mwhudson> oh yay
[03:10] <mwhudson> (i was looking in the wrong place)
[03:11] <lifeless> pydoc bzrlib.transport.Transport :>
[03:13] <AfC> lifeless: is that exposed on the command line somehow? ie, is there a way to delete a remote branch which I'm accessing via bzr+ssh://?
[03:14] <AfC> (right now, of course, I'm ssh'ing to the server, cd'ing, and doing rm -r. Hm)
[03:15] <lifeless> AfC: well, 'python -c "import bzrlib.transport; bzrlib.transport.get_transport('url').delete_tree()"' ?
[03:15] <AfC> Let me get right on that
[03:15] <lifeless> AfC: ssh is simpler :)
[03:16] <AfC> The case I am interested in is where you have ssh access to run bzr commands but not an  remote shell.
[03:16] <AfC> (which is what we offer our users)
[03:16] <AfC> (I gather Launchpad is the same? Anyway)
[03:17] <AfC> I have to delete their obsolete branches for them. Kinda ugly. You're saying I should ask them to run that snippet? Very well.
[03:17] <mwhudson> launchpad allows sftp, which somewhat allows the same
[03:18] <spiv> Launchpad offers no shell, although it does offer a web UI that can delete branches.
[03:18] <Peng> There's no need to delete obsolete branches..
[03:20] <spiv> Peng: it is useful if you like to browse branches to get a sense of what's being worked on.
[03:21] <Peng> Yeah.
[03:21] <spiv> (presupposing a mechanism to browse collections of branches, of course)
[03:21] <Peng> I leave my branches around forever, using Launchpad to mark them as merged or abandoned or whatever.
[03:25] <lifeless> AfC: no really saying that that snippet is a good answer; just thats the only answer in bzrlib today
[03:31] <lifeless> I hate test_35_wait_lock_changing
[03:48] <Peng> Yay, I had a weird problem with bzr-svn (traceback trying to branch something, then "not a branch"), but I upgraded, and now it's ok. :)
[04:57] <Peng> So what's the status of bzr.dev and http://bazaar.launchpad.net/, what with bug 207558?
[04:59] <lifeless> bug 207558?
[05:01] <jdong> lol
[05:01] <jdong> seveas upgraded to hardy.
[05:01] <jdong> hilarity ensues.
[05:03] <spiv> Peng: I'm working on it atm
[05:07] <fullermd> spiv: Hey, I had a Q about that root_client_path thing you merged in today...
[05:08] <fullermd> spiv: I'm not sure I understand its implications.  Could that be useful in the case where the request paths aren't directly under a common root?
[05:08] <Peng> spiv: Ok.
[05:09] <Peng> Oh, ubotu isn't here?
[05:11] <spiv> fullermd: hmm, I'm not sure.  It's just designed so that you can publish e.g. /home/code/project-x at bzr+http://host/bzr/repos/x-project
[05:12] <fullermd> spiv: I have the [recreational] desire to get the smart server in bed with UserDir's...
[05:13] <spiv> So you can effectively designate some path in your public URL space as the root of the bzr-served area, and then have that consistently translated to an underlying transport.
[05:13] <fullermd> Hm.  So that wouldn't really apply...
[05:13] <lifeless> fullermd: ~ translation just needs a transport adapter I think
[05:14] <spiv> fullermd: what lifeless said :)
[05:14]  * fullermd gets his Greek-to-English dictionary out...
[05:15] <spiv> fullermd: e.g. write a plugin that registers a transport for the "userdir:" URL scheme, and use that as the backing transport for your bzr+http server
[05:17] <spiv> So instead of having a SmartWSGIApp that publishes '/home/code/project-x', it could publish "userdir:///".
[05:17] <lifeless> spiv: well, I was thinking something that looks for ~ and does userdir expansion
[05:17] <lifeless> spiv: but yeah
[05:18] <fullermd> Either way, it sounds like it classifies solidly as "bzr hackers might be able to get this working".  So, I guess I'll leave that laying for a while yet.
[05:19] <lifeless> always need more help fullermd
[05:19] <fullermd> Well, my port of bzrlib to perl is a little stalled...
[05:20] <lifeless> I said help :)
[05:20] <fullermd> I am helping; it's stalled   ;)
[08:19] <mdke> lifeless: thanks very much for your email
[09:13] <fullermd> It's kinda odd that 'missing' doesn't have --remember, and doesn't remember by default either.  And doesn't use the submit branch...
[09:14] <james_w> sounds like the start of a soppy song... "oh, if only I could remember all those missing revisions..."
[09:16] <fullermd> Hm.  Yeah.  Simon and Garfunkel.
[09:32] <igc> night all
[09:34] <james_w> night igc
[09:42] <james_w> igc: thanks for the proposed new hook, it could well make bzr great for use with ikiwiki
[09:48] <james_w> does anyone understand this?
[09:48] <james_w> http://release.debian.org/migration/testing.pl?package=bzr-builddeb
[09:48] <james_w> it seems to be a bit of a circular argument.
[09:49] <james_w> it might be http://release.debian.org/migration/testing.pl?package=bzr-svn that is the root of it then
[09:50] <siretart> james_w: we need to ask the release team to add a hint that the bzr related package need to go in together
[09:51] <siretart> james_w: or we could just prod dato, since he is a member of the debian release team ;)
[09:54] <james_w> ah, I see, thanks siretart
[10:15] <dato> siretart, james_w: I added a hint, should be done in a couple days, when bzr-svn is ready to migrate
[10:16] <james_w> dato: thanks
[10:38] <schierbeck> jelmer: hi
[10:43] <jelmer> schierbeck: hey
[10:44] <schierbeck> have a look at lp:~bzr-gtk/bzr-gtk/seahorse-integration
[10:44] <schierbeck> it's rocking.
[10:44] <schierbeck> i've got key fingerprints and trust down nown
[10:44] <schierbeck> *now
[10:44] <schierbeck> though i still need to fix some bugs
[10:52] <jelmer> cool
[10:52] <jelmer> schierbeck: any chance you can review my other two patches I sent to the list?
[10:53] <jelmer> ([MERGE] Signatures tab and [MERGE] Split identity settings out of main preferences window.)
[10:55] <jamesh> jelmer: thanks for looking at my commit-notify patch
[10:55] <schierbeck> jelmer: sure
[10:59] <jamesh> now I just need to get lifeless to review the bzr-dbus bits
[10:59] <jamesh> :)
[11:01] <jelmer> schierbeck: thanks
[11:02] <schierbeck> okay
[11:02] <schierbeck> looked over the settings branch, looks good!
[11:02] <schierbeck> jelmer: btw, do you think we should rename the "signature" tab label to "trust"?
[11:03] <schierbeck> i think it makes more sense
[11:03] <schierbeck> since a signature doesn't really mean anything if you don't trust it.
[11:04] <jelmer> schierbeck: I'd rather call it signature for now
[11:04] <jelmer> Since trust can mean different things here
[11:05] <jelmer> Does it mean you trust the person who made the signature to have made the commit, or does it mean you trust them to write good code without security bugs?
[11:05] <schierbeck> that could be differentiated in the tab ui
[11:06] <schierbeck> i.e. [x] Trust that this revision was committed by 'John Doe'
[11:06] <schierbeck> and [x] Trust the validness of this revision
[11:07] <schierbeck> where validness would be replaced with a proper word...
[11:07] <jamesh> jelmer/schierbeck: if you want to do signature verification, maybe try pygpgme
[11:07] <jamesh> I haven't done much work on it recently, but it works pretty well
[11:07] <schierbeck> jamesh: we're looking at using the seahorse dbus service right now, but i'll take a look
[11:08] <james_w> I don't know if you guys know, but we had a discussion on signatures at the sprint
[11:08] <jelmer> schierbeck: The problem is that bzr can only store signatures at the moment and afaik it's not really clear what they mean
[11:08] <schierbeck> jup, that's been an issue for a while
[11:09] <james_w> it's not clear that what we have now is the best approach, so it may be re-evaluated.
[11:09] <schierbeck> remember discussing it a few months ago
[11:09] <jamesh> schierbeck: okay.  From memory, seahorse is built on top of gpgme, so they should be mostly equivalent
[11:09] <jamesh> it just changes who forks and exec's gpg
[11:09] <schierbeck> jamesh: i think a review system integrated into bzr would be nice
[11:09] <james_w> I've been tasked with writing a spec about it
[11:09] <jelmer> schierbeck: that's why I'd rather stay away from assigning trust, etc for now
[11:09] <schierbeck> jelmer: i see your point
[11:10] <jamesh> bzr has enough hooks now that the jam's old signing plugin could be extended to do useful things now
[11:10] <james_w> or at least a document about the issues, and the fact that the point of a signature is not currently clear is the biggest problem with the current state for me
[11:10] <jamesh> like refuse merges that aren't signed by a trusted key
[11:10] <schierbeck> what about having review keywords, like "approve", and then just sign the keyword and sha1-sum?
[11:11] <schierbeck> bzr review <approve|reject|...> -r <revision>
[11:13] <schierbeck> the idea would be that all history up to that revision would then be "approved"
[11:13] <schierbeck> just an idea, though
[11:20] <schierbeck> jelmer: okay, i've pushed some further changes to lp
[11:20] <schierbeck> the new implementation now exceeds the old in functionality
[11:21] <schierbeck> jamesh: does pugpgme have any documentation?
[11:21] <schierbeck> *py*
[11:22] <jamesh> schierbeck: not really.  The API is mostly the same as the C one though.
[11:22] <jamesh> and the tests cover pretty much all the entry points
[11:22] <schierbeck> jamesh: okay
[11:23] <schierbeck> perhaps i'll switch to it later on
[11:23] <schierbeck> also depends on distribution stuff
[11:25] <jelmer> schierbeck: I'd rather use seahorse than pygpgme since seahorses password prompting will always be gtk based
[11:25] <jamesh> schierbeck: whatever you do, don't use pyme
[11:26] <jamesh> it is one of the worst kinds of swig generated Python extension
[11:26] <ubotu> New bug: #210053 in bzr "no way to edit subject when using bzr send builtin editor" [Medium,Confirmed] https://launchpad.net/bugs/210053
[11:26] <ubotu> New bug: #210092 in bzr "Bazaar raises AssertionError in TreeTransformBase.version_file: 'file_id is not None'" [High,Confirmed] https://launchpad.net/bugs/210092
[11:27] <jelmer> schierbeck: the seahorse-integration branch gives me list out of range exceptions
[11:28] <ubotu> New bug: #209849 in bzr "Bazaar chokes when running commands over SFTP" [Undecided,New] https://launchpad.net/bugs/209849
[11:28] <ubotu> New bug: #209948 in bzr "bzr log failure (possible regression)" [High,Confirmed] https://launchpad.net/bugs/209948
[11:28] <ubotu> New bug: #209998 in bzr-gtk "Should integrate with Seahorse" [Medium,In progress] https://launchpad.net/bugs/209998
[11:30] <ubotu> New bug: #209912 in bzr "--hardlink option produce traceback on Windows" [Undecided,New] https://launchpad.net/bugs/209912
[11:36] <g0nzal0> hello there, I'm trying use bazaar to do personal version control of a little django project
[11:36] <g0nzal0> using Ubuntu 7.10
[11:36] <g0nzal0> I get this: http://dpaste.com/42536/ :(
[11:36] <g0nzal0> when doing commit
[11:36] <g0nzal0> for the first time
[11:37] <AfC> g0nzal0: you really want to be using a version of Bazaar that is not 6 versions old.
[11:37] <AfC> g0nzal0: upgrade to bzr >= 1.3
[11:37] <g0nzal0> AfC: OK!
[11:37] <bob2> g0nzal0: 'bzr commit -q' might succeed
[11:37] <james_w> g0nzal0: what's your locale?
[11:37] <bob2> if that error is from trying to print the filename
[11:37] <AfC> g0nzal0: 0.90 is ancient
[11:38] <g0nzal0> AfC: I thougth so.., thanks
[11:38] <g0nzal0> james_w: es_AR.UTF-8
[11:38] <schierbeck> jelmer: yeah, i noticed
[11:38] <james_w> g0nzal0: there is a PPA you can use to get the latest version
[11:39] <schierbeck> jelmer: it's if you don't have the key
[11:39] <g0nzal0> AfC: I thougth apt-get install bzr would get it
[11:39] <james_w> https://launchpad.net/~bzr/+archive
[11:39] <g0nzal0> james_w: thanks
[11:46]  * AfC is a bit shocked that Ubuntu doesn't publish updates of things, but that's ever been the Debian way.
[11:48] <siretart> AfC: ubuntu does update software, even in released version. the updating policy is documented on wiki.ubuntu.com
[11:48] <AfC> Uh huh
[11:55] <schierbeck> jelmer: is it still giving off noise?
[12:04] <jelmer> schierbeck: let me try
[12:04] <jelmer> dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id:
[12:06] <schierbeck> jelmer: you're at revision 427?
[12:07] <jelmer> schierbeck: yes
[12:07] <schierbeck> hmm
[12:07] <schierbeck> i'll see if i'm running an old version of seahorse
[12:08] <schierbeck> i'm running 2.20.1
[12:08] <jelmer> GNOME seahorse 2.22.0
[12:10] <schierbeck> you're running hardy, right?
[12:10] <jelmer> no, Sid
[12:11] <schierbeck> okay
[12:11] <schierbeck> i'm not sure what's changed in the api
[12:12] <schierbeck> can you try using self.get_id() instead of self.key in GetKeyField() et al?
[12:14] <jelmer> dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.UnmappedError.Seahorse.Code1: Invalid key id:
[12:16] <schierbeck> what method is throwing it?
[12:17] <schierbeck> is it discover() or one of the getters?
[12:18] <jelmer> not sure, the machine I was runnig it on just crashed :-(
[12:32] <sabdfl> is bzr.dev having a crisis of identity?
[12:32] <sabdfl> peregrine% ./bzr pull                                        ~/software/bzr.dev
[12:32] <sabdfl> Using saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/
[12:32] <sabdfl> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/".
[12:33] <Peng> sabdfl: >= r3309?
[12:33] <Peng> sabdfl: https://bugs.edge.launchpad.net/bzr/+bug/207558
[12:34] <ubotu> Launchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress]
[12:34] <sabdfl> 3323
[12:34] <Peng> ubotu: When did you get back?
[12:34] <Peng> Fuck! X-Chat's dying again.
[12:34] <Peng> Or, some less-obscene variant of that sentence.
[12:43] <schierbeck> jelmer: still no luck?
[12:48] <ubotu> New bug: #210142 in bzr "Log comments cannot be changed/edited/annotated" [Undecided,New] https://launchpad.net/bugs/210142
[12:50] <mtaylor> is there a way to change a repository from --with-trees to --without-trees without recreating it?
[12:50] <dato> mtaylor: there is `touch .bzr/repository/no-working-trees`
[12:51] <mtaylor> dato: nice :)
[12:54] <schierbeck> hmm, perhaps i should work on my exam assignment today...
[12:54] <schierbeck> i always get so god damned productive when i have exams!
[12:55] <schierbeck> just in the wrong areas...
[13:12] <jelmer> schierbeck: one sec
[13:13] <jelmer> schierbeck: http://pastebin.org/26636
[13:14] <jelmer> schierbeck: yeah, I always get that as well.. the more you have to do, the more interesting other things become :(
[13:46] <ubotu> New bug: #210218 in bzr ""bzr send" fails if branch nick contains a slash" [Undecided,New] https://launchpad.net/bugs/210218
[14:51] <aantn> hello
[14:51] <aantn> can I get bzr merge to ignore two revisions from the merge source?
[14:51] <aantn> I'd like it to merge all revisions after revision number x
[14:52] <aantn> and permanently ignore the revisions before that
[14:54] <aantn> The man page explains that "If you specify two revisions, the first will be used as a BASE,
[14:54] <aantn>   and the second one as OTHER."
[14:54] <aantn> I'm not sure what the 'other' means
[14:55] <luks> you would need to cherry-pick those revisions
[14:55] <luks> which has it's disadvantages
[14:55] <luks> regular merge will only merge the whole branch
[14:56] <luks> no easy way to workaround it, because it would mean that the newer revisions in the new branch have different parents than the same revisions in the old branch
[14:57] <luks> what you can do is a full merge, and then revert those X revisions with a reversed merge
[14:58] <aantn> I'm not sure I follow...
[14:58] <luks> which part?
[14:58] <luks> or the whole monologue? :)
[14:58] <aantn> luks: why a regular merge beginning from a specific number wont work
[14:59] <luks> because revisions in bzr have some identifiers and have defined their parent revisions
[14:59] <luks> if you merge from some specific revisions, you would break the original revision parent<->children chain
[14:59] <luks> bzr allows you to do that, but it will look differently from a regular merge
[15:00] <luks> (it's called cherry-picking)
[15:03] <luks> what is your use case for this?
[15:03] <aantn> hmm...
[15:03] <aantn> I run my own branch that really is probably going to split from the trunk
[15:04] <aantn> I've already added the feature that those revisions add to the trunk
[15:04] <aantn> And I like the way I implemented it more than the way it was done in trunk
[15:04] <aantn> I think I'll just merge it in and then restore it to what it was before
[15:04] <luks> yes, that's the best solution I think
[15:04] <luks> do a full merge, and revert those specific changes
[15:05] <aantn> luks: is there a command to do that, or should I just do it by hand?
[15:05] <luks> well, if they are touching the same code, you will have conflicts on the merge
[15:07] <luks> so you will probably have to do manually anyway
[15:07] <aantn> luks: probably
[15:07] <aantn> thanks
[15:07] <luks> `bzr shelve` could help probably
[15:07] <luks> that is, in case you don't have textual conflicts, but want to revert specific changes
[15:07] <luks> if those changes affect whole files, you can simply use `bzr revert path/to/file`
[15:09] <aantn> luks: that should work
[15:12] <Peng> What's that simple POST to see if an HTTP smart server is alive, that just returns "ok2"?
[15:21] <james_w> Peng: there's a hello plugin
[15:22] <james_w> so I think you can do bzr hello bzr+http://wherever
[15:51] <ubotu> New bug: #210280 in bzr "unable to obtain lock after push failure" [Undecided,New] https://launchpad.net/bugs/210280
[15:53] <Peng> james_w: That's true. I've even downloaded it, but never installed it.
[15:53] <Peng> I've got it.
[15:54] <Peng> $ echo hello | POST http://.../.bzr/smart
[16:06] <Peng> bzr-hello is neat too.
[17:09] <cody-somerville> What is the command to build a debian package from a repository?
[17:10] <LeoNerd> apt-get source foo;  debuild ?
[17:10] <Peng> There's bzr-builddeb.
[17:10] <cody-somerville> Thanks Peng
[17:10] <LeoNerd> Oh.. that :)
[17:10] <cody-somerville> Are you sure thats the command?
[17:11] <cody-somerville> oh, I guess I don't have it installed
[17:11]  * cody-somerville thought he did.
[17:13] <Peng> Yeah, it's a package. I don't know what the command is.
[17:14] <cody-somerville> fun
[17:24] <james_w> cody-somerville: try without the -
[17:24] <james_w> bzr builddeb
[17:47] <beuno> poolie, lifeless, did you manage to send in the paper for debconf?
[17:51] <james_w> hi besonen_mobile2
[17:51] <james_w> and beuno, hi to you too
[17:51] <beuno> hey james_w!  how are you?
[17:52] <james_w> good, how are you?
[17:52] <beuno> pretty good, finally caught up with most of the stuff I had left fall behind  :)
[17:52] <beuno> how's your new work?
[17:53] <james_w> it's going great thanks.
[17:54] <beuno> I'm glad :)
[18:06] <jelmer> hi james_w
[18:06] <jelmer> james_w: Did you see the bug report I filed on bzr-builddeb's timestamps?
[18:06] <jelmer> james_w: Took me a while to figure out what was causing those differing checksums...
[18:06] <james_w> jelmer: yeah I did
[18:07] <james_w> I haven't had time to look at though I'm afraid
[18:07] <dato> is it going to work by just using the same timestamps?
[18:07] <james_w> I don't know
[18:07] <jelmer> dato: yep, a diff on the tarfile showed that was the only thing that differed
[18:07] <dato> fwiw joeyh wrote pristine-tar for stuff like this
[18:07] <dato> jelmer: aha
[18:07] <jelmer> dato: that's the other way around though
[18:08] <james_w> dato: i'd like to integrate it, but there's no easy place to stash the diff in bzr
[18:08] <dato> james_w: true...
[18:19] <jelmer> james_w: Hmm, looks like that's actually a bug deep inside the bzr export code...
[18:21] <james_w> jelmer: that it doesn't set the timestamps, or something else?
[18:22] <jelmer> james_w: it explicitly sets the timestamp to time()
[18:23] <jelmer> the exporting happens from a revision tree, when there is no revision object around anymore
[18:24] <jelmer> bzrlib/export/tar_exporter.py:33
[18:24] <james_w> I can get the revision object in builddeb and set the timestamp then
[18:25] <jelmer> you mean avoid the standard bzr export code?
[18:26] <james_w> no, just set the timestamp after
[18:27] <james_w> if I could do it with the bzr export code that would be better obviously
[18:27] <james_w> a timestamp= parameter or something
[18:29] <jelmer> james_w: there is no generic timestamp argument passed to the argument code at the moment
[18:29] <jelmer> though one could be added, I guess
[18:30] <james_w> yeah, I don't know if it could be done without breaking other exporters, I'm not looking at the code at the moment.
[18:31] <james_w> that would probably be the cleanest way though.
[18:36] <jdong> james_w: any hints on http://launchpadlibrarian.net/13012802/buildlog_ubuntu-hardy-i386.bzr-builddeb_0.93_FAILEDTOBUILD.txt.gz?
[18:37] <james_w> Unable to load plugin 'builddeb' from '/build/buildd/bzr-builddeb-0.93/build/lib/bzrlib/plugins'
[18:37] <james_w> that's annoying
[18:37] <james_w> we need a -Dplugin_loading or something
[18:38] <james_w> it means that I want the ~/.bzr.log to debug it
[18:38] <james_w> jdong: there's no easy way to run the testsuite from debian/rules, I thought this way would be it, but it only seems to have built in mine and my sponsor's chroots
[18:39] <james_w> so I don't know what the fix is exactly.
[18:39] <james_w> perhaps just to disable the testsuite during the build.
[18:39] <james_w> though I don't like doing that
[18:40] <jdong> james_w: odd enough it worked in my pbuilder too....
[18:40] <jdong> james_w: hmm I'll disable the test suite for now so we don't lose the bzr-builddeb binary entirely while we investigate a better fix
[18:40] <james_w> thanks
[18:41] <james_w> the other alternative is to cat ~/.bzr.log if that command fails, just so we can debug it properly
[19:02] <schierbec1> jelmer: ping
[19:06] <jelmer> schierbec1: pong
[19:08] <schierbec1> jelmer: i'm tweaking the sig tab labels
[19:08] <schierbec1> i'm thinking: a bold headline and a longer description
[19:09] <schierbec1> such as:
[19:09] <schierbec1> *Authenticity unknown*
[19:09] <schierbec1> This revision has not been signed; it may be forged.
[19:09] <schierbec1> etc.
[19:09] <schierbec1> what do yuo think?
[19:09] <schierbec1> *you
[19:10] <jelmer> schierbec1: The fact there is a signature doesn't say the revision is or isn't forged
[19:10] <jelmer> schierbec1: I can forge one of your revisions and sign it.
[19:11] <schierbec1> jelmer: yeah, but signed + trusted key => not forged, right?
[19:11] <jelmer> schierbec1: no, that implies you trust all people whose keys you've signed to not forge revisions
[19:11] <schierbec1> well, okay then
[19:12] <schierbec1> but then the whole idea of signatures kind of goes away
[19:12] <schierbec1> if you can't even trust your trusted friend to f00k you over
[19:12] <jelmer> schierbec1: right, but that's what the whole discussion about signatures in bzrlib was about
[19:13] <schierbec1> jelmer: what if we match the signature name + email with the committer's?
[19:14] <jelmer> schierbec1: yeah, that would make some sense
[19:14] <schierbec1> so a revision signed by its author is authentic if the key is trusted?
[19:14] <jelmer> schierbec1: yeah
[19:14] <mdke> quick question. When I upgrade a branch from dirstate-with-subtree to rich-root-pack (on Launchpad), what will the other users of the branch need to do to get the changes? upgrade their branches too or get them again?
[19:15] <jelmer> mdke: afaik they should be able to continue pulling if they have bzr >= 1.0
[19:15] <mdke> jelmer: and pushing?
[19:15] <jelmer> mdke: pushing will still be possible too
[19:16] <mdke> cool, thanks. but to get the benefits they need to upgrade right?
[19:16] <jelmer> mdke: it'll be slower than it can be though, so I would highly encourage them to also upgrade to --rich-root-pack
[19:16] <mdke> fine, thanks a lot
[19:16] <jelmer> schierbec1: so I think we have 4 situations then:
[19:16] <jelmer> or rather 5
[19:16] <schierbec1> jelmer: so we have four cases: (unsigned), (signed - trusted), (signed + trusted - committer), and (signed + trusted + committer) ?
[19:17] <schierbec1> oh
[19:17] <schierbec1> what's the fifth?
[19:17] <schierbec1> well, (signed + committer - trusted)
[19:17] <jelmer> yeah, 4
[19:17] <jelmer> schierbec1: no signature, signed by trusted author, signed by untrusted party, signed by trusted person (not author)
[19:18] <mw-home> does bzr have keywords like $Id: $ ?
[19:18] <jelmer> okay, that matches what you said
[19:18] <jelmer> mw-home: nope, not yet
[19:18] <schierbec1> i think we should only handle unsigned, signed+trusted+committer and signed-trusted+committer
[19:18] <jelmer> mw-home: there is an open specification about it but nobody working on it yet afaik
[19:18] <schierbec1> that's all related to authenticity
[19:18] <jelmer> schierbec1: I think we should show if somebody who's trusted but not the author has signed
[19:19] <schierbec1> jelmer: yeah, but perhaps delay that a bit
[19:19] <jelmer> schierbec1: We should clearly state that that person is not the author
[19:19] <jelmer> schierbec1: ok
[19:19] <jelmer> schierbec1: We should be checking against committer email btw, not author email
[19:19] <schierbec1> jelmer: i think we should have an 'Authenticity' section
[19:19] <schierbec1> okay
[19:20] <jelmer> schierbec1: also, if the revision is signed by somebody untrusted it's not relevant if that key's email matches the committer email
[19:21] <jelmer> since we can't trust the email on the key to be valid
[19:21] <schierbec1> exactly
[19:22] <schierbec1> jelmer: but we may like to provide the user with the option of trusting the key
[19:22] <jelmer> schierbec1: we should leave that to specific apps such as seahorse imo
[19:22] <schierbec1> if he's spoken with the committer and knows the revision is authentic, we can then trust it (marginally)
[19:23] <schierbec1> jelmer: seahorse is meant to be integrated like that -- no ordinary user will open up a key manager
[19:23] <jelmer> schierbec1: I think we should allow launching a key details dialog or something from seahorse
[19:24] <mw-home> jelmer: thanks for the information.
[19:24] <jelmer> but we shouldn't have a "trust this person" key, that's really outside of the scope of bzr-gtk
[19:25] <schierbec1> jelmer: i'm not sure -- if that's the way the user extends his trust network?
[19:26] <jelmer> schierbec1: signing keys should involve identity verification and the like
[19:27] <jelmer> schierbec1: also, seahorse already deals with this task, let's not reimplement that bit
[19:27] <jelmer> afaik the key information diaog from seahorse has buttons for trusting the key
[19:27] <schierbec1> jelmer: allright, but perhaps we can have a look at it in the future
[19:29] <schierbec1> jelmer: does it still throw exceptions at you?
[19:29] <schierbec1> i talked with a seahorse dev, he said the api didn't change
[19:29] <schierbec1> jelmer: btw, i've pushed to lp, you can check out the new headings
[19:30] <jelmer> schierbec1: yep, still errors
[19:30] <jelmer> Invalid key id:
[19:30] <schierbec1> can you print out the key?
[19:30] <jelmer> this is on your signed revisions
[19:31] <schierbec1> it should be of the format "openpgp:<key>"
[19:31] <jelmer> it works fine for my own signed revisions
[19:31] <jelmer> such as 14.1.1 (in bzr-gtk)
[19:33] <jelmer> schierbec1: The "Authenticity confirmed" bit is incorrect until we're checking the author email == key email
[19:33] <schierbec1> jelmer: yeah, this is just the ui bits, i'll add the comparison asap
[19:34] <schierbec1> jelmer: can you add a print in crypt.py so i can see what the key looks like?
[19:34] <jelmer> sure
[19:34] <jelmer> what/where?
[19:34] <schierbec1> just in Key.__init__()
[19:34] <schierbec1> print key
[19:35] <schierbec1> jelmer: it may also be that my key is not fetched from the server
[19:37] <jelmer> schierbec1: We should not rely on seahorse being able to fetch a key
[19:37] <jelmer> schierbec1: since you may be offline, for example
[19:37] <jelmer> schierbec1: I think I also have automatic key fetching turned off in gpg since it is slow
[19:38] <schierbec1> jelmer: i'm not completely sure what the protocol is, but the docs mention that a key may be "missing" at first
[19:38] <schierbec1> jelmer: but that may very well be the problem
[19:39] <schierbec1> jelmer: i'd like to try something: in __init__(), replace "discover(key)" with "discover(self.get_id())"
[19:39] <schierbec1> that's just to see if the api's changed
[19:42] <jelmer> schierbec1: that changes the error back to the list index out of range exception
[19:43] <jelmer> schierbec1: what does DiscoverKeys() do exactly?
[19:43] <jelmer> does that try to fetch the key from the web?
[19:45] <schierbec1> yup, or the local network
[19:45] <schierbec1> i'd like to see the value of "key" -- can you print it out?
[19:45] <jelmer> schierbec1: key is an empty string
[19:45] <schierbec1> it sounds like VerifyText returns something stupid
[19:45] <schierbec1> hmm
[19:46] <jelmer> schierbec1: seahorse also has an option to automatically discover keys as they are requested
[19:46] <schierbec1> what about cleartext in crypt.verify() ?
[19:46] <jelmer> schierbec1: I'd rather rely on that
[19:47] <jelmer> schierbec1: cleartext does indeed contain the testament
[19:48] <schierbec1> that's funny -- the "key" return value is just empty?!
[19:48] <jelmer> schierbec1: dbus.String(u'')
[19:50] <schierbec1> ?
[19:50] <jelmer> schierbec1: "print repr(key)" prints dbus.String(u'')
[19:51] <schierbec1> 3 seconds, on the phone
[19:56] <schierbec1> jelmer: sorry, my mom called
[19:56] <schierbec1> hehe, a bit hard to just hang up...
[19:57] <schierbec1> jelmer: but yeah, it's returning an empty string -- i'll just make a test for that and mark the key as invalid then
[19:58] <jelmer> schierbec1: s/invalid/unknown?
[19:58] <jelmer> since it could be trusted
[19:58] <jelmer> schierbec1: it's a bit odd though that it doesn't return anything at all, it should known the key id even if it doesn't have the key
[20:00] <schierbec1> jelmer: exactly, but i guess we'll just mark it as unsigned or what?
[20:00] <jelmer> schierbec1: unknown should be a separate thing imho
[20:02] <schierbec1> jelmer: okay, like "error verifying key"?
[20:02] <schierbec1> oh, the seahorse guy is responsive now, i'll ask him
[20:03] <jelmer> schierbec1: ah, cool
[20:03] <jelmer> schierbec1: it would be nice if seahorse could actually return the key id there
[20:04] <jelmer> schierbec1: and it would be nice if a command could be added to the DBus API to display the key information dialog for a particular key
[20:04] <schierbec1> yup
[20:09] <schierbec1> jelmer: could i get you to pastebin the crypttext of a revision that doesn't work?
[20:09] <schierbec1> in crypt.verify()
[20:11] <jelmer> http://pastebin.org/26731
[20:11] <schierbec1> yeah, that looks like it should
[20:12] <schierbec1> i'm talking with the seahorse guy, it seems that it's because the key is not in your keyring
[20:12] <jelmer> schierbec1: right, and it shouldn't have to be
[20:13] <jelmer> I mean, seahorse should be able to return the key idea
[20:13] <jelmer> and we could print something like "signature from unknown key YYYY"
[20:14] <schierbec1> jelmer: exactly
[20:14] <schierbec1> right now, i think we should just write "Authenticity cannot be verified -- Key not available"
[20:15] <jelmer> right, that makes sense
[20:20] <schierbec1> jelmer: okay, pushing a fix to lp
[20:21] <schierbec1> let's see if this works
[20:22] <jelmer> schierbec1: yep, works now - thanks
[20:22] <schierbec1> cool
[20:22] <jelmer> schierbec1: This should not be marked as Authentication error imho
[20:22] <schierbec1> i was just about to ask
[20:23] <schierbec1> what do you think? "Authenticity cannot be verified"?
[20:23] <schierbec1> s/verified/confirmed/
[20:24] <jelmer> yep, that sounds good
[20:25] <schierbec1> jelmer: ok, it's pushed
[20:25] <schierbec1> jelmer: just one last thing -- try replacing VerifyText with DecryptText
[20:26] <schierbec1> it could be an error in the VerifyText implementation
[20:26] <jelmer> "No data"
[20:27] <schierbec1> hmm, well, ok then
[20:27] <schierbec1> jelmer: i think i'll rewrite the descriptions
[20:28] <jelmer> schierbec1: we shouldn't be calling discover() imho
[20:28] <schierbec1> we're not anymore
[20:28] <jelmer> my bad, it's just the function that's still there
[20:28] <jelmer> sorry
[20:28] <schierbec1> "The revision has been signed by a person you trust" ?
[20:28] <schierbec1> s/The/This/ ?
[20:29] <jelmer> and which person, if possible :-)
[20:29] <schierbec1> or rather "... signed with a trusted key" ?
[20:29] <schierbec1> jelmer: yeah :)
[20:29] <jelmer> I'd prefer "signed with a trusted key "
[20:29] <schierbec1> okay
[20:30] <schierbec1> and then "This revision has been signed, but you do not trust the authenticity of the key."
[20:32] <jelmer> what about "This revision has been signed with an untrusted key" ?
[20:33] <schierbec1> jelmer: i think it's perhaps too close to the trusted version
[20:33] <schierbec1> just two letters apart
[20:33] <schierbec1> we should emphasize that it's not trusted, as a signature in itself means nothing
[20:35] <jelmer> we need more colored icons :-)
[20:35] <Kinnison> Is bzr currently unable to branch from launchpad?
[20:35] <Kinnison> I was trying to get the gedit plugin and bzr says it's not a branch
[20:36] <schierbec1> jelmer: always :)
[20:36] <schierbec1> jelmer: i'm working out a seahorse patch with the dev guy
[20:36] <jelmer> schierbec1: cool
[20:38]  * Kinnison hrms, also can't bzr pull from the bzr-svn branch
[20:38] <Kinnison> perhaps launchpad is moosed
[20:43] <jelmer> Kinnison: I think there was a regression in bzr.dev that breaks it with launchpad or something
[20:45] <Kinnison> jelmer: arse
[20:45] <Kinnison> oh well
[20:45] <Kinnison> no bzr-svn for me until that's fixed :-)
[20:46] <james_w> Kinnison: you should be able to pull over bzr+ssh://
[20:46] <schierbec1> jelmer: what about "This signature has been signed, but the authenticity of the signature cannot be trusted."?
[20:46] <Kinnison> james_w: from a branch I don't own?
[20:46] <james_w> Kinnison: yeah, you don't need write permission to pull
[20:46] <Kinnison> schierbec1: "...signature has been signed..." ?
[20:47] <Kinnison> james_w: I was more incredulous about having ssh access to branches I didn't own
[20:47]  * Kinnison didn't know that was allowed
[20:47] <Kinnison> I thought launchpad virtual-chrooted you
[20:47] <schierbec1> Kinnison: bzr-gtk ui bits for signed revisions
[20:47] <schierbec1> oops, s/signature/revision/
[20:47] <Kinnison> schierbec1: aah, suddenly it makes more sense :-)
[20:47] <schierbec1> hehe
[20:49] <schierbec1> jelmer: could i get you to check out a patch for seahorse?
[20:49] <schierbec1> svn://svn.gnome.org/svn/seahorse/trunk/
[20:49] <schierbec1> only if you have time
[20:50] <jelmer> schierbec1: sure
[20:52] <jelmer> schierbec1: or http://people.samba.org/bzr/jelmer/seahorse/jelmer :-)
[20:53] <schierbec1> :)
[20:53] <schierbec1> http://pastebin.com/d24eb0110
[20:53] <schierbec1> here's the patch
[20:56] <schierbec1> jelmer: "This revision has been signed, but the authenticity of the key has not been established"?
[20:56] <schierbec1> perhaps s/key/signature/?
[20:56] <schierbec1> just chime in, everybody!
[21:00] <jelmer> schierbec1: I'd rather just say that the key is unknown or untrusted
[21:02] <schierbec1> ok
[21:02] <schierbec1> jelmer: "... but the key is not trusted."?
[21:03] <jelmer> schierbec1: yep
[21:05] <schierbec1> jelmer: have you tried out the patch?
[21:05] <jelmer> working on it
[21:05] <schierbec1> cool
[21:05] <beuno> vila, I've got 2 hours separated for the upload plugin today, so I'll give you the feedback I owe you  :)
[21:06] <vila> beuno: great !
[21:09] <mwhudson> beuno: hi!
[21:09] <jelmer> schierbec1: yep, that patch fixes it
[21:11] <schierbec1> jelmer: awesome!
[21:12] <beuno> hey mwhudson!   welcome back  :)
[21:12] <ubotu> New bug: #210422 in bzr-gtk "gpg signer should be part of ui_factory" [Undecided,New] https://launchpad.net/bugs/210422
[21:16] <schierbec1> jelmer: well, now we just have to wait 6 months until the next stable is released! :)
[21:17] <jelmer> :-)
[21:17] <chell> hi
[21:18] <chell> hey
[21:18] <emgent> http://nopaste/p/aMZkktaSw
[21:18] <emgent> some idea?
[21:18] <emgent> bzr locked.
[21:18] <chell> emgent: nope sorry
[21:19] <chell> "locked 123 hours, 27 minutes ago" sounds a bit weird
[21:19] <jelmer> try bzr break-lock
[21:19] <emgent> jelmer: same error..
[21:20] <emgent> :|
[21:22] <beuno> emgent, try a few times more (sometimes LP locks it a few times)
[21:24] <emgent> beuno: to push or brack-lock ?
[21:24] <beuno> emgent, break lock
[21:25] <beuno> emgent: bzr break-lock bzr+ssh://emgent@bazaar.launchpad.net/~emgent/ubuntu-cve-tracker/universe-security-updates
[21:25] <beuno> 3 or 4 times should do it  :)
[21:25] <emgent> yes i know
[21:25] <emgent> but same problem
[21:25] <emgent> ok :)
[21:25] <beuno> emgent, still nothing?
[21:27] <emgent> ok now work :)
[21:27] <beuno> emgent, :)
[21:28] <emgent> thanks
[21:28]  * beuno wonders when LP will fix that bug
[21:30] <schierbec1> jelmer: okay, now we just need to figure out what to do if seahorse isn't installed
[21:35] <jelmer> schierbec1: hide the signature tab :-)
[21:41] <schierbec1> jelmer: yeah, but we should add a check for seahorse :)
[21:42] <schierbec1> the branch is in the team repo, so you can just commit changes if you wish to
[21:51] <schierbec1> jelmer: what do you think about left-aligning the table "keys"?
[21:51] <schierbec1> i.e. the bold labels
[22:07] <mdke> how can I make changes to the details of my "parent" or "submit" branch?
[22:07] <beuno> mdke, what kind of changes?
[22:08] <mdke> beuno: well, remove them or specify another branch
[22:08] <beuno> mdke, just use bzr push/pull/merge new_location --remember
[22:08] <mdke> thanks
[22:09]  * jdong investigates bzr mailing list... did he break bzrtools?
[22:09] <beuno> :)
[22:10] <jdong> it worksforme....
[22:11] <beuno> jdong, he probably has pycentral b0rked
[22:11] <jdong> beuno: also see bug 210452 though
[22:11] <ubotu> Launchpad bug 210452 in bzrtools "error updating bzrtools" [Undecided,New] https://launchpad.net/bugs/210452
[22:12] <jdong> it seems like a different reporter
[22:12] <jdong> perhaps it only happens on an update?
[22:12] <james_w> jdong: there's a load of bugs filed with this error
[22:12] <james_w> on different packages
[22:12] <james_w> I can't remember the fix offhand, I think it might have been rebuilds, but that doesn't make sense here
[22:13] <james_w> https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/197840 is one
[22:13] <ubotu> Launchpad bug 197840 in bzr-svn "bzr-svn fails to install (Ubuntu Hardy, with ppa bzr)" [Undecided,Fix released]
[22:13] <james_w> https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/197692
[22:13] <ubotu> Launchpad bug 197692 in python-central "package ubuntu-desktop 1.94 failed to install/upgrade: problemas de dependencias - se deja sin configurar" [Undecided,Fix released]
[22:13] <james_w> that's the one
[22:14] <jdong> odd
[22:27] <james_w> jdong: yeah
[22:28] <james_w> jdong: passing it on to python-central may be the right thing to do, I don't know
[22:28] <james_w> I don't really know what bzrtools might have done to provoke this
[22:28] <james_w> although, hang on, bzrtools was a merge, so maybe something was dropped
[22:29] <james_w> or maybe not dropped, but needs to be improved.
[22:59] <xma> 'lo
[23:00] <xma> why does bb crash so often ?
[23:01] <lifeless> does it ?
[23:04] <xma> :)
[23:04] <xma> each time I want to read patch entries => no luck (500 internal error)
[23:10] <lifeless> xma: whats the last couple of lines of the traceback?
[23:11] <xma> each time I have seen it, it was a SQL query
[23:11] <poolie> hello xma
[23:11] <lifeless> let abentley know, probably via the list
[23:11] <poolie> i think it crashes pretty often
[23:11] <xma> poolie: hello
[23:12] <poolie> all things considered
[23:12] <poolie> i still love it deeply
[23:12] <xma> yes it is very valuable
[23:12] <xma> (when it works :))
[23:12] <abentley> It crashes so often mainly because I don't know why it crashes so often :-)
[23:12] <xma> I learnt many python related things when reading people's patches
[23:13] <xma> abentley: hey aaron
[23:13] <xma> 00:04 <lifeless> let abentley know, probably via the list
[23:13] <xma> ;)
[23:13] <xma> so it is down now: OperationalError database is locked
[23:14] <xma> gotta go now
[23:14] <xma> see ya all
[23:18] <poolie> hello abentley
[23:19] <abentley> poolie: hi
[23:19] <poolie> there was a recent bug report of a failure in treetransform
[23:19] <poolie> if you get a sec could you comment on it, if you have not already?
[23:19] <abentley> Okay
[23:19] <poolie> it should still be in the recent list
[23:35] <igc> morning all