[00:32] <jelmer> kklimonda, yes, that's correct
[00:33] <jelmer> kklimonda, svn-import imports all of history, it's different from e.g. "svn checkout" which downloads just the last revision
[00:42] <lifeless> jelmer: hai
[00:44] <jelmer> lifeless, hellø
[00:45] <lifeless> https://code.edge.launchpad.net/~lifeless/subunit/nopassthrough/+merge/9557
[00:46] <jelmer> lifeless, any reason for the two spaces of indentation on line 50 and 51 in the diff?
[00:47] <lifeless> editor fail
[00:47] <lifeless> will fix
[01:13] <jelmer> lifeless, why does launchpad add "(community)" behind jml's name and mine in the reviewer field?
[01:14] <lifeless> I don't know
[01:14] <lifeless> there is a bug open about it, that I filed.
[01:15] <lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/400950
[01:33] <lifeless> lol. re fail :(
[01:33] <lifeless>   File "/usr/lib/python2.6/sre_compile.py", line 517, in compile
[01:33] <lifeless>     "sorry, but this version only supports 100 named groups"
[01:33] <lifeless> AssertionError: sorry, but this version only supports 100 named groups
[01:35] <thumper> lifeless: what are you trying to do?
[01:36] <lifeless> thumper: just test combination
[01:36] <lifeless> I suspect a shallow bug in command line aggregation
[01:36] <lifeless> I'll look at it later
[01:36] <thumper> jelmer: it seems there is a small bug somewhere in the community identificaiton code ...
[01:36] <thumper> jelmer: we are looking into it
[01:37] <thumper> lifeless: do you know much about StringIO and unicode?
[01:37] <lifeless> sadly yes
[01:37] <thumper> should it be avoided?
[01:37] <jelmer> thumper, what is community supposed to be though? Would it be used to identify people who don't have voting rights?
[01:38] <lifeless> thumper: its ok some of the time, but it doesn't have clearly (or consistently!) defined semantics.
[01:38] <thumper> jelmer: it is more to indicate that while they may provide a review, it doesn't yet hold the weight of a real reviewer
[01:38] <thumper> lifeless: it should be well defined
[01:38] <lifeless> thumper: if you want a bytestream, which is what python 2.x files are meant to be, its a bad bad bad idea to write unicode to the input side
[01:38] <thumper> I know what it should be
[01:38] <lifeless> thumper: its not; StringIO and cStringIO, which are meant to be identical, behave differently.
[01:39] <thumper> ew
[01:39] <lifeless> thumper: I'm sure it seems well defined though :)
[01:39] <spiv> thumper: (c)StringIO is meant to emulate a file, which is meant to contain bytes.  So, feed it bytes (str) not unicode, or else unexpected crap happens.
[01:39] <thumper> spiv: ok, ta
[01:39] <lifeless> thumper: in py3 there are defined semantics for layering strings down to bytes and back
[01:39] <thumper> spiv: I'll reject my reviewers suggestion then :)
[01:40] <spiv> Use CodecReader/Writer (or whatever they are called) wrapped around a StringIO, if you like.
[01:40] <lifeless> thumper: what did they suggest?
[01:40] <thumper> I'm using text.splitlines()[:max_lines] -> testlines = islice(StringIO(text), max_lines)
[01:41] <poolie> hello thumper, lifeless
[01:41] <lifeless> hi poolie
[01:41] <thumper> hi poolie
[01:41] <poolie> thumper: any chance launchpad could stop flattening whitespace in code review comments? :)
[01:41] <thumper> what?
[01:42] <thumper> poolie: ref plz
[01:42] <lifeless> thumper: uhm, islice(text.splitlines(), maxlines)
[01:42] <lifeless> thumper: is ~=
[01:42] <lifeless> also
[01:42] <thumper> poolie: someone must have changed it
[01:42] <spiv> thumper: yeah, that seems pretty dubious to me.  splitlines really could use a maxsplit argument, like split.
[01:42] <lifeless> thumper: also
[01:42] <spiv> lifeless: I assume the point is to avoid a second copy of the (large?) string in memory
[01:43] <lifeless> islice(bzrlib.osutils.chunks_to_lines([text]), maxlines)
[01:43] <poolie> thumper:look at eg john's comments in https://code.edge.launchpad.net/~mkbosmans/bzr/topo_sort/+merge/9532
[01:43] <spiv> thumper: or just use split('\n', max_lines)
[01:43] <poolie> it's like it was specifically designed by someone who hates python
[01:43] <lifeless> ^ that is about the most efficient, if you need to deal with large strings/are doing this a lot
[01:43] <thumper> spiv: that doesn't discard the rest though does it?
[01:43] <poolie> the problem occurs when you copy and paste from the review diff
[01:43]  * lifeless repeats
[01:43] <spiv> thumper: yeah, I guess not.
[01:43] <lifeless> islice(bzrlib.osutils.chunks_to_lines([text]), maxlines) <- use that
[01:44] <thumper> poolie: they don't look flattened to me...
[01:44] <lifeless> thumper: its python, your text isn't getting freed anyway
[01:44] <lifeless> oh, the other thing you could do is use a buffer object
[01:44] <lifeless> but really, at that point, I'd rather write C
[01:44] <thumper> lifeless: what do you mean the text isn't getting freed?
[01:45] <spiv> lifeless: right, scan ahead for the nth \n, make a buffer object, splitlines that.
[01:45] <lifeless> text.splitlines() is your big slab of text, its going to be kept in memory until you're done with the last handle to it
[01:45] <lifeless> spiv: not quite, N buffer objects
[01:45] <lifeless> splitlines will allocate
[01:46] <lifeless> depends on parameters thumper hasn't shared about object lifetime
[01:46] <spiv> lifeless: depends on you are worried about, I guess
[01:46] <lifeless> ^ great minds
[01:46] <spiv> lifeless: I'm thinking of say 100M of text after max_lines that you don't care about (and certainly don't want a 2nd in-memory copy of)
[01:46] <thumper> I don't care that much I guess
[01:46] <thumper> at most will have 512k
[01:47] <spiv> thumper: I see poolie's problem; it's in the code lines John's quoted from the review diff, not the new code he's suggested in the comment.
[01:47] <lifeless> spiv: I was thinking of 20K lines and a little noise after :)
[01:47] <spiv> thumper: e.g. the first four lines of that comment
[01:47] <spiv> lifeless: :)
[01:47] <lifeless> thumper: can you give us a quick english description of the problem
[01:47] <thumper> gotcha
[01:48] <thumper> it is actually the tal formatter that formats the diff
[01:48] <thumper> I get a (maybe unicode) string
[01:48] <spiv> lifeless: Well, I'm guessing from the "max_lines" value that limiting the amount of data handled is the concern.  It would be good not to guess :)
[01:48] <thumper> to break up and make pretty
[01:48] <thumper> yes, I want at most a configurable number of lines
[01:48] <lifeless> ok
[01:49] <lifeless> so, here's what I'd do
[01:49] <lifeless> I'd first pass the string through some coerce_to_unicode thing
[01:49] <lifeless> noting that diffs from bzr can be in any encoding
[01:49] <thumper> lifeless: like unicode(text)
[01:49] <lifeless> and that different files can be different
[01:49] <lifeless> thumper: like that, but that will fail.
[01:50] <lifeless> thumper: there are heuristics things around in lp for this already.
[01:50] <lifeless> in exceptional cases, parts of the diff are in two different encodings
[01:50] <thumper> lifeless: we have code that attempts to decode the actual diff elsewhere
[01:50] <lifeless> consider when someone reencodes a NEWS file from cp-1280 to utf8
[01:50] <lifeless> (this is real, people do it it Debian.Changelog)
[01:50] <thumper> yes we know there are edge cases
[01:50] <lifeless> ok
[01:50] <spiv> thumper: that's just an implicit spelling of text.decode('ascii') (unless you've done evil things to your python runtime, like "import gtk"...)
[01:51] <lifeless> well, I'd get it to a known state, either all bytes, or all unicode
[01:53] <lifeless> then then loop on re.finditer(r'\r|\n', re.MULTILINE) to get the position
[01:53] <lifeless> finally, bzrlib.osutils.chunks_to_lines([buffer(text, 0, pos)])
[01:54] <lifeless> we may need to bugfix that to deal with buffer objects, but its the right conceptual function for stashing that in.
[01:54] <thumper> interesting
[01:54] <thumper> overkill for me now, but interesting
[01:54] <lifeless> I thinl its overkill too
[01:54] <lifeless> I think diffs will either be fine to deal with naively
[01:54] <lifeless> or so big that the first text is already killing you
[01:55] <lifeless> so actually limiting needs to be pushed down the stack.
[01:56] <lifeless> alternatively, loop on
[01:56] <lifeless> re.finditer(r'.*\r|\n', re.MULTILINE)
[01:57] <lifeless> for match in islice(re.finditer(r'.*(\r|\n)', re.MULTILINE), max_lines):
[02:01] <spiv> poolie: btw, that case I was worried about turns out to be a non-issue; it's already handled correctly.
[02:06] <lifeless> thumper: actually, the re one is worth testing, it may well be the bomb
[02:07] <thumper> :)
[02:12] <poolie> spiv: way to go
[02:13] <spiv> ...and it's beating IDS for wall clock time on fetch from 1.9 -> 2a over HPSS.
[02:13] <igc> morning
[02:14] <spiv> For bzr.dev -r2000, anyway.  It'll be interesting to see how mysql goes.
[02:15] <jelmer> hi Ian
[02:15] <jelmer> moin Andrew
[02:16] <spiv> jelmer: hola
[02:20] <lifeless> spiv: \o/
[02:21] <lifeless> igc: did you get a chance to take commit for a spin?
[02:21] <igc> lifeless: not yet - will do so today
[02:23] <lifeless> ok
[02:28] <krisives> Hey, anyone here familiar with the FTP transport code in bzr?
[02:28] <lifeless> somewhat
[02:29] <lifeless> its mainly a thin veneer around ftplib
[02:29] <lifeless> if I am remembering correctly
[02:29] <krisives> Someone was having problems with CHMOD not being allowed on their Windows-based FTP server for their host, but from what I read in the code it just warns if CHMOD fails
[02:29] <lifeless> perhaps the server is giving a fatal failure?
[02:30] <krisives> Not sure, but I am correct that it should just generate warnings and still push (for example) ?
[02:30] <krisives> It also seems to have problems pushing because it keeps the branch lock open :(
[02:31] <lifeless> we catch ftplib.error_perm
[02:31] <lifeless> its probably returning a different error code
[02:31] <lifeless> the intent is to warn and continue
[02:31] <krisives> Well, the error string for that catch is what's being output
[02:31] <lifeless> oh, if its outputting the string then its being caught ok
[02:31] <krisives> I suspect that the FTP is killing the connection at sometime, which would leave the branch locked
[02:32] <lifeless> that sounds plausible too
[02:32] <krisives> If that happens, what does bzr do?
[02:32] <krisives> Does it try every X seconds?
[02:32] <lifeless> if the branch is locked when we try to lock it, yes we spin for a while
[02:32] <lifeless> if the connection is broken leaving a stale lock, the 'bzr break-lock' command can be used to manually break the lock
[02:33] <krisives> Indeed, but his FTP is just too borked I think
[02:33] <krisives> To sync just 1 file it drops the connections so much that you can't realistically break the lock and push, you'd be doing it every few seconds
[02:34] <lifeless> ouch
[02:34] <lifeless> I need to go eat; perhaps you or he could file a bug?
[02:34] <lifeless> we can see if we can improve things - though it may not be feasible
[02:34] <krisives> I believe he is, but honestly I think it's just the FTP being fudge
[02:34] <krisives> Unacceptable for an FTP to not have CHMOD IMO
[02:35] <lifeless> I don't know that its chmod causing the problem
[02:35] <krisives> Thanks for your help :)
[02:35] <lifeless> it may be incidental
[02:35] <krisives> I agree
[02:35] <lifeless> ciao
[02:35] <krisives> Either way his FTP is the real issue here
[03:36] <lifeless> vila: I'm going to look at the test suite this afternoon
[03:36] <lifeless> I've got my check branch passing again
[03:37] <lifeless> poolie: do you want to do an incremental review? The changes were all shallow - tests calling branch.check() rather than check_dwim on the branch path (which is the public API according to our docs)
[03:52] <spiv> lifeless: speaking of reviews, inventory-delta is up for review again.
[03:52] <spiv> lifeless: it uses a separate substream now and is generally looking fairly shiny I think.
[03:52] <lifeless> awesomeness
[03:52] <lifeless> what did you do about the parents issue
[03:54] <spiv> It transmits them on the FulltextContentFactory.
[03:54] <lifeless> cool
[03:54] <spiv> Actually, this is effectively unchanged from the previous interation, I'm pretty sure despite John's comments it was sending them before, too.
[03:54] <lifeless> :P
[03:55] <spiv> Anyway, if it's wrong, then a test should fail  :P
[03:55] <spiv> But I'm pretty sure this is doing the conservative thing.
[03:57] <spiv> Next up is more interactive testing and maybe see if I can do a cheap hack to do something about the "inserting a stream into 2a causes massive bloat until the final autopack" issue.
[03:57]  * igc lunch
[03:57] <spiv> But first, lunch.
[03:57] <spiv> igc is a trendsetter :)
[03:57]  * spiv -> lunch.
[05:16] <poolie> lifeless: hi i'm back
[05:16] <poolie> lifeless: want to read spiv's thing?
[05:22] <poolie> igc, we should chat about the web site sometime, if you're up
[05:24] <igc> poolie: sure. I'm back from lunch now. I'm feeling rather washed out today but discussing websites is well within my mental ability nevertheless :-)
[05:24] <poolie> igc :) how about now?
[05:24] <igc> poolie: np
[05:25] <thumper> poolie: wouldn't mind a chat some time
[06:53] <poolie> hi thumper
[06:54] <poolie> omg death by telephone
[06:54] <lifeless> mtaylor: ask thumper; here.
[06:54] <poolie> lifeless: i forget, did you want me to reread your check-1 branch?
[06:56] <mtaylor> thumper: is it possible to use boost::format without using the % operator?
[06:56] <lifeless> poolie: its up to you
[06:56] <lifeless> 12:36 < lifeless> I've got my check branch passing again
[06:56] <lifeless> 12:37 < lifeless> poolie: do you want to do an incremental review? The changes were all shallow - tests calling branch.check() rather than check_dwim on the branch path (which is the public API according to our
[06:56] <lifeless>                   docs)
[06:57] <poolie> that's https://code.edge.launchpad.net/~lifeless/bzr/check-1/+merge/7489 ?
[06:58] <poolie> if you want to use the Trivial Button, use it.
[06:59] <lifeless> I'll send it to pqm now then
[07:13] <poolie> lifeless, i'm working up towards doing that subunit-filter feature myself...
[07:13] <lifeless> cool
[07:14] <lifeless> I've been thinking about the problem of multiple outcomes for tests
[07:14] <lifeless> I think its a 2d squashed into 1d problem
[07:14] <lifeless> erm, not multiple events per fixture, but addSuccess vs AddFailure vs addSkip etc
[07:14] <lifeless> I might mail TIP about it actually
[07:20] <poolie> meaning it should be more like addResult('success')?
[07:21] <lifeless> I think there are multiple dimensions:
[07:21] <lifeless>  - ran | did not run (reason)
[07:21] <lifeless>  - failed (details)
[07:22] <lifeless> I'm exploring the concept at the moment
[07:22] <lifeless> its not mature
[07:22] <lifeless> not all coordinates make sense
[07:23] <lifeless> didn't run, failed   is an interesting one to consider - MissingDependency might be that case
[07:23] <lifeless> basically I think the that list can't ever be complete the way its tackle at the moment
[07:23] <lifeless> and that provokes ugliness/continual growth in the API
[07:23] <vila> hi all !
[07:24] <lifeless> hi vila
[07:24] <poolie> agree
[07:24] <lifeless> vila: I haven't fixed it yet
[07:25] <poolie> it may be more cleaner to add some kind of object to which you can then add attributes and dimensions
[07:25] <poolie> hi vila
[07:25] <vila> lifeless: just reading your last comment, you're on on the right design track though :-)
[07:26] <lifeless> thanks
[07:26] <lifeless> vila: so, for --parallel
[07:27] <lifeless> I think special casing the counting decorator to be applied before the parallel one, would be reasonable.
[07:27] <lifeless> or something
[07:27] <lifeless> long term I want to fix the driving problem about status info
[07:27] <lifeless> push that down to subunit and up to python upstream
[07:28] <lifeless> first though, its EOD for me, and I'm off to think/tweak nested progress in  subunit
[07:29] <vila> lifeless: ok, short term I just disabled --parallel=fork in the test farm, but 1) it's a shame, 2) I still need it :)
[07:29] <poolie> lifeless: how am i meant to invoke the subunit test suite?
[07:30] <lifeless> poolie: make check / make distcheck
[07:31] <bialix> vila: hi
[07:32] <vila> bialix: hi, wow, already up ? :)
[07:33] <bialix> yep, I'm in +2 TZ
[07:33] <bialix> vila: bzr pull http://bzr.dev hang
[07:33] <bialix> http://pastebin.com/m757ed464
[07:33] <vila> bialix: hehe, I know, but you generally come later
[07:34] <bialix> is it bug or this is my network ?
[07:34] <bialix> vila: :-P
[07:35] <vila> bialix: from what I can see, it should be your network, try with -Dhttp maybe ?
[07:35] <bialix> I've surprised by  25 bytes left message
[07:36] <bialix> our ADSL is so flaky :-/
[07:37] <emmajane> poolie, beuno, igc: incoming email, although I'm outgoing for sleep. :)
[07:37] <vila> well, it smells a bit but not enough to trigger a deep debug session so far, I've seen it in other reports though so I'm aware that something strange is going on here
[07:37] <igc> hi emmajane
[07:37] <vila> emmajane: hi !
[07:37] <vila> emmajane: good to see you around :)
[07:37] <igc> emmajane: sorry I've missed you on irc recently - haven't been around much these last 10 days
[07:38] <bialix> what it means: lock cannot be broken? http://pastebin.com/m3a7d4d30
[07:38] <emmajane> igc, not to mention yo'ure in the wrong time zone for me. :)
[07:38] <emmajane> (it's nearly 3AM here)
[07:38] <igc> emmajane: may be we can catch up some time later this week
[07:38] <emmajane> igc, that'd be good!
[07:38] <poolie> bialix: probably something holding the os lock (must die)
[07:39] <poolie> there should be a traceback in bzr.log
[07:39] <vila> bialix: isn't it OS lock realted (which must die ?)
[07:39] <vila> rats
[07:39] <poolie> jinx :)
[07:39] <emmajane> vila, ps HAI :)
[07:39] <bialix> rats
[07:39] <emmajane> ok. sleep time now.
[07:39] <vila> HAI ?
[07:39] <poolie> lifeless: (lazy) how is subunit meant to treat xfail in its tests?
[07:39] <poolie> sleep well
[07:39] <emmajane> vila, "hi" in lolspeak.
[07:39] <emmajane> poolie, thanks. :)
[07:40] <vila> emmajane: :)
[07:40] <poolie> lifeless: nm
[07:40] <lifeless> poolie: it doesn't have any xfail tests at the moment :)
[07:40]  * emmajane clearly needs sleep :)
[07:40] <igc> night
[07:40] <lifeless> poolie: it has tests /of/ xfail
[07:40] <poolie> it folds it to success, it seems?
[07:41] <igc> emmajane: yep, certainly wrong timezone but I'm often around in my early morning as well so I'm sure we'll catch up soon enough :-)
[07:43] <lifeless> poolie: ah yes.
[07:43] <lifeless> poolie: 2.7 has an addExpectedFailure now, I haven't adjusted subunit to use that yet, is all.
[07:43] <bialix> vila: -Dhttp does not reveal anything and pull has finished successfully
[07:43] <bialix> but OSLMD definitely
[07:44] <vila> OSLMD ?
[07:44] <igc> hi bialix!
[07:44] <bialix> invented today: OS Locks Must Die!
[07:44] <bialix> hi igc
[07:44]  * vila wonders where he lost his acronym deciphering capabilities...
[07:44] <vila> OSLMD !!! Of course !
[07:44] <bialix> LOL
[07:45] <bialix> igc: today will do review of pending merges in qbzr, after noon in my TZ
[07:45] <poolie> lifeless: this seems to mean it loses the KnownFailure exception details :/
[07:46] <igc> bialix: excellent. thanks
[07:46] <lifeless> poolie: thats a shallow bug now that python has a defined contract
[07:46] <bialix> but today morning I'm thinking about your mail. Why quncommit is so important for you?
[07:47] <bialix> igc: ^
[07:50] <lifeless> poolie: I'm filing a bug on the xfail squash
[07:50] <poolie> i did already
[07:50] <poolie> bug 409193
[07:50] <lifeless> oh, thanks
[07:51] <poolie> also bug 409191
[07:51] <poolie> not very related
[07:51] <poolie> but would be cool with many failures
[07:51] <lifeless> lp indeed
[07:51] <lifeless> bah typo
[07:51] <lifeless> indeed
[07:51] <lifeless> back shortly
[07:56] <igc> bialix: it's not to me personally. But it is w.r.t. menu options I'd want to explain in a manual for explorer say
[07:58] <igc> bialix: scanning over the user guide and 'translating' the tasks to gui actions (instead of bzr commands), we need ...
[07:58] <bialix> I mean: I don't think this is main operation
[07:58] <bialix> ah
[07:58] <igc> bialix: (1) easy importing & (2) being able to undo mistakes
[07:59] <bialix> easy importing?
[07:59] <poolie> emmajane: really nice mail :)
[08:00] <igc> bialix: I personally care more about shelve for example, than uncommit, but most new users will screw up a commit message more often than want to shelve ;-)
[08:01] <bialix> shelve (shelve2) does not work for me, so
[08:01] <igc> bialix: "I have a tree of files - put it under version control for me"
[08:01] <bialix> ok, I've grok your pounti
[08:01] <bialix> ok, I've grok your point
[08:01] <bialix> qimport?
[08:02] <bialix> is not import command still the part of bzrtools>?
[08:06] <poolie> baz-import is, i think
[08:06] <poolie> plain import i think has always been built in?
[08:06] <lifeless> import is in core I'm fairly sure
[08:07] <poolie> lifeless: there are no blackbox tests iiuc?
[08:07] <bialix> bzr help import said: From:     plugin "bzrtools"
[08:07] <bialix> :-P
[08:07] <lifeless> none!
[08:08] <poolie> woo, freedom!
[08:11] <poolie> well that obviously works
[08:11] <poolie> why do people bother writing tests?
[08:12] <lifeless> poolie: so, I'll probably add something approximating blackbox tests at some point in the future
[08:15] <lifeless> poolie: for now, I do TDD for all the core code
[08:15] <poolie> sure
[08:15] <lifeless> and treat UI validation as a shallow release task
[08:15] <poolie> i'm not complaining, i'm just checking i don't miss it
[08:15] <lifeless> :)
[08:15] <poolie> i mean i'm changing it and i don't want to submit without tests
[08:16] <lifeless> thats fine
[08:24] <poolie> done- https://code.edge.launchpad.net/~mbp/subunit/408821-filter-re/+merge/9680
[08:31] <poolie> spiv, how's the inventory delta patch? did it turn out it's ok to go?
[08:31] <poolie> ooh this is very nice
[08:32] <lifeless> err might not be a string
[08:32] <lifeless> it seems like a bug there
[08:32] <lifeless> but otherwise nice
[08:32] <poolie> i was only assuming it could be cast to a string
[08:33] <poolie> or i only meant to
[08:33] <mdke> lifeless: I am now
[08:33] <mdke> lifeless: just trying this fast-export thing at the moment
[08:38] <mdke> ok, I've run the export and piped it to a file
[08:40] <mdke> let's see now
[08:44] <mdke> an error - http://paste.ubuntu.com/247816/
[08:48] <mdke> lifeless: if you have any ideas, give me a shout - I'm off to work now but will pick up hilights. Thanks in advance!
[08:55] <lifeless> a bug in fast-export, or a broken stream
[08:55] <lifeless> file a bug
[09:12]  * igc dinner
[09:12] <poolie> vila, lifeless, i think i'll call it a night
[09:12] <poolie> bye
[09:12] <lifeless> ciao
[09:12] <lifeless> I'm reviewing atm
[09:12] <vila> poolie: bye
[09:13] <poolie> i wonder how spiv's patch went?
[09:19] <lifeless> poolie: reviewed
[09:19] <poolie> the subunit thing?
[09:19] <lifeless> I think its nice, but improvable
[09:19] <lifeless> yes
[09:20] <lifeless> oh, missed a bit
[09:20] <lifeless> I don't think the predicate should be public on the filter
[09:20] <lifeless> it would be odd for someone else to be calling it
[09:21] <poolie> i thought they might want to chain on it
[09:22] <lifeless> you mean replace it after construction?
[09:22] <poolie> yes
[09:22] <lifeless> mmmm, I think I'd rather have a list of predicates for that, in the object.
[09:23] <lifeless> its also a bit yagni, as I strongly suspect these filters are build-and-execute, not build-edit-execute
[09:23] <poolie> did you comment on the mp?
[09:23] <lifeless> yes
[09:23] <poolie> i'll make it private
[09:23] <lifeless> bunch of mostly shallow stuff
[09:23] <lifeless> it looks really nice as a feature
[09:23] <poolie> oh, now you did
[09:25] <poolie> how can it hit on None?
[09:26] <lifeless> perhaps not from the command line
[09:27] <lifeless> but addSkip(test, None) is something people might call
[09:28] <lifeless> its possible I'm overthinking it
[09:31] <lifeless> k, well I'm going to head for a bit
[09:31] <lifeless> I'll tackle progress later
[12:38]  * bialix works on qbzr
[12:46] <spiv> poolie: I resubmitted the inventory-delta patch for review; didn't Launchpad send you mail about it?
[12:46] <poolie> oh hi spiv
[12:46] <poolie> i saw there was a new review from about 5h ago
[12:46] <poolie> i didn't review it myself though :/
[12:47] <poolie> maybe john will
[12:55] <Tak> am I doing something wrong, or is push being strict by default supposed to be super-annoying? :-P
[12:59] <bialix> hehe
[12:59] <bialix> you can set push_strict = False in bazaar.conf to disable this
[13:03] <Tak> ah, nice
[13:03] <bialix> nice?
[13:04] <Tak> it's nice that I can disable that in the preferences
[13:04] <vila> Tak: when do you encounter it ?
[13:04] <bialix> with qpush you've got yes/no dialog
[13:05] <bialix> vila: sometimes it's perfectly legal situation to push finished job and get unfinished changes in the tree :-P
[13:05] <Tak> vila: when I have uncommitted local changes
[13:06] <vila> bialix: I know it's perfectly legal, I'd like to better understand why and when people encounter it
[13:06] <Tak> ah
[13:06] <Noldorin> krisives: ping?
[13:06] <vila> Tak: but why did you want to push anyway ?
[13:06] <krisives> Knee deep in CSS :(
[13:06] <Tak> when working with an ide like monodevelop, it makes a lot of trivial changes to project files (reordering elements, etc) that I don't want to commit
[13:06] <Noldorin> krisives: hehe, lucky you
[13:06]  * bialix push anyway to publish his finished work for other people
[13:06] <Noldorin> krisives: i'll catch you later maybe?
[13:07] <Tak> so I generally commit source changes only, then push
[13:07] <vila> Tak: I see
[13:07] <vila> bialix: I see too :)
[13:08] <krisives> I'm around just kinda in the background
[13:08] <krisives> Feel free to ask anything, but I will probably be a while
[13:08] <bialix> (vila has a good eyesight!)
[13:08] <Tak> there are other times when I'm halfway through a bugfix or something, but I want to push previously committed changes because I'm going to goto lunch, go home, etc.
[13:09] <vila> Tak, bialix : both of you are aware of the consequences, push_strict is for newbies that may not realize *what* they are/aren't pushing
[13:09]  * bialix sighs
[13:10] <vila> it's a bit unfortunate we realize that so late, but I really think the default should be strict, as Tak said, adding a push_strict = False in bazaar.conf is not a lot to ask to power users
[13:10] <bialix> yep
[13:10] <luks> should the default UI be really targetted at people who don't know how to use it?
[13:12] <vila> luks: ???
[13:12] <bialix> vila: well, with qpush I don't need to set push_strict
[13:12] <vila> luks: that sounds obvious, how can you learn it otherwise ?
[13:12] <Tak> luks: yes.
[13:12] <luks> vila: by reading the manual
[13:12] <vila> luks: mwhahahaha
[13:13] <bialix> lol
[13:13] <luks> Tak: it's the "Mr .Clippy" issue
[13:13] <Tak> vila: I'm ok with the config option
[13:13] <luks> Tak: you don't want the program watching you and tell you what are doing wrong
[13:13] <vila> Tak: note that you can put it in any config file (bazaar.conf, locations.conf, branch.conf) to restrict its scope
[13:14] <Tak> of course, I disable spellcheck in all my applications
[13:14] <Tak> but on the same token, I appreciate that spellcheck is on for other people
[13:14] <Tak> because then I don't have to stab them as much
[13:14] <luks> spellcheck that warns and spellcheck that doesn't allow you to save incorrectly spelled words are different
[13:15] <luks> this is the later case
[13:15] <vila> luks: novice can't be required to activate a novice mode, power users will feel obvious to desactivate a novice mode
[13:15] <luks> I wouldn't mind a message, or even a question
[13:15] <Tak> there is a message: "Use --no-strict to override."
[13:15] <vila> warning are ignored, questions are even more annoying in CLI !
[13:15] <Tak> maybe the config option should be mentioned in the message, though
[13:15] <luks> vila: so take the first --no-strict as a step from novice to advanced mode
[13:16]  * Tak agree @ CLI questions
[13:16] <luks> vila: well, I find the need to run the command again even more annoying
[13:16] <vila> luks: yup, I think the missing bit is a hint that --no-strict can be set in config files
[13:17] <vila> luks: you should do that only once, learn about the config variable, think about it, set it, forget the problem
[13:18] <vila> by contrast, if it's off, the novice will suffer before he understand why his changes weren't pushed !!! Where are they ? Are they lost ?
[13:18] <luks> vila: now we only need support for `bzr config push_strict False` :)
[13:18] <vila> luks: good point !
[13:20] <bialix> luks: can I ask about Qt? What is QStyle?
[13:20] <luks> bialix: class that draws widgets
[13:20] <bialix> I can use default instance of QStyle?
[13:20] <luks> well, QStyle is an abstract class
[13:21] <luks> where do you need it?
[13:21] <bialix> one sec
[13:21] <luks> every widget has a style instance associated with it
[13:21] <luks> you can use widget.style()
[13:21] <bialix> luks: see http://pastebin.com/m7ae00e28
[13:21] <bialix> luks: Gary use parent=None here but does not provide default style and this code failed in tests
[13:22] <luks> bialix: use QtGui.QApplication.instance().style()
[13:22] <bialix> can I just use style = QStyle() here is parent is None?
[13:22] <luks> at least I think that's the right name
[13:22] <bialix> ok
[13:22] <luks> QStyle() would be wrong
[13:22] <bialix> ok
[13:23]  * bialix trying
[13:25] <bialix> luks: it does not help
[13:25] <luks> hm, why not?
[13:25] <bialix> because QtGui.QApplication.instance() is None when I'm running tests
[13:26] <luks> ah
[13:26] <luks> you can't work that around that
[13:26] <luks> the icon loading will have to be moved outside of the model
[13:26] <bialix> all I need actually is style.standardIcon
[13:27] <bialix> hmm, but IIUC model should provides these icons
[13:28] <luks> but they depend on the widget style
[13:29] <luks> what are the tests doing with the model?
[13:29] <luks> if they are not asking for the icons, you can move the code and load them lazily
[13:30] <bialix>         model = TreeModel(None)
[13:30] <bialix>         modeltest = ModelTest(model, None)
[13:30] <bialix>         
[13:30] <bialix>         model.set_tree(tree, tree.branch)
[13:30] <bialix> ^ it was tests
[13:30] <luks> hm
[13:30] <luks> I don't know what ModelTest does, but I guess it does lots of things
[13:30] <bialix> I'm about mark this test as KnownFailure for 0.13
[13:31] <luks> so the best solution is probably to load the icons elsewhere and pass it to the model
[13:31] <luks> and pass empty icons from the test
[13:32] <luks> or even check if parent is None and just create empty icons in the model
[13:32] <luks> hacky, but should do the work
[13:32] <bialix> empty icons sounds good
[13:34] <bialix> luks: empty icons (aka QtGui.QIcon()) did the trick, thanks
[13:35] <krisives> How can I get a changelog?
[13:36] <luks> krisives: bzr log?
[13:36] <luks> or bzr qlog if you want something cooler :)
[13:36] <krisives> <-- dumb
[13:37] <bialix> luks: it seems Gary did the wrong thing with this model
[13:38] <bialix> luks: TreeModel is subclass of QtCore.QAbstractItemModel, the latter can have parent in constructor as instance of QModelIndex and the latter does not have style()
[13:57] <krisives> How can I get bzr log to only output changes?
[13:58] <krisives> (Not dates, file names, etc.)
[14:15] <Noldorin> krisives: you still busy?
[14:15] <krisives> Sadly so
[14:16] <Noldorin> krisives: ok no worries
[14:16] <krisives> What it do/
[14:16] <Noldorin> CHMOD is not something that does not work just on our Windows servers, it
[14:16] <Noldorin> does not work on any Windows servers. CHMOD is supported at present only by
[14:16] <Noldorin> the Linux operating system.
[14:16] <Noldorin> that's what my web host replied
[14:19] <krisives> LOL
[14:20] <krisives> Well, many FTP servers emulate the permission model, and some use NTFS correctly to do some primitive permissions
[14:20] <bialix> luks: still around?
[14:20] <Noldorin> krisives: so that's basically rubbish, isn' it?
[14:20] <krisives> I would say so
[14:20] <LarstiQ> Noldorin: imnsho, utter rubbish
[14:21] <LarstiQ> Noldorin: there are ftp servers which don't use the OS filesystem as a backing store but a database for example
[14:21] <Noldorin> LarstiQ: yeah, exactly what i thought
[14:21] <krisives> A quick search reveals many of them
[14:21] <krisives> http://www.xlightftpd.com/
[14:21] <krisives> was the first Windows-based result I found
[14:22] <Noldorin> and if the file system is NTFS, CHMOD should work with no problem
[14:22] <krisives> I've found the best way to "communicate" things to companies is to just politely tell them "Ok, thanks. I would like to cancel my business with you."
[14:23] <krisives> Person on the phone will take it as a personal insult...
[14:23] <the-erm> I have an account on launchpad.net, and I want to add another user who can edit/approve changes to a project.  How do you do that?  Do you have a url that explains it
[14:23] <krisives> And then you have to break down into 3rd grader mode and be like "Business is business... You can't provide the services I want, so I'm not interested"
[14:24] <LarstiQ> Noldorin: but I think we should be able to make bzr work without chmod
[14:24] <krisives> Anyone know how I can get bzr log to return all but the first revision?
[14:24] <Noldorin> LarstiQ: yes, thats is true
[14:24] <Noldorin> what is your latest suggestion?
[14:24] <Noldorin> to use mount a virtual directory for the FTP server?
[14:24] <krisives> LarstiQ: I did some testing and it's not isolated to CHMOD
[14:24] <LarstiQ> krisives: bzr log -r 2..-1
[14:24] <krisives> LarstiQ: Thanks!
[14:24] <krisives> His FTP just straight kills connections too from what I tested
[14:25] <LarstiQ> the-erm: the trick is to make the project owned by a team: https://help.launchpad.net/Teams
[14:25] <Noldorin> yeah
[14:25] <krisives> It would leave the branch lock while trying to sync a 1 file test repo
[14:25] <Noldorin> but i still don't understand why ...
[14:25] <LarstiQ> krisives: nice
[14:25] <LarstiQ> krisives, Noldorin: has a bug been filed?
[14:25] <vila> the-erm: try #launchpad instead, but overall, yes you can do that, and start reading at https://help.launchpad.net/
[14:25] <krisives> I actually put a return statement in _setmode to completely bypass CHMOD
[14:25] <krisives> Using a custom bzr checkout
[14:26] <vila> krisives: if you have control over the server ftp is really not the best option
[14:26] <Noldorin> LarstiQ: not yet
[14:26] <Noldorin> krisives: hmm, did you paste me your log after doing that?
[14:27] <Noldorin> LarstiQ: i thikn krisives understands the problem better than me :)
[14:28] <krisives> I had problems with nautilus with this FTP too
[14:29] <krisives> I've found that if nautilus gets made it's usually because of passive connections or something like that. What does bzr do in that regard?
[14:29] <vila> krisives: if you have to use ftp anyway bypassing _setmode shouldn't help because it isn't required anyway, that will make your log easier to read though
[14:29] <vila> krisives: use aftp: instead of ftp: if you need passive
[14:30] <vila> lol, no
[14:30] <vila> aftp is to force active, sorry
[14:31] <LarstiQ> vila: the server is not under our control
[14:31] <vila> so we are passive by default, use aftp to force active
[14:31] <vila> LarstiQ: ha, the hard case :)
[14:31] <LarstiQ> vila: yup
[14:32] <krisives> vila: I did that because I thought his server would get irritated with so many bad CHMOD attempts
[14:32] <vila> krisives: ha, good idea :)
[14:32] <LarstiQ> vila: it's a windows based ASP.NET hoster
[14:32] <krisives> vila: Does bzr use passive connections via FTP?
[14:32] <krisives> Yeah it's not mine either I'm just helping Noldorin
[14:33] <vila> krisives: yes, passive by default
[14:33] <krisives> vila: You can change it?!
[14:33] <Noldorin> hmm
[14:33] <vila> krisives: you can use active by saygin aftp:// instead of ftp://
[14:33] <krisives> If you can you might want to try that Noldorin. Like I said nautilus (file browser) uses passive connections and was exhibiting similar problems
[14:34] <krisives> vila: Sorry, it's late/early for me ;)
[14:34] <vila> krisives: no worries
[14:34] <Noldorin> krisives: what's the option for bzr?
[14:34] <krisives> It's a different protocol
[14:34] <krisives> Instead of "ftp://blah" it's "aftp://blah"
[14:34] <Noldorin> oh i misread.
[14:35] <Noldorin> thought you were just referring to an active connection
[14:35] <vila> no no, that should be me :)
[14:35] <krisives> Well, all I know is that there are two ways to connect to the FTP, and one way flat out doesn't work on your server
[14:35] <vila> Noldorin: ftp has two ... as krisives says :)
[14:35] <krisives> And I tested both ways because Filezilla worked fine, but others didn't work worth beans
[14:36] <krisives> That's probably the dumbest way to describe the whole thing, but it's 6:36 AM and I've been dealing with IE6 in a VM
[14:36] <LarstiQ> krisives: I know it's late/early for you, but if you could file a bug so we can start collobarting/tracking around that, that would be nice
[14:36] <vila> krisives: what kind of VM ?
[14:36] <LarstiQ> hmm, that's a fun way to spell collaborate
[14:36] <krisives> VirtualBox
[14:36] <vila> krisives: what type of network connection ?
[14:37] <vila> krisives: NAT, bridged ?
[14:37] <krisives> Not sure, I think it's NAT bridged
[14:37] <vila> krisives: what host OS ?
[14:37] <krisives> Could care less if the VM goes *poof*
[14:37] <krisives> Ubuntu 9.04
[14:37] <Noldorin> LarstiQ: that, that would be great if krisives could do it, who understands this problem better than me :)
[14:38] <krisives> Well, right now I don't know what I would file
[14:38] <vila> krisives: it's either NAT or bridged, nad NAT is severely limited in my experience
[14:38] <krisives> Well it works on both local and external network, and it has it's own IP i think
[14:38] <LarstiQ> krisives: ideally a way to reproduce it, the rest can be fleshed out later
[14:38] <krisives> I hate having to use `net use x: \\vboxsvr\blah` though, it should be in the Network Stuff area
[14:39] <Noldorin> krisives: have you tried aftp on my server?
[14:39] <LarstiQ> krisives: the important part is to have a flag in the ground to rally around
[14:39] <krisives> Good point
[14:39] <LarstiQ> krisives: just saying "it doesn't work with hoster X, herre is the traceback" would be a start
[14:39] <krisives> I don't have your FTP details + I am kinda busy at the momemnt
[14:39] <vila> krisives: if you use it as a client only NAT generally works flawlessly, if you try to use some servers or mount some NFS volumes and need to be authenticated by the NFS server... things become more complicated
[14:40] <krisives> I just use this as an exaggerated version of Wine lol
[14:40] <krisives> It runs IE6 and Photoshop
[14:40] <vila> krisives: NAT is enough then
[14:40] <krisives> Using Photoshop in Wine is suicide
[14:40] <Noldorin> krisives: i'll give them to again later if you fancy doing any more testing :)
[14:41] <vila> krisives: and will help stay away from the bad boys :)
[14:41] <krisives> It "works" but in reality it has so many quirks that any real PS user will be irritated to hell
[14:41] <krisives> Well, I guess I have to play the "I'm behind 3 routers" card
[14:41] <krisives> So it's good ol' security through obscurity on my home network sometimes
[14:41] <krisives> (joke)
[14:42] <vila> krisives: don't know what you're talking about (joke)
[14:42] <krisives> http://en.wikipedia.org/wiki/Security_through_obscurity for anyone lost
[14:43] <krisives> (actually lost)\
[14:43] <krisives> this is getting confusing lol
[14:44] <vila> STO requires that I don't talk about how I setup my home network :)
[14:45] <vila> funnily enough, http://www.virtualbox.org/wiki/Changelog says:
[14:45] <vila> # NAT: fixed passive ftp access to host server (bug #4427)
[14:45] <vila> sorry ubottu. not for you
[14:46] <vila> krisives: and that's for VirtualBox 3.0.4 (released 2009-08-04), I don't know if you are up-to-date
[14:50] <LarstiQ> kfogel: 1.17 could be uploaded, but maybe we want to wait
[14:51] <krisives> Sorry im back, had to make a corn dog
[14:51] <kfogel> LarstiQ: hey, thanks, was about to ping.  We would want to wait because... ?
[14:51] <krisives> The base of my office chair broke, so I just put it on top of 2 ATX towers for the mean time
[14:52] <LarstiQ> kfogel:  [REGRESSION] bzr 1.17 does not use _knit_load_data compiled extension
[14:53] <LarstiQ> kfogel: reading that thread, it may not be too serious
[14:53] <vila> LarstiQ: didn't spiv backport the patch ?
[14:54] <vila> LarstiQ: no, not really serious, I doubt knit is still widely used
[14:54] <LarstiQ> kfogel: I suppose you'll want to use 2a?
[14:54] <LarstiQ> vila: but a 1.17.1 point release has not been made, has it?
[14:55] <LarstiQ> kfogel: I think I'll just include the fix as a Debian local patch
[14:55] <vila> LarstiQ: no 1.17.1 AFAIK
[14:56] <kfogel> LarstiQ: this is to use 2a
[14:56] <LarstiQ> kfogel: right, then it wouldn't really matter for you
[14:56] <kfogel> LarstiQ: right
[15:03] <spiv> vila: I backported it to ~spiv/bzr/1.17, pqm didn't let me commit it to the 1.17 branch though.
[15:04] <LarstiQ> lp:~spiv/bzr/bzr-1.17 specifically
[15:04] <lamont> does 1.17 support any (well, commit in particular) hooks in the branch, or are they all still located only under $HOME ?
[15:05] <LarstiQ> lamont: code or configuration?
[15:06] <lamont> use case: whenever anyone does a commit in this (shared) branch, i want to run a script
[15:07] <lamont> last I saw, that required modifying files under $EVERYONE's home directory
[15:07] <lamont> though to be fair, haven't looked recently, for any value of "recent"
[15:07] <LarstiQ> lamont: that can be configured in .bzr/branch/branch.conf
[15:07] <LarstiQ> lamont: problem is, then you'll need to do that in each branch
[15:08] <LarstiQ> lamont: which especially with pushing new branches is a pain
[15:11] <spiv> LarstiQ: ta
[15:12] <vila> spiv: ha, thanks, I thought you did something, so it's in jml hands then ?
[15:12] <spiv> vila: well, jml is probably too busy with other things atm, I think.
[15:13] <spiv> I guess you could ask him :)
[15:13] <spiv> I'm not sure if there's really much enthusiasm for a 1.17.1 or not.
[15:13] <jml> what huh?
[15:13] <spiv> jml: :)
[15:13] <vila> LarstiQ: spiv told me you should ask jml :)
[15:13] <spiv> jml: there are some small patches that would possibly be worth cutting a 1.17.1 for.
[15:13] <LarstiQ> spiv: I'm branching now, going to have a look at the diff and apply it locally to the Debian packaging of 1.17
[15:14]  * LarstiQ wouldn't mind cutting a 1.17.1 if jml is too busy
[15:14] <lamont> LarstiQ: cool - is the particular config snippet trivially on a manpage somewhere?  and I gather that the rest of that means that it's not copied as part of push/pull/etc operations, but is local to the branch only?
[15:14] <LarstiQ> lamont: to answer the last question first, correct.
[15:14] <jml> LarstiQ, I am pretty busy right now, so that would be wonderful.
[15:15] <spiv> jml, LarstiQ: I think there were only 2 or 3 patches people suggested, check the list archives.
[15:15] <LarstiQ> lamont: the rest of the configuration is the same as otherwise, so post_commit_to = for the email plugin etc
[15:15] <vila> LarstiQ: Are you still sheperding bzr dogfooding 2a ?
[15:15] <LarstiQ> vila: yes, although I haven't actively shepherded lately, should get back to that
[15:16] <lamont> LarstiQ: ta
[15:19] <fullermd> If you're not actively shepherding, are you just flocking around?
[15:19]  * Tak rimshot
[15:19] <fullermd> Thank you, I'll be here all week.  Try the veal!
[15:19] <Tak> http://instantrimshot.com/
[15:29] <vila> jam, sidnei: ping
[15:29] <jam> greetings and welcome vila
[15:29] <sidnei> vila: aye
[15:30] <vila> what is missing to plug the buildbot ?
[15:30] <jam> hand of god?\
[15:30] <vila> god: ping
[15:31] <sidnei> time and goodwill?
[15:31] <jam> AFAIK, getting sidnei to put a buildbot.tac on kerguelen
[15:31] <jam> and getting someone to review my patch
[15:31] <jam> (which may have happened, I haven't gotten through all my mail this morning)
[15:31] <sidnei> and changing vila's master config to accept kerguelen and send the right instructions
[15:31] <sidnei> vila: just to confirm,  lp:bzr-buildbot-net is your master config?
[15:31] <vila> jam: no, not reviewed yet, I'd like to, but I'd really prefer to be able to test it first, see the trend ? :)
[15:32] <jam> vila: merge locally, "make installer-all"
[15:32] <jam> I don't really know how "make installer-all" will work into the buildbot setup
[15:32] <jam> but it at least is a manual bootstrap you can use
[15:32] <vila> sidnei: yes, merge your changes, setup a slave, publish a branch somewhere and I'll update my master
[15:33] <vila> jam: I still don't have a windows VM ! I want to use kerguelen for that
[15:33] <vila> jam: well, I want to use kerguelen as a reference point to configure my VM
[15:33] <sidnei> vila: awesome. i will work on that between now and tomorrow evening. there's a security release i need to get out tomorrow morning which is urgent.
[15:34] <vila> sidnei: ok, I'm waiting for your branch and a slave (we still need to sync about the ssh tunnel though)
[15:35] <jam> vila: rdesktop kerguelen; start cygwin, cd /home/shared/bzr/1.18-win32-buildbot; make installer-all
[15:35] <vila> jam: doh
[15:40] <sidnei> vila: i see you named slaves after the os. should i call thsi slave kerguelen or win2k3?
[15:42] <vila> sidnei: no hard rules so far, but preferably the later but I don't know any windows version called 2003 ???
[15:42] <sidnei> windows 2003? it's server-only, i think that's what kerguelen is using, or is it xp?
[15:43] <jam> sidnei: it is 2003 server edition 64-bit
[15:43] <sidnei> thats what i thought
[15:50] <vila> sidnei: yeah right, just saw that, so is that an NT variant ?
[15:51] <sidnei> vila: well, everything after 2000 is an NT variant, including Vista and XP?
[15:51] <bialix> I think so
[15:51] <vila> isn't vista more than a variant ?
[15:51] <vila> and windows7 less ?
[15:52] <vila> jam: no /home/shared for me
[15:52] <LarstiQ> vila: all NT
[15:52] <LarstiQ> vila: Windows ME was the last non-NT derivative
[15:52]  * LarstiQ doesn't know much about Windows 7 yet
[15:52] <jam> vila:  I'm sure cd /cygdrive/c/home/shared will work
[15:53] <jam> I'm not sure where that is mapped into the cygwin world
[15:53] <jam> (well, where *else* that is mapped in)
[15:53] <vila> jam: good enough
[15:53] <jam> I have a symlink from ~/dev => shared/...
[15:53] <sidnei> for completeness, Vista was based off the 2003 "R2" codebase, not XP
[15:54] <vila> jam: right and 1.18... is under bzr, finding my way :D
[15:54] <bialix> LarstiQ: IIRC Vista is 6.0 and Windows 7 is 6.1
[15:55] <spiv> jam: hey, thanks for offering to review inventory-deltas again.
[15:55] <jam> spiv: well I'd really like it to be good and land
[15:55] <LarstiQ> bialix: right, that makes sense
[15:55] <spiv> jam: I'd really like to be able to land it this time :)
[15:55] <jam> and then build bundles off of it
[15:55] <spiv> Right.
[15:56] <jam> spiv: well if the previous time had actually been sending deltas over the wire, I probably would have been more receptive :)
[15:56] <spiv> Also if it's going to make the next release it needs to land very soon :/
[15:56] <spiv> I'm *sure* I had been sending deltas at some point!  I guess not that version...
[15:59] <vila> jam: so, running make instaler-all raises permission denied
[15:59]  * vila pester rdesktop for not supporting copy/paste
[15:59] <jam> vila: silly Windows ACLs
[16:00] <jam> vila: on *my* machine I end up with a copy & paster service that makes it work
[16:00] <jam> but that is Windows Terminal Client
[16:00] <jam> vila: let me go check what groups are what
[16:00] <jam> it is certainly likely that "jameinel" is the sole owner of that dir
[16:01] <jam> (to date it hasn't mattered, because nobody else seems to do anything on that machine... :(
[16:01] <bialix> am I remember right that August 6 is the BIG RELEASE DAY?
[16:02] <bialix> it will be 2.0 or 1.18?
[16:02] <jam> bialix: rc1
[16:02] <jam> and given the open bugs for 2.0 it will probably be 1.18
[16:02] <jam> depends how this week goes
[16:02] <bialix> today is August 5, so...
[16:03] <bialix> ok, I'll release qbzr 0.13 in next few days for bundling into installer
[16:04]  * vila pester against non-resizable dialogs with scrollbars
[16:05] <bialix> vila ?
[16:05] <vila> bialix: not in qbzr !
[16:05] <vila> :D
[16:05] <bialix> ah, ok!
[16:05] <bialix> so I can off my qbzr hat
[16:05]  * bialix waves
[16:06] <vila> jam: build-win32 seems to lack write access for Users
[16:06] <jam> vila: probably
[16:07] <jam> I'm currently changing the owner of the whole "shared" folder
[16:07] <jam> but it is taking a while
[16:07] <jam> lots of files
[16:07] <vila> jam: can I remove it ? Or does it contain precious downloaded items ?
[16:07] <jam> vila: not precious in the sense that they won't be redownloaded
[16:07] <jam> but precious in the sense that it takes... 30min-1hr to download everything
[16:08] <vila> ok, I'll wait for the ACL change then
[16:10] <sidnei> vila: is the format of that branch 2a? i got a gnarly error
[16:11] <awilkins> vila: rdesktop supports clipboard
[16:11] <vila> sidnei: should be, what error do you get
[16:11] <sidnei> vila: http://paste.lisp.org/display/84828
[16:11] <sidnei> vila: i created a 1.9 shared repo, that's why
[16:13] <vila> sidnei: yes, you need to use the same format than the project if you want to stack
[16:14] <sidnei> vila: maybe the error message should say that *wink*
[16:15] <vila> sidnei: that *is* what it said *wink* :-D
[16:15] <sidnei> that's sad. no human would figure that out.
[16:15] <jam> vila: owner fixed
[16:15] <vila> sidnei: I know, that was a (bad) joke :-/
[16:17] <vila> jam: same problem, Users are still not able to write as they are for 1.18-win32-buildbot say
[16:17] <fullermd> Wow, I thought I liked bzr a half hour ago.
[16:17] <sidnei> got another nasty, not sure i need to do something about it
[16:17] <fullermd> But after fiddling with CVS again...
[16:17] <sidnei> sidnei@topia:~/canonical/bzr-buildbot-net/kerguelen-windows-installer$ bzr push lp:~sidnei/bzr-buildbot-net/kerguelen-windows-installer
[16:17] <sidnei> This transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~sidnei/bzr-buildbot-net/kerguelen-windows-installer/. See 'bzr help working-trees' for more information.
[16:17] <sidnei> Created new branch.
[16:17] <jam> sidnei: it is just a warning, and the push succeeded
[16:17] <jam> one of the side effects of when the target seems to already exist
[16:18] <LarstiQ> why o why does it mention the working tree if it is creating a new branch?
[16:18] <jam> LarstiQ: the dir already existed
[16:18] <jam> it is a current bug, I'm not sure how it comes about
[16:18] <vila> LarstiQ: because the branch can have a working tree and the WT will be updated if possible
[16:18] <LarstiQ> vila: note 'Created new branch'
[16:18] <fullermd> I think thta's a LPism, actually.
[16:18] <LarstiQ> jam: right
[16:19] <vila> LarstiQ: yeah, right, I didn't say the whole was coherent :)
[16:20] <jam> vila: ok, replacing permissions as well as owner to be 'recursively owner has full control'
[16:20] <jam> expect it to take another little while
[16:21] <LarstiQ> jam: would I have access to that host as well?
[16:21] <sidnei> vila: https://code.edge.launchpad.net/~sidnei/bzr-buildbot-net/kerguelen-windows-installer/+merge/9699
[16:22] <jam> LarstiQ: we can get you access if you want/need. I don't think you have an account there yet
[16:23] <LarstiQ> jam: I'll keep it in mind
[16:25] <vila> sidnei: Did I read it right that you desactivated all of my slaves ?
[16:25] <jelmer> LarstiQ: hi
[16:25] <sidnei> vila: not intentionally no, but let me double check
[16:25] <jelmer> LarstiQ: it looks like the repo on bzr.debian.org is broken, I'll push it agian from scratch
[16:25] <jam> vila: keep in mind that as you build a windows VM, it would be nice to have a "stock" windows install with nothing extra installed
[16:26] <jam> so that we can start it up, run the bzr installer, make sure it works, and then reset to scratch
[16:26] <sidnei> vila: maybe you missed this part "builderNames=[b["name"] for b in c["builders"]]"
[16:26] <vila> jam: that will be the test VM yes, separate from the dev VM
[16:26] <LarstiQ> jelmer: did you upgrade it to 2a?
[16:26] <vila> sidnei: could be
[16:27] <awilkins> What VM platform are you using?
[16:27] <jelmer> LarstiQ: I attempted to
[16:27] <jelmer> LarstiQ: can you try again?
[16:27] <LarstiQ> jelmer: I would like to get that bug stamped out
[16:28] <jelmer> LarstiQ: which bug?
[16:28] <LarstiQ> jelmer: the upgrade getting you branches that do that, I've seen it before
[16:28] <jelmer> LarstiQ: it's basically being caused by the fact htat the upgrade was partial
[16:28] <jelmer> and if the upgrade is partial not all of the revisions in the repository would be converted
[16:28] <jelmer> LarstiQ: so attempting to access the tip revision of a branch would cause a NoSuchRevision error
[16:29] <jelmer> which bzrlib.builtins.cmd_branch catches
[16:29] <LarstiQ> jelmer: aha
[16:31] <jelmer> it would actually be nice if upgrade could do a conversion in a separate bzrdir and then move the existing .bzr out of the way later rather than as the first step
[16:31] <vila> sidnei: fine, master restarted
[16:31]  * jelmer files a bug
[16:31] <sidnei> vila: so next steps is to get the ssh tunnel going, i need to setup autossh on kerguelen
[16:32] <LarstiQ> jelmer: 1.17 backport almost done building, then one more selftest run and I'll upload the result to richtlijn.be and prod you for a proper upload
[16:34] <jml> how can I write a tool that uses bzrlib for command-line UI infrastructure but doesn't actually force people to say 'bzr foo'? (Instead: 'my-command foo')
[16:35] <spiv> jam: I have some hackery towards auto repack of streamed data.  Not working yet, but looks promising.
[16:35] <awilkins> jml: Write python scripts that call bzrlib for features?
[16:35] <awilkins> jml: I just have a bunch of shell scripts that run bzr :-)
[16:35] <LarstiQ> jml: write them as bzr plugins and symlink my-command to bzr *ducks*
[16:35] <spiv> jam: but it's rather late here so I'm going to sleep now :)
[16:36] <LarstiQ> jml: proper thing I guess would be to extract the bzr command classes further
[16:36] <jml> LarstiQ, that's not quite good enough for what I want
[16:36] <spiv> jml: the answer depends on precisely what you mean by "command-line UI infrastructure", perhaps.
[16:36] <spiv> jml: e.g. do you want our debug flag handling?
[16:37] <spiv> And our other magic global options?
[16:37] <jml> spiv, not specifically, but I wouldn't mind it, as long as I could make sure it was specific to my app
[16:37] <spiv> jml: I suspect some minor patches to bzr may be required.
[16:37] <spiv> jml: anyway, g'night.  I hope Dublin is treating you well!
[16:38] <jml> spiv, looking at 'bzr help global-options', I think all of those would be desirable
[16:38] <jml> spiv, g'night. Dublin is great
[16:38] <jml> it's not always raining.
[16:39] <jam> jml: well, you could consider hooking into the "run_bzr" layer
[16:39] <jam> def myappsmain(args):
[16:39] <jam>  from bzrlib.commands import run_bzr
[16:39] <jam> run_bzr(args)
[16:39] <jam> you'd probably need to patch 'get_cmd_object' as well, though.
[16:39] <jam> to not actually load the bzr commands
[16:41] <jam> jml: though maybe if you just avoid a call to "install_bzr_command_hooks" that will be taken care of for you
[16:42] <jml> jam, may be. I should experiment with it.
[16:42] <jam> and as "run_bzr_catch_errors" is the code that actually installs the hooks
[16:42] <jam> you *could* just call 'run_bzr' directly
[16:46] <jml> and maybe crib some stuff from commands.main()
[16:49] <jelmer> hi jam
[16:49] <jelmer> hi jml
[16:49] <jml> jelmer, h
[16:49] <jml> i
[16:50] <jam> hey jelmer
[16:50] <jam> jml: no cribbing
[16:51] <jam> you must blindly get it right on your own
[16:51] <jml> heh.
[16:51] <jelmer> hmm, confusing nicks
[16:51] <jml> nooo
[16:52] <jrv> D?
[16:52] <jdw> David
[16:53] <jml> jam: I've already found things that would have to change if they were to be re-used
[16:53] <jml> report_user_exception has a 'bzr: ' prefix, for example
[16:55] <jml> anyway, that's enough to get started on.
[16:56] <jam> jml: except report_user_exception isn't called inside run_bzr IIRC
[16:56] <jml> no.
[16:56] <jam> only run_bzr_catch_user_exception
[16:56] <jml> jam: exactly.
[16:56] <jml> but I would need something like exception_to_return_code for my own app, I think.
[16:56] <jam> sure
[16:58] <jam> vila: permissions should be fixed now
[16:59] <vila> jam: sidnei took my place on kerguelen, slave setup in progress
[17:03] <jam> vila: thought you might be intereseted
[17:03] <jam> there is a discussion in the merge proposals about optimizing topo_sort
[17:03] <jam> implementing it on top of KnownGraph gives me KG.topo_sort in 10ms down from about 188ms
[17:03] <jam> though there is 30-40ms of KG setup overhead
[17:05] <vila> jam: I marked the discussion as should-re-read-asap but didn't see KnownGraph mentioned...
[17:06] <vila> jam: it's topo_sort not merge_sort right ?
[17:09] <jam> topo_sort
[17:09] <jam> yes
[17:10] <jam> vila: but it is a promising look at what merge_sort could become :)
[17:10] <jam> though honestly the slow point is still loading the whole graph...
[17:10] <vila> jam: my long term plan for that is to have a dedicated index with the parents sorted by gdfo
[17:16] <vila> sidnei: congrats !!!
[17:17] <sidnei> \o/
[17:23] <sidnei> jam: bzr: ERROR: no such option: --no-tree
[17:23] <sidnei> jam: i guess kerguelen is running an old bzr?
[17:23] <jam> sidnei: my guess is you are using an old bzr
[17:23] <jam> though it worked for me
[17:23] <jam> but perhaps because I forced bzr.bat?
[17:23] <sidnei> could be
[17:24] <sidnei> jam: it's got 1.11 installed
[17:24] <jam> sidnei: that is fairly signifcantly old
[17:24] <sidnei> jam: should i try to upgrade it?
[17:25] <al-maisan> Hello there! How does one read bytes from a file given a bzrlib.branch.Branch or similar?
[17:25] <jam> sidnei: if you want
[17:25] <jam> I generally prefer to run from bzr.dev myself
[17:25] <jam> but you should be able to use the installer we built :)
[17:26] <sidnei> jam: 1.17?
[17:26] <jam> yeah
[17:26] <sidnei> wonder if there's a local copy on kerguelen to avoid a download :)
[17:27] <jam> sidnei: there should be plenty
[17:27] <sidnei> jam: under shared?
[17:28] <jam> C:/home/shared/bzr/releases/bzr.1.17 should be the easiest
[17:29]  * sidnei finds it
[18:20] <kfogel> LarstiQ: http://backports.org/debian/pool/main/b/bzr/ still on 1.16 -- expected?
[18:32] <OllieR> Hey, do client and server always need to run the same version of bzr?
[18:33] <beuno> OllieR, no, in general, they work well together
[18:33] <beuno> they work better if they're the same version, fo course
[18:33] <beuno> and if one of them is too old, then you may not be able to
[18:33] <beuno> but in general, they don't need to be
[18:33] <LarstiQ> kfogel: yes, testsuite run just finished
[18:33] <LarstiQ> hmm, now my uploader disappeared :)
[18:34] <LarstiQ> ah no
[18:34] <LarstiQ> jrv: http://richtlijn.be/~larstiq/bzr/1.17/
[18:34] <OllieR> I have noticed commits seems to be taking far too long recently. For example I change one text file, do a commit over sftp to a central repo, and 8mb is transfered, which seems crazy.
[18:34] <OllieR> Wondering whether this is because I am using such an old version of bzr - Bazaar (bzr) 1.3.1
[18:35] <kfogel> LarstiQ: *nod*  thanks
[18:36] <LarstiQ> kfogel: it's a matter of uploading now
[18:36] <LarstiQ> kfogel: (jelmer changed his nick to jrv (temporarily)?)
[18:36]  * LarstiQ continues cooking
[18:37] <kfogel> LarstiQ: great!
[18:42] <OllieR> Surely a one character change to a text file shouldn't incur such huge data transfer. It makes no sense....
[19:55] <SamB> jelmer: I'm having auth issues with bzr-svn again :-(
[20:00] <jelmer> SamB: please be more specific
[20:01] <SamB> jelmer: are there flags I can use for that?
[20:02] <jelmer> SamB: you're being very vague - what doesn't work exactly?
[20:02] <SamB> jelmer: well, let me paste a transcript ...
[20:03] <SamB> http://paste.ubuntu.com/248182/
[20:06] <SamB> log is at http://paste.ubuntu.com/248185/
[20:06] <kfogel> I tried to install python-launchpadlib, but I'm having some problem with bzr and bzrtools (I think, maybe because I build bzr from trunk?):
[20:06] <kfogel>  I installed python-launchpadlib, but it looks like maybe I'm paying for my habit of installing bzr from trunk?  see https://pastebin.canonical.com/20828/
[20:06] <SamB> in short, what doesn't work is "bzr push https://dosemu.svn.sourceforge.net/svnroot/dosemu/trunk --no-strict"
[20:06] <kfogel> sorry that was a paste from another channel, so it duplicated some information.  the pastebin is the main thing
[20:07] <jelmer> SamB: does push to svn+https:// work?
[20:07] <SamB> jelmer: no
[20:07] <jelmer> SamB: same problem?
[20:07] <jelmer> SamB: when did this break? Does the last known working version still work?
[20:07] <kfogel> jelmer: (you saw LarstiQ's pings to you above?)
[20:08] <SamB> jelmer: except it has '' instead of 'dosemu.svn.sourceforge.net' between 'HTTPS ' and ' username: '
[20:08] <jam> kfogel: yeah, it looks like you already have a /usr/lib/python2.5/bzrlib file
[20:08] <jam> and so it tries to install bzr using apt and can't
[20:08] <jam> because files are in the awy
[20:08] <jam> one possibility is to manually delete bzrlib
[20:08] <kfogel> jam: ah, thanks
[20:08] <jam> install from apt
[20:08] <jam> then install from source
[20:08] <kfogel> jam: *nod*  will do
[20:08] <jam> though if you are runinng bzr from source
[20:08] <jam> you don't have to install it
[20:08] <jam> just 'make' in that directory is enough
[20:09] <kfogel> jam: I'd prefer to have it in /usr/local/bin though!
[20:09] <jam> cd /usr/local/bin
[20:09] <jam> ln -s ~/bzr/bzr.dev/bzr
[20:09] <jam> kfogel: symlinks work well for that
[20:09] <SamB> jelmer: hmm, I don't know :-(
[20:09] <kfogel> jam: no /usr/lib/python2.5/bzrlib at all
[20:09] <SamB> mostly I just want bzr-svn to have better support for debugging this type of thing, I guess ...
[20:09] <kfogel> jam: hmm, could do symlink
[20:10] <jam> kfogel: /usr/lib/python2.5/site-packages/bzrlib
[20:10]  * SamB wishes this could be included in the test suite
[20:11] <kfogel> jam: d'oh
[20:11] <jam> you'll still want to install the regular apt supported bzr so that apt's db thinks you have bzrlib available
[20:12] <kfogel> jam: doing now.  I'm going to do it your way: build from source, symlink from /usr/local/bin/, *never* install my source-built bzr, let apt own what it thinks it owns.
[20:12] <jelmer> kfogel: yeah, I'm on it
[20:12] <kfogel> although apt shouldn't touch anything in /usr/local
[20:12] <kfogel> jelmer: wonderful
[20:13] <kfogel> jam: everything fixed now.  Thank you for the timesaving help.
[20:13] <Tak> I've always wished there was an `apt-get pretend-to-install`
[20:13] <SamB> jelmer: is there some way I can trace the authentication process ?
[20:15] <jelmer> SamB: not really - most of it is in bzr itself anyway
[20:15] <SamB> jelmer: I'd be a bit happier if it was using SVN's auth stuff ...
[20:16] <jelmer> SamB: it does use svn's auth cache as well if it's present
[20:16] <SamB> what is "it"?
[20:17] <jelmer> SamB: if there are credentials present in svn auth cache for the repository you're connecting to it should use those
[20:17] <SamB> again, what is "it"?
[20:17] <jelmer> SamB: bzr-svn
[20:17] <jelmer> SamB: and bzr
[20:18] <SamB> jelmer: it can't just let svn do it ?
[20:18] <jelmer> SamB: no, because if you're using http:// the first access is using bzr
[20:18] <jelmer> SamB: so a 403 would trigger a password prompt
[20:19] <jelmer> SamB: anyway, does a "manual" commit work ok with svn on that machine?
[20:19] <SamB> hmm
[20:20] <jelmer> SamB: auth over https works fine here with current bzr-svn
[20:21] <SamB> jelmer: oh ... I guess I never stored that before ...
[20:22] <jelmer> SamB: so, password prompting should still work
[20:22] <jelmer> SamB: even if it wasn't stored before
[20:22] <SamB> hey ... the first access isn't the one that needs authentication here anyway!
[20:26] <jelmer> LarstiQ, kfogel: We should probably wait for a 1.17.1 with the performance fix
[20:26] <LarstiQ> jelmer: performance fix?
[20:26] <LarstiQ> jelmer: I included the knit_load_pyx fix
[20:26] <jelmer> LarstiQ: the pyrex import stuff
[20:27] <LarstiQ> jelmer: ie, applied the diff from lp:bzr/1.17 to lp:~spiv/bzr/bzr-1.17
[20:27] <jelmer> LarstiQ: backports shouldn't include any changes other than backporting existing stuff
[20:28] <LarstiQ> jelmer: hmja
[20:28] <jelmer> what are the plans for 1.17.1 ?
[20:28] <LarstiQ> jelmer: I'm going to look through the list for changes and cut it on Sunday I think
[20:30] <kfogel> jelmer: the perf fix doesn't affect 2a repositories, does it?
[20:30] <LarstiQ> jelmer: if you don't want to include the change, I'll prepare a 1.17-2
[20:30] <LarstiQ> kfogel: it doesn't
[20:31] <kfogel> jelmer, LarstiQ: then no urgency from Emacs' point of view, since it will be 2a anyway.  But if yuo want to do 1.17.1, that's great!
[20:31] <LarstiQ> kfogel: 1.17.1 will also have some Windows fixes
[20:32] <jelmer> there'll be quite some stable users who aren't using 2a yet, so I'd rather not upload something that hurts performance for them
[20:33] <LarstiQ> jelmer: right. So that is why I included the ~6 lines of changes
[20:33] <jelmer> LarstiQ: sorry about that, I wasn't aware about this problem in 1.17.0
[20:33] <LarstiQ> jelmer: and for unstable, my rationale is that they can wait for 1.17.1 or 1.18
[20:34] <LarstiQ> jelmer: if you absolutely want the change in unstable first I'll do that
[20:34] <LarstiQ> jelmer: but please look at the debdiff first
[20:34] <kfogel> LarstiQ: oh, Windows fixes are good.
[20:35] <LarstiQ> kfogel: yeah, there will be an 1.17.1 anyway, but it will take some more time
[20:35] <kfogel> jelmer, LarstiQ: maybe it is worth a re-roll and re-upload, then -- if it's not difficult for you guys.
[20:35] <kfogel> your call
[20:35]  * LarstiQ nods
[20:35] <kfogel> we're good to go even with 1.17.0+patch, and remember, clients can get anythig they want -- this is for Savannah to *host* the trunk repository, raelly.
[20:36] <LarstiQ> kfogel: would Savannah want to take the deb if it doesn't come from backports.org?
[20:36] <LarstiQ> kfogel: I mean, it runs on Lenny
[20:37] <LarstiQ> kfogel: but I can understand them not wanting to make an exception in their software channels
[20:39] <kfogel> LarstiQ: I think they want it from backports.org, they're pretty conservative.
[20:39] <LarstiQ> kfogel: fair enough
[20:41] <jelmer> LarstiQ: I've looked at the debdiff, that's how I knew about the change :-)
[20:42] <jelmer> LarstiQ: I'm hesitating because I'm paranoid about breaking stable users systems.
[20:42] <LarstiQ> jelmer: ah
[20:42] <LarstiQ> jelmer: right, that is very sensible
[20:42] <jelmer> LarstiQ: (and I've never done a backports uplaod before)
[20:42] <LarstiQ> jelmer: if you want we can ask nobse, who uploaded the previous version, what he thinks about the backports upload specific part?
[20:43] <jelmer> LarstiQ: Yeah, that's a good idea.
[20:43]  * jelmer queries
[20:43] <LarstiQ> jelmer: other than that, I think the question is, would you trust 1.17.1 to be stable enough, or not?
[20:44] <jelmer> LarstiQ: are you sure the other changes in 1.17.1 are going to be windows fixes?
[20:44] <LarstiQ> jelmer: the infinite recursion one is pretty bad, so that will go in
[20:44] <LarstiQ> jelmer: I'll have to look at the list to see what other stuff people have proposed
[20:45] <emmajane> beuno, No response required. I just wanted to put this on your radar in case you hadn't heard of it: http://www.springloops.com/
[20:48] <beuno> emmajane, thanks
[20:49] <emmajane> pricing seems similar to unfuddle, but the basecamp integration looks interesting
[20:49] <beuno> (on the phone, as usual)
[20:49] <emmajane> heh
[20:50] <DaffyDuck_> How does bzr use ElementTree? With regards to the bug reports about bazaar using excessive amounts of memory, I'm wondering if it in my case can be due to cElementTree not being available.
[20:51] <jelmer> LarstiQ: the infinite recursion problem is windows-specific?
[20:51] <LarstiQ> jelmer: well, it is uncorrectly splitting the drive letter if your cwd is the top, iirc
[20:53] <jelmer> ah
[20:53] <LarstiQ> DaffyDuck_: I doubt that, but possibly.
[20:55] <LarstiQ> DaffyDuck_: check bzrlib/xml_serializer.py
[20:59] <beuno> emmajane, do they have their own VCS?
[20:59] <emmajane> beuno, nope, it's just subversion
[20:59] <beuno> ah
[20:59] <beuno> "ew"
[20:59] <beuno> :)
[20:59] <emmajane> (unfuddle has git or subversion)
[20:59] <emmajane> :)
[21:00] <beuno> it looks slick though
[21:00] <emmajane> very slick, yes.
[21:00] <emmajane> and the base camp integration is interesting.
[21:40] <mobodo> I think I have my bzr browser pretty much sorted out
[21:41] <mobodo> I'll clean and post the code in case anybody is interested
[21:41] <mobodo> http://bazaar.enseed.com/
[21:42] <pygi> :)
[21:42] <pygi> nice
[21:43] <mobodo> it's only a php file and a .htaccess, no need to configure the server
[21:47] <pygi> php xD
[21:47] <pygi> evil :D
[21:51]  * beuno finally gets to emmajane's email and start replying
[21:51] <emmajane> heh
[21:51] <ronny> hmm, i should do one of those things for all intresting vcs's
[21:53] <ronny> jelmer: any plans to add a wsgi app to dulwich that implements the http proto ?
[21:54] <SamB> jelmer: well, I added exception logging to auth.SubversionAuthenticationConfig.get_svn_simple
[21:55] <SamB> jelmer: you can pull it from bzr+ssh://bazaar.launchpad.net/~naesten/bzr-svn/hackz/
[21:55] <SamB> and it says:
[21:56] <pygi> ronny, or I should...since I need it for Roundup
[21:56] <SamB>   File "/usr/lib/python2.5/site-packages/bzrlib/ui/text.py", line 92, in get_non_echoed_password
[21:56] <SamB>     password = getpass.getpass('')
[21:56] <SamB> NameError: global name 'getpass' is not defined
[21:57] <ronny> pygi: as long as i can use it without roundup >:)
[21:57] <pygi> ronny, that is/should be the general goal
[21:57] <pygi> not sure when I'll come around to do it tho
[21:58] <ronny> pygi: well, i need to write more apps using the historo abstraction, so i can find issues
[21:58] <pygi> write it then
[21:58] <pygi> I won't argue :p
[21:59] <jelmer> SamB: please submit a patch to bzr :-)
[22:00] <SamB> jelmer: yeah, started looking at that ;-)
[22:01] <beuno> emmajane, aaaaand, replied (don't need to F5 all the time!)
[22:01] <emmajane> :)
[22:01] <emmajane> beuno, thanks :)
[22:01] <SamB> jelmer: I would suggest trying to find a nicer way to do such exception logging for *all* of bzr-svn's methods that are to be called by subvertpy ...
[22:01] <emmajane> beuno, you get a cookie for being the first
[22:01] <jelmer> SamB: generally this isn't a problem
[22:01] <jelmer> SamB: but some callbacks in the svn API don't allow you to abort the operation e.g. by returning an error code
[22:01] <SamB> er, that is, when exceptions wouldn't be passed through
[22:01] <beuno> \o/
[22:02]  * beuno eats the cookie
[22:02] <SamB> jelmer: well, okay, I just mean any others of that sort
[22:02] <jelmer> SamB: there is only one other function like that
[22:02] <SamB> ah.
[22:02] <jelmer> SamB: (transport activity)
[22:02] <SamB> it's hard to tell just from looking at the code!
[22:03]  * emmajane jumps up and down and gets all excited that beuno responded and looks at everyone else and wonders who else wants cookies. :)
[22:03] <jelmer> did somebody say cookies ? :-D
[22:03] <emmajane> jelmer, only if you respond to the RFC for the new home page. :)
[22:03] <SamB> oh. I should grab some cake ;-)
[22:04]  * emmajane is not above (or is it below?) bribery. ;)
[22:04] <jelmer> emmajane: what's the URL?
[22:05] <emmajane> https://lists.ubuntu.com/archives/bazaar/2009q3/061047.html
[22:05] <emmajane> http://www.flickr.com/photos/emmajane/3791477132/ has the wireframe itself
[22:07] <SamB> jelmer: hmm. apparantly it's a bug in "bzr 1.17+4566+119" but not in the bzr.dev I have around ...
[22:09] <SamB> shouldn't there have been a new PPA build by now?
[22:12] <SamB> jelmer: oh, but it still seems like it ought to find the credentials in the SVN cache rather than making me type them in
[22:12] <SamB> especially considering that subvertpy passed in the correct username already!
[22:13] <SamB> jelmer: ... so my question is now: do you think it would be possible to create a blackbox test for this?
[22:17] <garyvdm> mobodo: That's interesting - I would like to add a commit screen a PHP cms system. How did you get data from bzr? did you run "bzr ls"?
[22:18] <garyvdm> *screen to a ...
[22:18] <mobodo> garyvdm: yes, bzr ls, bzr cat and bzr version-info
[22:18] <mobodo> and bzr log
[22:18] <garyvdm> mobodo: That cool. Where is your code?
[22:19] <mobodo> it being cleaned up as we speak :)
[22:19] <mobodo> I can send you an email later tonight or tomorrow if you want
[22:20] <garyvdm> mobodo - Yes please - I probably will copy bits out to make a commit screen in php. garyvdm@gmail.com
[22:20] <mobodo> sure
[22:23] <jelmer> SamB: yes, it'll check the svn auth cache and the bzr configuration first, and if there's no data found there it'll prompt
[22:23] <SamB> jelmer: yeah, so you keep saying
[22:24] <SamB> but it doesn't seem to work very well for me :-(
[22:24] <jelmer> SamB: a blackbox test for this is only possible if you can somehow automate starting an apache server with the svn module loaded
[22:25] <jelmer> SamB: you could do some unit testing for the auth infrastructure though, making sure it asks the right credentials providers
[22:25] <SamB> jelmer: I was afraid of that :-(
[22:26] <SamB> I don't suppose we could mock up a dummy svn server that would only do enough to test the authentication?
[22:26] <SamB> ... and then fail after that?
[22:28] <jelmer> SamB: you'll have to implement a significant part of the protocol for that
[22:30] <jelmer> SamB: I think testing just the auth infrastructure should take care of most of these problems though
[22:30] <jelmer> there's no particular need for blackbox tests
[22:33] <SamB> jelmer: hmm.
[22:34] <SamB> well, it certainly sounds more practical than the alternative ...
[23:47] <SamB> jelmer: hmm ... it works if I hand-edit the file in ~/.subversion/auth/svn.simple to actually work with the simple authprovider ...
[23:47] <lifeless> deal evolution, doing 3M/s from my disk forever, is not good.
[23:47] <SamB> where by "works", I mean *those* values get used
[23:59] <poolie> emmajane: are you here?