[00:06] <berto-> jelmer: no luck on figuring out my os x issues.  i'm going to work on it and when i have it working i'll report back.  i gg for now.
[00:06] <berto-> ttyl.
[00:07] <jelmer> ok
[00:07] <jelmer> bye
[00:11] <lifeless> jelmer: I've filed a bug
[00:14] <jelmer> lifeless: k
[00:14] <lifeless> jelmer: the item_keys_introduced_by function is the current failing thing
[00:15] <ToyKeeper> jelmer: I have a working diff panel in bzrk, but I'm not happy with it and I've been too busy to fix it.
[00:15] <jelmer> ToyKeeper: ah, ok
[00:15] <ToyKeeper> jelmer: If you want it, it's at lp:~toykeeper/bzr-gtk/bzr-vis-enhancements
[00:16] <jelmer> ToyKeeper: I'll wait until you're happy with it
[00:16] <beuno> jelmer, lol, I was just about to send the same patch to the list  (minus the tortoise bits that sneaked into your patch)
[00:17] <ToyKeeper> I probably need to fix some things in DiffWidget.  It doesn't like to have its contents changed after it gets displayed.
[00:17] <mbp_> hello all
[00:17] <ToyKeeper> Also, is there any existing way to save preferences, or should I make something up?
[00:19] <jelmer> ToyKeeper: We generally just use the bazaar configuration infrastructure
[00:22] <beuno> mornin' mbp_   (poolie-in-disguise)
[00:22] <lifeless> hi mbp_
[00:26] <jelmer> hi Martin
[00:26] <jelmer> lifeless: I'm a bit confused about the use of iter_lines_added_or_present_in_keys()
[00:27] <lifeless> jelmer: ignore that, look at the top of the frame
[00:27] <jelmer> lifeless: would it be valid to just retrieve those keys' contents and yield their lines one by one?
[00:27] <lifeless> top-frame
[00:27] <jelmer> ahh
[00:31] <lifeless> jelmer: :)
[00:39] <lifeless> bug 243998
[00:39] <lifeless> jelmer: this is by design; perhaps you could enlarge on why it affects you?
[00:48] <jelmer> lifeless: I've got a plugin that registers a post-push hook
[00:49] <jelmer> that hook will push a index.html page (with a quick description of how to check out the branch, and its history) if there is no remote working tree
[01:01] <lifeless> jelmer: nice; you should catch NotLocalUrl
[01:02] <jelmer> lifeless: that's what I'm doing at the moment
[01:03] <jelmer> it does seem like something that the API could handle for me though
[01:03] <jelmer> since it does have enough data to return a proper value
[01:04] <lifeless> jelmer: it sounds like you want 'has_working_tree' or something; thats really a Look-before-you-leap style method though; I'd question its value
[01:04] <jelmer> lifeless: that's what we're talking about here though
[01:04] <jelmer> this function *is* called has_working_tree()
[01:04] <jelmer> it's not open_working_tree() I'm referring to
[01:05] <lifeless> hmm
[01:05] <jelmer> I think it's perfectly sensible for *open_workingtree()* to raise NotLocalUrl if it's a remote URL
[01:12] <baco> Hi, I am trying to run a smart server via inetd with this line «4155  stream  tcp  nowait  baco  /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/» and when I do telnet to the port I get «bzr: ERROR: unknown command "--inet"»
[01:13] <baco> where is the problem?
[01:16] <mwhudson> lifeless: have you looked at the btrees in the zodb?
[01:16] <mwhudson> (i sort of doubt they're suitable, but probabyl worth a look)
[01:16] <lifeless> mwhudson: I found something that looked like it was that; it uses marshall
[01:16] <lifeless> mwhudson: / pickle
[01:17] <mwhudson> there's a string/string version isn't there?
[01:17] <lifeless> mwhudson: and wants to update - its a disk hash table rather than anything else
[01:17] <mwhudson> yeah, the write-once stuff isn't part of its world
[01:18] <mwhudson> anyway, just a thought
[01:18]  * mwhudson wanders off for a bit
[01:19] <lifeless> mwhudson: http://pypi.python.org/pypi/zc.dict/1.2.1 is what I looked at
[01:19] <lifeless> and http://pypi.python.org/pypi/zope.bforest/1.2
[01:20] <mwhudson> ah, i think i was thinking about bforest and had forgotten a lot of details
[01:21] <lifeless> there is a ZODB.BTrees apparently
[01:21] <lifeless> but I'm having trouble finding it :)
[01:22] <lifeless> (in pypi that is)
[01:23] <lifeless> also there isn't SSBTree, only I or O
[01:24] <lifeless> (as far as I can tell to date)
[01:26]  * lifeless considers running bzr search over zope, so he can find this damn code
[01:27] <lifeless> davidstrauss: how did you go with loggerhead?
[01:28] <davidstrauss> lifeless: haven't tried installing it yet
[01:28] <davidstrauss> lifeless: i'll probably try tomorrow
[01:28] <davidstrauss> lifeless: but thanks for asking
[01:28] <spiv> baco: that's weird, it's like it isn't seeing the 'serve' part of the command line
[01:29] <lifeless> davidstrauss: no probs; I think most people run loggerhead from source, but I may be wrong
[01:29] <baco> spiv: I bet is the inetd server, I am changing it now
[01:32] <baco> spiv: yeah, I was right, is wried anyways, but do not install inetutils-inetd, openbsd-inetd is the one that works
[01:35] <lifeless> mwhudson: yeah, zodb.btrees is not suitable; two reasons - it pickles. and it pickles.
[01:35] <lifeless> mwhudson: oh, and it is mutable, and complex.
[01:36]  * spiv buys lifeless a Pickle-Me-Elmo
[01:36] <lifeless> ewww
[03:42]  * igc lunch
[04:08] <StevenK> lifeless: Continuing from -devel, this is the worrying output:
[04:12] <StevenK> Conflict adding files to libmokoui.  Created directory.
[04:12] <StevenK> Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.
[04:12] <StevenK> Conflict adding file libmokoui.  Moved existing file to libmokoui.moved.
[04:12] <StevenK> (libmokoui is a directory, so 'Conflict adding file' is worrysome
[04:12] <lifeless> StevenK: you add files to directories
[04:13] <lifeless> StevenK: can you create a new branch of the one you were merging into
[04:13] <lifeless> StevenK: and then repeat the merge from the one you were merging from
[04:13] <lifeless> StevenK: (I want to eliminate the chance of local edits causing issues)
[04:15] <StevenK> lifeless: There were no local edits, same behavior from a fresh branch
[04:16] <lifeless> StevenK: ok, please file a bug
[04:17] <lifeless> StevenK: 'adding files' could be clearer I guess, but something is almost certainly wrong if two well formed branches can't merge in that manner without the error about being unversioned
[04:17] <StevenK> lifeless: I suspect the branches haven't seen each other before, but bzr should be able to merge them
[04:18] <lifeless> StevenK: if they don't have a common parent it would error
[04:19] <StevenK> Can I teach it the common parent? I don't see why it's adding files, either, file lists are the same.
[04:19] <lifeless> StevenK: if they have a common parent, then they've seen each other before :). directories added to both sides should (and appear to have) cause a simple conflict - the 'Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.' is what is spurious and seems to have propogated
[04:19] <lifeless> StevenK: does it say 'branches have no common parent cannot merge' ?
[04:19] <lifeless> StevenK: or words to that effect?
[04:19] <StevenK> Branches have no common ancestor, and no merge base revision was specified.
[04:19] <StevenK> I suspect I "branched" this using cp
[04:20] <lifeless> StevenK: ok. that says bzr thinks these are entirely separate projects.
[04:20] <lifeless> StevenK: using 'cp' is fine, unless you then bzr init and add and give everything brand new identity
[04:20] <StevenK> I may well have done that, I'm not certain.
[04:21] <lifeless> StevenK: so. you know bzr has an inode concept right? files and directories have identity separate from path.
[04:21] <lifeless> StevenK: 'bzr add' assigns identity to a file/directory
[04:21] <lifeless> StevenK: bzr merge when two files/directories share a path but don't share identity -> conflict
[04:23] <StevenK> Hm. Drat.
[04:23] <lifeless> StevenK: so, every file that is in common between these two separate projects will conflict. This is appropriate - consider two separate projects with different COPYING contents.
[04:23] <lifeless> StevenK: or even the same, but then one changes its mind; we shouldn't consider them to be the same file.
[04:24] <lifeless> StevenK: there is a genuine bug here - the 'Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.' error is spurious AFAICT
[04:24] <lifeless> StevenK: but you've also, almost certainly, made your life harder by doing 'bzr init' rather than 'bzr branch' at some point in the past.
[04:24] <StevenK> Can I fix that?
[04:25] <lifeless> StevenK: in some senses yes. Essentially, for every common path you need to pick one file id and choose it. That file id will keep its history, the other will show up as deleted at this point
[04:25] <lifeless> StevenK: if there is an upstream/downstream relationship here, you should take the upstreams file ids.
[04:28] <StevenK> lifeless: Okay, so how I pick/change the file ids?
[04:29] <lifeless> StevenK: bzr st *should* show you foo and foo.moved for every conflicting path
[04:29] <lifeless> StevenK: before we go further, can you file a bug with:
[04:29] <lifeless> the two branches
[04:30] <lifeless> the output of 'bzr version-info' in each branch
[04:30] <lifeless> and the output of the merge; I'll clean it up into an actual bug report on the thing I think is going wrong
[04:35] <StevenK> lifeless: Submitted, bug 244115
[04:42] <lifeless> StevenK: thanks
[04:42] <lifeless> StevenK: so
[04:43] <lifeless> StevenK: in your tree right after the merge
[04:43] <lifeless> StevenK: if you do 'bzr diff -r branch:THINGYOUMERGEDFROM'
[04:43] <lifeless> StevenK: we want to keep adjusting your working tree until that diff looks reasonable
[04:43] <lifeless> StevenK: with no delete+add pairs etc
[04:43] <lifeless> StevenK: (assuming the branch you merged from is your 'upstream'.)
[04:44] <lifeless> StevenK: if you are the upstream, we'll use 'bzr diff' to do this test
[04:57] <lifeless> StevenK: ping me when you are back
[05:06] <StevenK> lifeless: I'm back
[05:07] <StevenK> lifeless: I've adjusted the working tree so that the diff looks good already
[05:07] <lifeless> StevenK: right, so does the above make sense?
[05:07] <lifeless> StevenK: against -r branch:, or your local branch?
[05:07] <StevenK> Local
[05:07] <lifeless> StevenK: and which branch has more history ?
[05:08] <StevenK> % bzr di -r branch:../trunk | diffstat | tail -n 1
[05:08] <StevenK>  40 files changed, 5141 insertions(+), 4244 deletions(-)
[05:08] <StevenK> Ah ha
[05:09] <StevenK> lifeless: trunk
[05:09] <StevenK> lifeless: The only changes in the ubuntu branch are under debian/
[05:09] <lifeless> StevenK: try bzr st -r branch:../trunk
[05:09] <StevenK> (trunk has no debian/)
[05:10] <StevenK> lifeless: It has two headings: removed: and added: and both list every file
[05:10] <lifeless> StevenK: right, you've resolve in the wrong direction :)
[05:11] <lifeless> StevenK: can I ask, as you trying to do 'uupdate via merge' ?
[05:12] <StevenK> lifeless: Basically, yes
[05:12] <lifeless> StevenK: so, this is why james_w is working on mass conversions and history joining
[05:14] <lifeless> StevenK: lets get you unblocked - bzr diff -r x..y ../trunk | bzr patch, is likely better
[05:14] <StevenK> x..y being what?
[05:15] <StevenK> Revision numbers, of course, but which?
[05:16] <lifeless> StevenK: well whatever you passed the merge command to make it do something
[05:17] <StevenK> lifeless: I essentially have that on my local branch as it is
[05:26] <lifeless> StevenK: does 'st' show a pending merge ?
[05:31] <StevenK> bzr: ERROR: Revision {('vcs-imports@canonical.com-20080410144539-rrh49m2mt78576ft',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x11ba350>".
[05:31] <lifeless> StevenK: I'd bzr revert and do 'bzr diff -r x..y ../trunk | bzr patch' TBH
[05:32] <StevenK> lifeless: I did
[05:32] <lifeless> StevenK: merging across separate imports is not easy
[05:32] <lifeless> StevenK: if you reverted, then you shouldn't be getting an error
[05:32] <StevenK> lifeless: It was a new branch
[05:34] <lifeless> StevenK: what was it
[05:34] <StevenK> lifeless: Sorry?
[05:35] <lifeless> StevenK: I have no idea what you're talking about anymore, read up and imagine you have only what you've told me to work off :)
[05:36] <StevenK> lifeless: Okay, so I started with a fresh branch using 'bzr branch', and then ran 'bzr di ... | bzr patch'. 'bzr st -r branch:../trunk' gave that error I pasted above.
[05:36] <lifeless> StevenK: ok.
[05:36] <lifeless> StevenK: just 'bzr st'
[05:36] <lifeless> no -r here, because we're not trying to produce a related branch
[05:36] <StevenK> Two files modified
[05:36] <StevenK> Which are the two files changed
[05:36] <lifeless> StevenK: any pending merges ?
[05:37] <StevenK> Nope.
[05:37] <lifeless> StevenK: commit and move on :)
[05:37] <StevenK> lifeless: But when trunk moves on, I can't just merge, I'll have this pain again?
[05:38] <lifeless> StevenK: yes.
[05:38] <StevenK> Can I make the pain stop? :-)
[05:38] <lifeless> StevenK: yes, build from upstream rather than having an unrelated branch
[05:38] <lifeless> 'bzr branch upstream; do stuff'
[05:38] <mwhudson> beuno: are you here/awake ?
[05:44] <StevenK> lifeless: Well, actually, if I could smush the two branches together, it would be ideal. ubuntu for everything under debian/ and trunk for everything else.
[05:46] <lifeless> StevenK: so
[05:46] <lifeless> StevenK: I described above what you need to do to sync up correctly
[05:46] <lifeless> StevenK: but we have to do this on 13K branches, doing it adhoc is really not that useful - james_w will be doing toolchain support for this
[05:47] <StevenK> lifeless: I've done bzr branch upstream, I'm just not sure what I can do to get the files from the existing ubuntu branch into the new one while preserving history
[05:48] <lifeless> StevenK: bzr merge -r 0..-1 ../ubuntu/debian
[05:48] <lifeless> StevenK: you did say that no changes were outside ./debian right ?
[05:50] <StevenK> lifeless: Right
[05:51] <StevenK> lifeless: -1 == HEAD isn't so intituive, either
[05:51] <lifeless> StevenK: -0 is hard to represent
[05:52] <StevenK> lifeless: The code can't have a constant set for HEAD?
[05:52] <lifeless> probably can :)
[05:52] <StevenK> Even if HEAD is a CVS-ism
[05:54] <StevenK> Grumble. bzr log doesn't show history
[05:56] <lifeless> StevenK: have you committed the merge?
[05:57] <StevenK> lifeless: Yes.
[05:57] <lifeless> StevenK: then it should
[05:58] <StevenK> lifeless: bzr merge .... ; bzr ci -m "<msg>"
[05:58] <lifeless> StevenK: bzr log --show-ids -r -1
[05:59] <lifeless> StevenK: does it have one or two parents?
[06:02] <StevenK> lifeless: It has one parent
[06:03] <lifeless> StevenK: so, let me introduce you to 'bzr st'
[06:03] <lifeless> its a great way of seeing what a commit will do
[06:04] <lifeless> :)
[06:04] <StevenK> lifeless: uncommit and then st shows added files, not a pending merge
[06:05] <lifeless> StevenK: of course; do a revert
[06:05] <lifeless> StevenK: then the merge again and see if st shows a pending merge
[06:05] <StevenK> lifeless: No, just added files
[06:06] <lifeless> abentley: is there some other way to join separate imports than 'merge -r 0..-1'? its not adding a pending parent for StevenK .
[06:07] <abentley> lifeless: I can't think of one.
[06:07] <lifeless> abentley: I am sure it used to, I think this is a merge regression - do you agree?
[06:07] <abentley> lifeless: Also, the only reason it wouldn't add a pending parent is if one had already been set.
[06:08] <abentley> ie the merge had been done in the past.
[06:08] <lifeless> abentley: in that case though, merge wouldn't need a -r at all ;)
[06:08] <lifeless> abentley: I think its still considering it a cherry pick
[06:08] <abentley> in that case, the merge should be a no-op.
[06:09] <abentley> My code certainly didn't do that.
[06:10] <lifeless> abentley: yah, like I say I think its a regression
[06:10] <abentley> I tried a merge -r 0..-1 and it behaved as expected.
[06:10] <lifeless> abentley: oh, no I know
[06:10] <lifeless> abentley: I know whats going on and why :)
[06:10] <abentley> Was a file specified in the merge?
[06:11] <lifeless> StevenK: ok, heres what to do
[06:11] <lifeless> abentley: yes
[06:11] <lifeless> StevenK: revert / uncommit etc until you have whats in trunk
[06:11] <lifeless> StevenK: then:
[06:11] <lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st
[06:13] <abentley> lifeless: There is "join", of course.  That's less general than you asked about.
[06:13] <StevenK> Okay, bzr st now shows a pending merge, but there was a bunch of errors from the other 3 commands.
[06:13] <lifeless> StevenK: thats ok
[06:13] <abentley> lifeless: also the merge-into plugin.
[06:13] <StevenK> And that's impressively counter-initutive :-)
[06:13] <lifeless> StevenK: it should ahve your ubuntu files etc; and you can just commit now
[06:14] <lifeless> abentley: yes, doing join and deleting and rearranging is probably the preferred ui
[06:14] <StevenK> I wonder if I can remove the 'submit' branch shown in bzr info
[06:14] <lifeless> StevenK: like I say, you're doing something that there is not much toolchain support for yet, and you can only do because you have the special case of no overlapping files
[06:15] <StevenK> Ah. We're trying to outsmart bzr a little too, I suspect?
[06:17]  * StevenK blinks. The merge works, but debian/ doesn't exist?
[06:18] <lifeless> StevenK: its not listed in 'bzr st' ?
[06:18] <StevenK> bzr st doesn't show anything. I've commited.
[06:18] <lifeless> StevenK: log -v -r -1 ?
[06:19] <StevenK> It shows the merge, and it that it added every file
[06:19] <StevenK> s/and it/and/
[06:21] <lifeless> StevenK: 'every file'?
[06:22] <StevenK> lifeless: Well, added every file, such as AUTHORS, NEWS, README, etc
[06:22] <StevenK> lifeless: I can pastebin the output, if you wish?
[06:23] <lifeless> StevenK: sure
[06:24] <StevenK> lifeless: http://paste.ubuntu.com/23876/
[06:25] <lifeless> StevenK: looks fine to me
[06:25] <lifeless> StevenK: lines 16 through 18
[06:25] <lifeless> StevenK: etc
[06:25] <lifeless> StevenK: what about 'bzr st -r -2..-1' ?
[06:26] <StevenK> lifeless: No output
[06:27] <lifeless> StevenK: ok, I think the last merge didn't quite do what we wanted
[06:27] <lifeless> StevenK: uncommit :)
[06:27] <lifeless> StevenK: repeat the 15:11 < lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st
[06:27] <lifeless> step
[06:27] <lifeless> and make sure debian is present and everything ok before you commit
[06:27] <StevenK> lifeless: bzr st still shows a pending merge
[06:27] <lifeless> revert too
[06:27] <StevenK> lifeless: Or revert and redo?
[06:28] <StevenK> Done. And:
[06:28] <StevenK> ls: cannot access debian: No such file or directory
[06:29] <lifeless> uhm
[06:29] <lifeless> bzr st
[06:29] <lifeless> does it list debian etc?
[06:29] <StevenK> It just shows a pending merge
[06:29] <StevenK> % bzr st
[06:29] <StevenK> pending merges:
[06:29] <StevenK>   Steve Kowalik 2008-04-19 Add missing X[BS]-Python-Version fields.
[06:29] <StevenK> ...
[06:29] <lifeless> bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st
[06:30] <StevenK> bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1349e10>".
[06:30] <lifeless> argh
[06:30] <lifeless> bzr revert
[06:30] <StevenK> Okay
[06:30] <lifeless> bzr branch ../ubuntu ./tempdir
[06:30] <lifeless> bzr join tempdir
[06:30] <lifeless> bzr mv tempdir/debian debian
[06:31] <lifeless> bzr rm --remove tempdir
[06:31] <lifeless> bzr st
[06:32] <StevenK> bzr: ERROR: Can't join trees because KnitPackRepository('file:///home/steven/canonical/moko/libmokoui2/ubuntu/.bzr/repository/') doesn't support rich root data.
[06:32] <StevenK> You can use bzr upgrade on the repository.
[06:32] <lifeless> ugh
[06:33] <lifeless> StevenK: that Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1349e10>" is a bug
[06:33] <lifeless> StevenK: what version of bzr do you have?
[06:33] <StevenK> Woo, another one
[06:33] <StevenK> lifeless: 1.4
[06:33] <lifeless> StevenK: try 1.5
[06:33] <lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st
[06:34] <StevenK> Try that with 1.5?
[06:34] <lifeless> yes
[06:35]  * StevenK digs for the bzr PPA
[06:42] <StevenK> lifeless: 1.5 still gives bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xf979d0>".
[06:45] <lifeless> StevenK: ok, file a bug I guess
[06:45] <lifeless> or try 1.3
[06:51] <StevenK> lifeless: 1.3.1 gives the same error
[06:54] <lifeless> bleep
[06:54] <lifeless> bugger a file for sure
[07:09] <StevenK> lifeless: Not sure what the bug is. :-)
[07:09] <lifeless> getting that error
[07:18] <Suigintou> "My husband comes from a family where the men are always in charge. He was very nice to me when we were dating and after we got married he changed like he thinks he is my master. I feel like a slave sometimes and if I don't do what I am supposed to he yells and curses at me and he even spanks me. He doesnt usually hit me too bad but I am thinking that if we have a baby maybe he would be nicer with a child in the house. What do you peo
[07:18] <Suigintou> ple think I should do."
[07:18] <Suigintou> lol, stupid women
[07:23] <lifeless> Suigintou: thats really not on topic for this channel
[07:23] <lifeless> Suigintou: not to mention being offensive
[08:04] <lifeless> mbp_: I have some initial figures on the B+Tree index approach
[08:05] <lifeless> mbp_: looks like 2 IO's for up to 250K keys
[08:05] <lifeless> mbp_: and 3 for up to 125M keys
[08:07] <Suigintou> wrong channel, in fact, wrong network altogether, really sorry
[08:59]  * igc dinner
[10:15] <gour> hi, how is bzr with handling (bigger) binary files, e.g. movies
[10:17] <gour> i tried to add (by mistake) some rendered files (*.ac3, +.m2v, *.mpg) where *.mpg is ~220MB and darcs was on knees using 1GB of memory + 1GB of swap :-/
[10:18] <gour> it's my old video-project and i'll definitely migrate it from darcs
[10:18] <beuno> gour, yeah, not so good. It uses about 3x the amount of memory of the file's size
[10:18] <beuno> if you hace enough ram, you can pull it off, but, in general, it's probably not the best idea
[10:18] <gour> bzr?
[10:18] <beuno> yeah, bzr
[10:19] <lifeless> gour: its improvable
[10:19] <lifeless> gour: and sounds like better than darcs :)
[10:19] <gour> hmm, 3x is till better than 2GBs for ~220MB file
[10:19] <gour> *still
[10:19] <gour> hopefully, it does not try to keep them all at once in memory
[10:20] <gour> lifeless: good. let me burn & print DVD first, then i'll check how bzr does
[10:20] <beuno> lifeless, what's improvable?
[10:20] <gour> during that attempt my machine become totally non-responsible :-/
[10:21] <lifeless> beuno: memory use
[10:22] <beuno> lifeless, the estimate is still 3x the file's size though, right?
[10:22] <gour> it's not very common use, but when doing video-editing it might be useful to be able to store files
[10:22] <lifeless> beuno: we can do better
[10:22] <lifeless> beuno: we don't today, but we can
[10:26] <beuno> lifeless, right, that reminds me of some bug where the user asked if we could warn them before adding a file that would probably run out of memory while committing. Is that too difficult to do today?
[10:26] <lifeless> beuno: its tricky
[10:26] <lifeless> beuno: some people have 8GB RAM
[10:27] <lifeless> beuno: some ave 8GB VM and 2GB ram
[10:27] <lifeless> beuno: at what point is 'out of memory' is it thrashing? is it hitting swap? etc
[10:27] <lifeless> using a non refcounting python would help too
[10:27] <beuno> hm, yeah, may be worth working on the actual problem then
[10:28]  * gour has 1GB only :-(
[10:29] <beuno> gour, well, 1GB should be enough for 220mb files
[10:30] <gour> darcs used 1GB + 1GB swap to add 15M + 180M + 222M
[10:30] <gour> and machine was down
[10:30]  * gour --> copy-shop to print DVD cover. bbl
[11:37] <ToyKeeper> gour: For large files like that, you might find rsnapshot more appropriate...  at least, if you just want to be able to retrieve old versions.
[11:38] <ToyKeeper> Or, perhaps rdiff-backup, if you make small changes to big files (like changing the ID3 tag in a mp3)...  could be more space-efficient.
[11:41] <gour> ToyKeeper: well, when i work with cinelerra i keep its project (xml) files and some graphic files under vcs, so it was mistake to add those rendered files and interesting (darcs) result. now, when i finish with burning, i'll check how will bzr react
[12:39] <mkanat> ERROR: Repository KnitPackRepository('file:///home/mkanat/projects/mw/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://control.trusthosting.net/var/www/html/everythingsolved.com/bzr/mingleware/.bzr/) ?
[12:44] <mkanat> Is that telling me that I can't use bzr+ssh with a rich-root-pack repo??
[12:44] <lifeless> mkanat: its telling you that one of repositories is rich root and one isn't
[12:45] <lifeless> mkanat: really shoukld make the error clearer
[12:45] <mkanat> lifeless: Hmm, I thought I made them both rich-root.
[12:45] <mkanat> lifeless: They're both rich-root-pack, I just checked.
[12:47] <mkanat> lifeless: At least, that's what .bzr/repository/format says.
[12:51] <mkanat> What's the difference between .bzr/branch-format and .bzr/branch/format ?
[12:54] <mkanat> Hmm, guess I need a newer bzr on the server side, that's my guess.
[12:58] <lifeless> mkanat: possibly; what version is it?
[12:58] <mkanat> It's 1.3 on the server, 1.5 on the client.
[12:58] <lifeless> .bzr/branch-format is the control dir format
[12:58] <mkanat> Ah, okay.
[13:00] <lifeless> (before 0.8 we didn't have split out repository/branch/checkout objects)
[13:00] <lifeless> so its named whackily, but backwards compatible
[13:00] <mkanat> Ahh. :-)
[13:00] <mkanat> Hmm, upgrading the server didn't help.
[13:01] <mkanat> sftp checkout works fine, bzr+ssh doesn't.
[13:02] <lifeless> mkanat: file a bug please
[13:02] <mkanat> lifeless: Okay, will do.
[13:03] <mkanat> Ah, it's already filed as bug 205579.
[13:04] <lifeless> mkanat: you sure its the same?
[13:05] <mkanat> lifeless: Yep, identical problem.
[13:56] <Pilky> I dunno if there are any other Xcoders in here but if there are then this may interest you: http://www.mcubedsw.com/blog/index.php?/site/comments/build_numbers_from_bazaar/
[14:24] <jelmer> Pilky, nice
[14:29] <Tsmith> after a branch merge, do you just delete the branch?
[14:31] <beuno> Tsmith, a little more information may be needed to answer that question  :)
[14:31] <beuno> you where working in a branch separate from the mainline
[14:31] <beuno> and you merged that into, let's say trunk?
[15:22] <guilhembi> abentley: hi! I wrote several posts on support issue 00002413
[15:22] <abentley> guilhembi: Hi there.  I saw them.
[15:22] <guilhembi> abentley: even the latest one?
[15:23] <abentley> "I missed your comment?"
[15:23] <abentley> I did see that.
[15:24] <guilhembi> abentley: ok, thanks
[15:24] <abentley> Right now, I'm looking into this tests directory conflict.
[15:24] <guilhembi> abentley: uber-great!
[15:24] <guilhembi> abentley: mysterious how mysys/tests/Makefile.am wasn't imported...
[15:25] <abentley> If mysys/tests *was* deleted, possibly Makefile.am was deleted at the same time.  But I can't say whether that happened yet.
[15:28] <guilhembi> abentley: and I don't know either if it was deleted. Looking for creation history when the file exists, is easy, but for deletion history when it's missing, is not, and it's not specific to bzr.
[15:28] <abentley> Yeah.  I can do it, it'll just take a bit.
[15:30] <guilhembi> abentley: after doing some grep somewhere, it looks like it was never deleted and never existed in 6.0-ndb
[15:33] <abentley> So far, I've determined that the file was created in mysql-5.1-telco-6.2-merge revno 2555.13.2
[15:38] <guilhembi> abentley: is that the same as sp1r-mtaylor@solace.(none)-20080425063223-04764 ?
[15:38] <abentley> guilhembi: Yes.
[15:43] <abentley> guilhembi: So it looks like my results match yours; 'tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j' is not a descendant of '﻿sp1r-mtaylor@solace.(none)-20080425063223-04764'
[15:43] <guilhembi> abentley: uh, did I say that...
[15:44] <abentley> Therefore the first didn't delete the directory created by the second.
[15:45] <abentley> It doesn't have the directory because it never had the opportunity to get it.
[15:45] <guilhembi> that I agree
[15:46] <abentley> So now I have to find out why bzr thought it did.
[16:43] <gour> heh, finally i found time to test how bzr handles binary files...i tried to add the same 3 binaries which put darcs on the knees (15M, 180M and 222M) and bzr handled them OK
[16:44] <gour> sure, there is room for improvement for the memory usage, but it was workable, while with darcs my machine almost stopped responding using all of 1GB RAM as well as 1GB of swap
[17:19] <NfNitLoop> so I'm doing a "push" to a remote (windows) filesystem.
[17:19] <NfNitLoop> slooow. :p
[17:19] <NfNitLoop> (The connection is just slow & laggy)
[17:20] <NfNitLoop> I imagine a pull would go much more quickly...  but I'm not sure if I have rights to install bzr on that end.  >.<
[17:37] <bpeterson> can I "clean out" a shared repo? can I get rid of the revision stored there that no longer have branches?
[17:39] <jam> bpeterson: I believe there is a plugin for it (bzr-remove-revisions), but there isn't a core garbage collection command
[17:40] <bpeterson> what does bzr pack do?
[17:40] <jam> bpeterson: combines small packs into larger ones
[17:40] <bpeterson> oh
[17:40] <bpeterson> thanks
[17:42] <bpeterson> are there plans to add some garbage collection type thing?
[18:35] <jam> abentley: ping, a question on the _merge_names logic
[18:36] <abentley> jam: pong
[18:36] <jam> abentley: you have this logic:
[18:36] <jam>         if this_name is None:
[18:36] <jam>             if name_winner == "this":
[18:36] <jam>                 name_winner = "other"
[18:36] <jam>             if parent_id_winner == "this":
[18:36] <jam>                 parent_id_winner = "other"
[18:36] <jam> Which seems to say "if this wants to delete the file, switch and consider "other" to introduce it
[18:36] <jam> Am I understanding that correctly?
[18:37] <abentley> jam: If you have a conflict, and so you need a name for it, and there's no name in THIS, use the name in OTHER.
[18:37] <jam> abentley: and if you don't have a conflict?
[18:38] <jam> It only does something if the _merge_contents happens?
[18:38] <jam> Is this just reserving a potential name?
[18:38] <abentley> I believe that the name isn't used if there is no conflict.  I would have to double-check, though.
[18:39] <jam> abentley: ok, it made it a bit harder to debug what was going on.. but if it is just reserving the name, it doesn't seem to be a problem
[18:39] <jam> It uses "if changed: self._merge_contents()" and in this case changed == False
[18:43] <abentley> jam: I believe this is the case that handles directory deleted in X, directory has files added in Y, merge X and Y.
[18:44] <jam> sure
[18:45] <abentley> It adjusts the path associated with the file, but is silent about whether anything is present at that location.
[18:47] <jam> abentley: sure, it seems my lca_multi_way logic is giving the right result
[18:47] <jam> but at a higher level I'm setting "changed=True" because the file is different versus *one* of the basse
[18:47] <jam> bases
[18:47] <jam> so it is picking OTHER for the filename, and then conflicting because of the other work
[18:48] <jam> oh well, at least the multi-way logic is correct :)
[18:52] <abentley> Ah well.
[18:53] <abentley> jam: In other news, it seems that VersionedFile is dead, dead, dead in bzr.dev.
[18:54] <jam> VersionedFiles is dead, long live the VersionedFiles
[18:54] <jam> VersionedFile is dead, long live the VersionedFiles
[18:54] <jam> I guess that works better :)
[18:54] <abentley> So we don't need to hoist get_line_list into it.
[18:55] <abentley> But iter_files_bytes looks to be efficiently implemented.
[18:55] <jam> So does it have an "add_bytes" method then?
[18:56] <abentley> No, just add_lines.
[18:58] <abentley> PlanMergeVersionedFile is still a VersionedFile, though.
[18:58] <abentley> We should probably fix that.
[18:58] <jam> abentley: actually, when I look closer, it doesn't look like it is done efficiently across multiple versions
[18:58] <Odd_Bloke> jelmer: I notice you've updated a few of your PQM branches recently.  Are those things I should be interested in?
[18:58] <jam> abentley: it seems to extract the deltas needed efficiently
[18:58] <jam> but then it does
[18:59] <jam> record.get_bytes_as('fulltext')
[18:59] <jam> for *each* record
[18:59] <jam> And Knits seem to do
[18:59] <jam>         if storage_kind == 'fulltext' and self._knit is not None:
[18:59] <jam>             return self._knit.get_text(self.key[0])
[19:00] <jam> unless the get_record_stream is smarter than I thought
[19:00] <jam> still looking
[19:01] <Odd_Bloke> thumper: You seem to have some relatively recent unmerged branches too, should I be interested in those?
[19:01]  * Odd_Bloke notes that he will bug by email if he hasn't received a response by this evening (BST).
[19:01] <abentley> Odd_Bloke: thumper has submitted at least some of those to lifeless for review.
[19:02] <jam> abentley: it looks like if you pass "include_delta_closure" it then expands all the requested texts into fulltexts
[19:02] <Odd_Bloke> abentley: Thanks, that's helpful to know. :)
[19:03] <jam> abentley: so it looks like it might, indeed, be done properly, but man the layering makes it difficult to see
[19:03] <jam> I suppose any time you pass "include_delta_closure" actually means that you always want fulltexts?
[19:03] <abentley> Odd_Bloke: https://code.edge.launchpad.net/~lifeless/pqm/trunk (see list of proposed merges)
[19:04] <Odd_Bloke> abentley: Cool, thanks.
[19:05] <abentley> I have no idea what include_delta_closure would mean.
[19:05] <Odd_Bloke> Pretty cool to see LP being used for this sort of stuff.
[19:05] <jam> abentley: well it is get_record_stream(keys, ordering, include_delta_closure)
[19:06] <jam> It seems to me that 'include_dellta_closure' would be a flag to include the deltas necessary to build everything into the record stream
[19:06] <jam> but not necessarily unpack them into fulltexts
[19:07] <abentley> jam: That's how I read the comment.
[19:07] <abentley> or docstring, rather
[19:09] <jam> abentley: yeah, but it seems all callers mean "give me fulltexts" and use it as such ...
[19:09] <jam> fetch() passes False, callers that want fulltexts pass True
[19:10] <jam> I'm guessing this is a case where Robert started thinking one way
[19:10] <jam> ended up a different way
[19:10] <jam> and didn't update all the places inbetween
[19:15] <abentley> jam: Yeah.
[19:15] <abentley> It seems he could trivially have done LinesContentFactory, and avoided the memory bloat.
[19:18] <jam> except the trivial implementation would have to apply all the deltas for each fulltext
[19:18] <jam> getting one which does the minimum amount of work before each request would be possible
[19:18] <jam> but non-trivial to write
[19:18] <jam> certainly it seems that the api would work with that situation, though.
[19:19] <abentley> He's already calling get_content_maps, which ought to be efficiently returning lines.
[19:23] <abentley> And it looks like he doesn't expect anyone to hold on to a ContentFactory, in which case there's no memory wasteage.
[20:00] <abentley> jam: It looks like PlanMergeVersionedFile has become a VersionedFiles, so get_line_lists should probably hang off _PlanMerge.
[20:02] <jam> Well... we could also just use get_record_stream() directly, since it seems to be on all VersionedFiles, record.get_bytes_as('fulltext') will return the lines.
[20:02] <jam> At least, as I understand the structuring.
[20:04] <abentley> jam: actually PlanMerge has get_lines, which returns lines for list of versions.
[20:04] <abentley> So there's already a friendly multi-get method.
[20:05] <jam> so... the 'get_lines()' api changed...
[20:05] <jam> oh, I guess this is on PlanMerge
[20:05] <jam> nm
[20:21] <jelmer> Odd_Bloke, hi
[20:21] <jelmer> Odd_Bloke, possibly - one replaces automake with setup.py
[20:22] <jelmer> the other uses a python module for gpg signature verification rather than invoking gpgv directly
[20:22] <jelmer> (the latter was causing breakage on my machine)
[20:26] <NfNitLoop> "breakage"?
[20:34] <abentley> jam: I posted the merge-delete-and-change tests to the list.
[20:36] <abentley> jam: I don't really understand the remaining test you wanted.
[20:38] <jam> The one for "ha_ndbcluster.cc"
[20:39] <jam> abentley: The idea is to have a merge which cannot be solved by the first LCA analysis
[20:39] <jam> nor by using just unique_lca + first lcas
[20:40] <abentley> This is a text merge?
[20:53] <jelmer> abentley, Is there any reason creating a merge directive requires write access to the repository?
[20:58] <abentley> jelmer: Yes.  It fetches the head revision of the submit branch into the local branch.
[21:07] <jelmer> abentley: Ah, that makes sense. Thanks!
[21:07] <jelmer> Related to this..
[21:08] <jelmer> Is there any easy way to upgrade read locks to write locks?
[21:08] <abentley> jelmer: Only if you control the whole call stack.  If you might want a write lock, take a write lock.
[21:20] <Odd_Bloke> jelmer: Is there any specific reason that the distutils one hasn't been merged, or has it just not been reviewed yet?  That'd make my life easier, because I just don't understand autotools.
[21:20] <jelmer> abentley: hmm, ok
[21:22] <Odd_Bloke> It would also reduce the number of files that are created in the root of the branch.
[21:32] <abentley> jam: One thing I forgot to mention; the problem with using a non-unique LCA during criss-cross is that disputed resolutions get silently resolved in favour of one side.  But this is what MySQL wants, no?
[21:55] <abentley> jam: I haven't been able to concoct a merge scenario for the last test.
[21:55] <mwhudson> beuno: hello
[21:55] <beuno> morning mwhudson!
[21:56] <jam> abentley: I'm happy to have a test with "weave" that asserts that is what it does. I can't say for sure what they would prefer, as at this point we have bad graphs all over the place messing things up :)
[21:56] <mwhudson> beuno: the new_theme needs a symlink icon
[21:56] <jam> In *general* they feel like if "bzr gannotate" shows the line as in the history
[21:56] <jam> they shouldn't be bothered by a conflict
[21:56] <jam> and the criss-cross different resolutions is something that you can't detect
[21:56] <jam> using gannotate
[21:56] <mwhudson> beuno: i tried to say this in email yesterdary but sent it to poolie instead :)
[21:57] <jam> So I think it is more of "If you can't answer 'why is this conflicted', don't show me a conflict".
[21:57] <beuno> mwhudson, it should have one, I may of forgot to add it
[21:57]  * beuno checks
[21:58] <abentley> What is this responding to? "﻿I'm happy to have a test with "weave" that asserts that is what it does..."
[21:59] <jam> abentley: That a mixmatched resolved conflict is silently ignored. You can write an XFail test or just a plain test for that if you want.
[22:00] <jam> I *can* say that --lca as it is implemented now still conflicts more than --weave, and they are worried about the "silently unclean merge" bug.
[22:01] <abentley> jam: I was trying to say that we might make them happy by writing a merge3 that uses a non-unique LCA.
[22:01] <jam> maybe, but --weave does the job too
[22:02] <mwhudson> beuno: bug #242580 is odd, and worrying
[22:02] <ubott2> Launchpad bug 242580 in loggerhead "Current trunk tends to peg CPU at 100% after running a while, for no obvious reason" [High,New] https://launchpad.net/bugs/242580
[22:02] <abentley> jam: --weave is making you do major surgery to the inventory code.  I'm not saying it's the wrong approach.  But I would be remiss in not pointing out the merge3 option.
[22:04] <lifeless> moin
[22:04] <beuno> mwhudson, is it related with what's happening in LP?
[22:05] <mwhudson> beuno: well, hard to say!
[22:06] <mwhudson> but he's only serving 18 branches
[22:06] <beuno> mwhudson, yeah. I suppose if this was widespread, the gnome mirror would be on it's knees
[22:07] <mwhudson> otoh, he does seem to be accessing branches over http
[22:07] <mwhudson> well, some branches
[22:08] <mwhudson> the name resolution failures could easily be running out of fds too, i'd guess
[22:08] <mwhudson> beuno: in any case, i hacked up a branch to help with the LP issues last night, let me push it
[22:10] <beuno> mwhudson, oh, cool. It closes the branch?
[22:10] <lifeless> jam: what sort of bad graphs do we have?
[22:10] <beuno> mornin' lifeless
[22:11] <jam> abentley: bad paths are making me do it :) And if we picked the wrong lca, we would be in the same position
[22:11] <mwhudson> beuno: it makes History objects ephemeral
[22:11] <mwhudson> beuno: and caches the expensive to calculate stuff elsewhere
[22:11] <jam> remember, we have (path1, None, None) for bases, and path2 for THIS, path1 for OTHER
[22:11] <jam> So if you pick the None LCA, you get the wrong answer
[22:11] <jam> if you pick the path1, you get the right answer for *this* file.
[22:12] <lifeless> whats the None, None there?
[22:13] <beuno> mwhudson, I'll take a peak at the branch.
[22:13] <mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/dont-hold-branches-open
[22:13] <mwhudson> there's some pretty nasty code in places, but i like the idea
[22:14] <mwhudson> beuno: have you thought about a prettier file listing at all?
[22:15] <beuno> mwhudson, this is related to the new theme?  Prettier the what we have now?
[22:15] <beuno> now == new theme
[22:15] <mwhudson> beuno: i haven't looked in the new theme...
[22:16] <mwhudson> beuno: ah sorry, i was vauge
[22:16] <mwhudson> vague
[22:16] <mwhudson> beuno: i meant BranchesFromFileSystemServer.directory_listing
[22:17] <beuno> mwhudson, ah, yes. I tried the other day, but my brain was fried and I was taking too many shortcuts  :)
[22:17] <jam> lifeless: The 'path' in that base is None, because the file doesn't exist there
[22:17] <beuno> I have 2 branches half-baked.  Proper setup.py, and template for directory listing
[22:17] <jam> it was added in one of the LCAs
[22:18] <mwhudson> beuno: both sound like good things :)
[22:18] <beuno> mwhudson, for starters, I thought we could use the same that we use to navigate branches/projects, and see what can actually be improved later on
[22:18] <mwhudson> beuno: mmm
[22:18] <lifeless> jam: so its (id, revision, path) ?
[22:19] <mwhudson> beuno: that sounds like it would be difficult because of shortcuts /i/ took in wsgi-ify :)
[22:19] <jam> lifeless: no it is (path_in_base1, path_in_base2, path_in_base3)
[22:19] <jam> we have 3 common ancestors
[22:19] <jam> (least common ancestors)
[22:19] <beuno> mwhudson, yes, that's what provoked less-then-acceptable hacks, and made me discard it  :P
[22:19] <jam> if we go all the way back to the unique_lca, the path is None, because it didn't exist yet
[22:20] <jam> So you see base = None, this = path2, other = path1
[22:20] <jam> aka, conflict
[22:20] <lifeless> and they want it to resolve to path2 no conflict?
[22:20] <jam> For *one* of the LCAs, you can see base = path1, this = path2, other = path1, aka path2 wins
[22:20] <jam> lifeless: yes, because that is *true* for the file in question
[22:20] <jam> it is only because we can't see it for the criss-cross throwing off our base selection
[22:21] <beuno> mwhudson, do you have any specific ideas for that bit?
[22:21] <jam> if we picked the base from the per-file graph, we would do it "correctly"
[22:21] <lifeless> jam: does the per file graph help? ok
[22:21] <mwhudson> beuno: not really, but start from scratch :)
[22:21] <lifeless> jam: and you've tried taking the per file graph an indexing from there back to the inventory contents?
[22:21] <jam> lifeless: no, I don't want to have to extract the full inventory for every file
[22:22] <jam> just to get the path, etc. each time
[22:22] <mwhudson> beuno: tbh, what i generate already with the standard macros.pt stuff wrapped around it would probably be ok
[22:22] <lifeless> jam: you don't have to though
[22:22] <beuno> mwhudson, heh, good, that's what I did.  Those are the two remaining bits I think we need, apart from new theme, to release 1.6
[22:22] <lifeless> jam: well, to be clear: you don't have to do full upgrading to Inventory to get the path out - from bzrlib.plugins.search.inventory import ids_to_paths
[22:22] <mwhudson> beuno: i'd like to put a vote in for dont-hold-branches-open :)
[22:22] <beuno> mwhudson, I can make it look better with the current approach then, generate it through python
[22:23] <mwhudson> beuno: and see if that fixes mkanat's problem
[22:23] <beuno> mwhudson, sure, I've got to go home and pick up some stuff, and I'll review/test it
[22:24] <lifeless> jam: thats reasonably close to being tweakable to process lines through the regex just-in-time
[22:25] <mwhudson> beuno: it's not really ready yet from a code clarity POV, but testing would certainly be appreciated :)
[22:25] <lifeless> abentley: can you help me understand bug 244115 ?
[22:25] <ubott2> Launchpad bug 244115 in bzr "merge between two branches fails" [Undecided,Confirmed] https://launchpad.net/bugs/244115
[22:26] <jam> lifeless: except it won't work if we change serialization formats, etc. I think I have a reasonable solution using our current apis, that should even perform decently, I just have to implement it.
[22:26] <jam> I can actually get the path correct using simple lca lookups
[22:26] <jam> the problem is that the file shows up as "changed" because of the [path, None, None] stuff
[22:26] <jam> so I need to do the same "is this actually changed" at a higher level
[22:26] <lifeless> abentley: I don't understand why it sees libmokoui as unversioned
[22:27] <beuno> mwhudson, I'll try and poke holes in it  :p   and, also, Peng is *really* good a poking holes
[22:27] <mwhudson> :)
[22:29] <abentley> lifeless: I don't really have time.  This is a cherrypick into an unrelated tree.  It adds a file to libmokoui, which doesn't exist, because this is an unrelated tree.  It doesn't add libmokoui because this is a cherrypick.
[22:29] <lifeless> abentley: I'll double check, but I was pretty sure libmokoui existed in both trees
[22:36] <lifeless> abentley: thanks, I get the cause now; I've commented back in the bug
[22:37] <jelmer> Odd_Bloke, IIRC lifeless didn't see a good enough reason to switch over from automake
[22:37] <lifeless> I didn't see the need to recreate all the existing automake support for docbook etc in setup.py and then maintain it
[22:38] <lifeless> its 'create more work because we like work'
[22:39] <Odd_Bloke> Yeah, I found the bug a while after asking and forgot to mention it.
[22:40] <Odd_Bloke> Well, by the looks of it, jelmer has already recreated the existing support in his patch.
[22:40] <lifeless> Odd_Bloke: its not a one time thing
[22:40] <lifeless> Odd_Bloke: that is code, it has to be bugfixed and maintained
[22:42] <jelmer> lifeless: Maintaining python code with automake has the same problems but the other way around
[22:43] <lifeless> jelmer: I'm happy to chain into setup.y if the automake python support is going to give us grie
[22:43] <jelmer> (the reason I ended up working on this was because I was looking into debianizing pqm but it was installing into the wrong directory)
[22:43] <lifeless> f
[22:58] <lifeless> jelmer: well, like I say, I just don't want the maintenance burden of reinventing automake + autoconf + make and all that dependency checking and correctness in setup.py
[22:58] <lifeless> If I'm going to maintain a build tool; it will be something clean :)
[22:59] <jelmer> heh
[22:59] <lifeless> jelmer: so if you want to migrate the bits that are problematic for debian to a setup.py file, and have ./configure && make chain through to that - thats ok and I'll review and merge.
[22:59] <jelmer> lifeless: the docbook stuff is the only bits that should remain in the end
[22:59] <mwhudson> at least libtool isn't involved
[23:00] <lifeless> mwhudson: well yes
[23:13] <jelmer> lifeless, That still keeps the heavy dependency on automake and just complicates things by using more build systems
[23:14] <jelmer> lifeless: My patch replaced 143 lines of automake+autogen with 162 lines of setup.py
[23:15] <lifeless> jelmer: and it was correct? or does it build doco every run unconditionally etc etc?
[23:15] <lifeless> jelmer: I think we're just not connecting here -
[23:19] <jelmer> lifeless: yes, it is - even if it wasn't, that's a different issue
[23:21] <jelmer> lifeless: sorry, I do indeed still don't see your point
[23:26] <lifeless> jelmer: so my issue is about having a NIH build tool for docbook in pqm; I think its wrong
[23:26] <lifeless> jelmer: I don't think that code belongs in the pqm tree
[23:26] <jelmer> lifeless: it's not a NIH build tool - it's just a distutils wrapper that calls xmlto
[23:26] <lifeless> I'll have to recheck the patch then
[23:29] <jelmer> Should I sent an updated bundle to the list, ccing you?
[23:30] <jelmer> I've just resolved some conflicts after merging trunk
[23:38] <lifeless> jelmer: to the patch, sure
[23:40] <mbp_> good morning
[23:41] <jam> mbp_: good morning, didn't we a have a call today? (and what have you done with poolie? :)
[23:42] <mbp_> hm
[23:42] <mbp_> silly irssi
[23:42] <mbp_> jam, i think we talked last week so i had it down for next weex
[23:43] <jam> poolie: well, my gcal shows it as this monday, but we did have a separate call last week
[23:43] <jam> I'm happy to bump it if you prefer
[23:43] <poolie> i'm away next tuesday so how about if we talk either monday or wednesday
[23:45] <jam> wed is good
[23:47] <jelmer> lifeless, sent
[23:47] <jam> poolie: hopefully the google calendar invite made it through properly
[23:48] <jam> but that puts the next meeting as Tues July 8th US, Wed July 9th AU time
[23:48] <jam> And for now, the next is Mon, Jul 20th / Tues Jul 21st.
[23:50] <poolie> um
[23:50] <poolie> do you mean the 21st/22nd?
[23:50] <poolie> " Cross your fingers and try again in a few minutes, or talk to the person who set up this event." :-)
[23:51] <poolie> i have it on paper anyhow
[23:53] <lifeless> jelmer: to the bug?
[23:53] <jelmer> lifeless, no, to the list
[23:53] <lifeless> jelmer: could you please send attach it to the bug?
[23:53] <jelmer> k
[23:54] <lifeless> thanks