[00:00] <mgz> Invalid -W option ignored: unknown warning category: 'ImportWarning'
[00:01] <mgz> I get spew, but otherwise seems harmless.
[00:01] <mgz> That one line change does seem a daft thing to drop Python 2.4 support over.
[00:01] <poolie> oh, do you?
[00:02] <poolie> i don't want to drop 2.4 support over this
[00:02] <poolie> ah, i was wrong
[00:02] <poolie> i forgot karmic's _default_ python is not 2.4
[00:03] <spiv> mgz: we need -Wignore:UnknownWarningWarning ;)
[00:03] <poolie> :)
[00:03] <poolie> so it's either a conditional binding of that name if it exists, otherwise just -Werror for some explicit things
[00:04] <poolie> hm, really rebooting now, unity bug filing done for teh moment
[00:05] <hugogee> greetz all :D
[00:07] <hugogee> I run openbsd and am interested in using Bazaar. Good stories, bad, i would like hear. tx
[00:07] <hugogee> sup poolie
[00:08] <poolie> hi hugogee
[00:08] <poolie> it's good; i like it
[00:08] <poolie> what are you going to use it for?
[00:09] <hugogee> Yes it seems good. I just want to know what i am up against trying to get the shoe to fit. :D
[00:09] <hugogee> community collaboration.
[00:09] <hugogee> how well does it work with binary files?
[00:09] <poolie> what kind?
[00:10] <poolie> it compresses them well, if they're at all compressible
[00:10] <hugogee> Word, excel...
[00:10] <poolie> it's not going to be able to natively diff or merge them
[00:10] <hugogee> diff ? or
[00:10] <poolie> there is a plugin to diff them
[00:10] <hugogee> oh, do tell.
[00:10] <poolie> to show the changes from one version to the next
[00:10] <poolie> i have to say Word and OpenBSD sounds like a strange combination to me :)
[00:11] <hugogee> Hehehe
[00:11] <hugogee> Its for collaboration.
[00:12] <poolie> if it's all office files, you may be better off using microsoft's collaboration things
[00:12] <poolie> much as i like bzr it is designed more for managing code
[00:12] <hugogee> naw!
[00:13] <hugogee> yes i understand but subversion does handle binary. so long as i can backup and restore all will be fine.
[00:13] <hugogee> m$ < great
[00:14] <hugogee> m$ > free
[00:14] <poolie> if you're happy with svn's binary handling bzr should be fine too
[00:15] <poolie> spiv one more thought:
[00:15] <hugogee> yes, i am trying to make it easy for this nice little community of people.
[00:15] <poolie> spiv, mgz, getting a -W meta warning during 'make check' is pretty harmless
[00:15] <mgz> that's my feeling too.
[00:16] <poolie> otoh other places might also hit ImportWarning
[00:16] <mgz> I prefer changing the makefile to the code.
[00:16] <poolie> other than just this thing
[00:16] <poolie> right
[00:16] <spiv> I'm fine with just changing the makefile.
[00:17] <spiv> I don't think anything depends on stderr of 'make check' being clean
[00:21] <poolie> so 2.1 apparently fails on py2.7 with AttributeError: 'module' object has no attribute '_WritelnDecorator'
[00:21] <poolie> this rings a bell
[00:22] <mgz> I didn't fix 2.7 errors on 2.1
[00:22] <mgz> only 2.3
[00:22] <mgz> a couple also landed on 2.2, but if you want to use... dammit... Python 2.7, you need Bazaar 2.3
[00:22] <poolie> fair enough
[00:23] <poolie> i was just testing my change didn't break later versions
[00:23] <mgz> this may not be clearly documented anywhere.
[00:23] <poolie> i would almost land a change saying this or giving a clean error
[00:23] <poolie> but it can probably wait until someone hits it
[00:23] <poolie> it's a bit like the plugin versioning thing, and whether it's important to warn about too-new bzrs
[00:26] <lifeless> hi mgz
[00:26] <mgz> hey lifeless!
[00:27] <poolie> hi lifeless
[00:30] <lifeless> hey poolie
[00:33] <poolie> wow running the 2.1 tests on natty is a bit annoying
[00:33] <poolie> bzr itself runs fine but there are snags around the edges
[00:33] <poolie> lifeless: thanks for the pqm improvement
[00:34] <lifeless> poolie: my pleasure
[00:34] <poolie> can we have one of us also do xfail?
[00:34] <poolie> ah a clearer way to put that would be
[00:35] <poolie> could you either do it (not right now) or give me a clue where to change it?
[00:37] <poolie> do those machines just run pqm trunk?
[00:37] <lifeless> So xfail
[00:38] <lifeless> The machine uses subunit from package
[00:38] <lifeless> and a branch of pqm which the losas pull into on request
[00:38] <lifeless> *if* the subunit they have has a TestResultFilter ready to handle xfail
[00:38] <lifeless> then its easy - just another parameter to the filter thats constructed
[00:39] <lifeless> if not, then we need to start with subunit and bubble it through
[00:39] <lifeless> not terribly hard
[00:39] <poolie> k, so first we need to either grep the package for that, or find out what package is installed
[00:39] <poolie> and this would be the subunit outside of the chroot
[00:44] <lifeless> poolie: yes
[00:45] <lifeless> poolie: my packaged subunit here says
[00:45] <lifeless>  |  __init__(self, result, filter_error=False, filter_failure=False, filter_success=True, filter_skip=False, filter_predicate=None)
[00:45] <lifeless> for pydoc subunit.test_results.TestResultFilter
[00:45] <lifeless> so I think johns patch needs a re-look, then merged, a release, package, and updated in CAT
[00:46] <poolie> ok
[01:02] <poolie> biab
[02:39] <poolie> nice revert speedup jam
[02:54] <poolie> spiv:
[02:54] <poolie> blah
[02:54] <poolie> https://code.launchpad.net/~mbp/bzr/trivial-2.1/+merge/57802
[03:33] <spiv> poolie: approved
[05:21] <hugogee> nite folks! :D
[06:14] <poolie> gack
[06:14] <poolie> omg look at them all
[06:17] <lifeless> poolie: hairball?
[06:18] <poolie> xchat-gnome has what may be a natty regression
[06:19] <poolie> that just typing //topic doesn't print the topic, it clears
[06:19] <poolie> it
[06:23] <puzzlement> poolie: Sent you an email re spiv's availability (or lack thereof) this afternoon.
[06:24] <poolie> got it, thanks for letting me know
[06:24] <poolie> no problem
[07:53] <jam> thanks poolie, morning?
[07:53] <poolie> hi jam!
[07:57] <poolie> spiv is off sick
[07:57] <poolie> or more precisely his son is sick
[08:03] <poolie> jam, how are you
[08:03] <poolie> i'm going to merge up the 2.4 regression fix, and finish off some old patches in the queue
[08:04] <jam> poolie: things are going pretty well here. Getting some random fallout in the test suite from my 'faster-merge' patch. It turns out that a fair amount of code accidentally assumed that all files would be declared to the TreeTransform
[08:04] <jam> so only mentioning the actually changed ones had random fallout elsewhere
[08:04] <jam> nothing hard, just annoying
[08:04] <jam> and then I fixed one incorrectly, but accidentally ran the bzr.dev test suite instead of my working copy before submitting it again :)
[08:06] <poolie> :)
[08:06] <poolie> in a while we might get a faster pqm, which would be nice
[08:07] <poolie> it's funny how old bzr 2.1 is
[08:07] <jam> poolie: indeed.
[08:07] <jam> (on both accounts)
[08:07] <poolie> eg it has hard test suite dependencies on paramiko and others
[08:07] <jam> poolie: we always tried to make stuff like paramiko soft, but we often missed a test here and there.
[08:13] <poolie> i think i will try to finish the diffoptions thing
[08:13] <poolie> maybe after one more of jelmer's patches
[08:20] <bradm> poolie: so, hi
[08:20] <bradm> poolie: do you think we still need that old chroot on balleny?
[08:28] <poolie> bradm: nah
[08:34] <bradm> poolie: okey, I'll blow it away then, and close off that ticket
[08:42] <jam> poolie: you have both "760435-unittest-deprecations" and "760435-less-fail" was the latter supposed to have a precondition on the former?
[08:42] <poolie> ah yes
[08:43] <jam> poolie: anyway, both "merge: approve"
[08:43] <jam> Of course, assuming it is all mechanical
[08:43] <jam> but it certainly seemed fine
[08:46] <poolie> it is
[08:58] <poolie> thanks for checking though
[09:14] <poolie> jam i've been stewing on a blog post about matchers
[09:15] <poolie> maybe after i do one more hr task i will actually write it odwn
[09:19] <lifeless> poolie: too java ish ?
[09:19] <poolie> a bit
[09:19] <lifeless> poolie: you should see the one I turned my nose up... was worse
[09:19]  * poolie looks
[09:19] <poolie> haha
[09:19] <poolie> i'd like to say
[09:19] <poolie> assertsomething not fileexists('foo')
[09:19] <poolie> and have it give a smart message when it fails
[09:20] <poolie> i think i have a testtools bug about it
[09:20] <jam> poolie: specifically that 'not' gives bad messages?
[09:20] <jam> or that fileexists('foo') tends to just give success/failure rather than a clear message?
[09:21] <poolie> by the time it gets to 'not', all it sees is a boolean
[09:21] <poolie> ideally this would be a bit more HOF-ish
[09:24] <lifeless> HOF ?
[09:24] <lifeless> poolie: assertThat('foo', FileExists()) doesn't work for you ?
[09:25] <poolie> higher-order-function
[09:25] <poolie> that's ok, though a bit longwinded
[09:26] <poolie> what if i want to assert it does not exist?
[09:26] <lifeless> poolie: assertThat('foo', Not(FileExists()))
[09:28] <poolie> so you get 'foo matches FileExists(something)'
[09:28] <lifeless> what is something ?
[09:32] <jam> lifeless: I think the point is that if "assertThat('foo', Not(FileExists())" fails, he wants to get a nice message "file "foo" was not supposed to exist, but what found"
[09:32] <jam> *but was found
[09:34] <lifeless> so it will say "'foo' matches FileExists()" with current testtools
[09:34] <jam> And Not(Matcher) doesn't tend to give good error messages.
[09:35] <lifeless> it is a currying/HOF approach; the protocol is /slightly/ more than simple functions can do though
[09:35] <jam> lifeless: so I can't put my finger on it exactly, but I have noticed that bzr test suite failure messages are more legible than the Launchpad ones going through Matches
[09:35] <jam> Matchers
[09:35] <lifeless> jml and I would welcome improvements
[09:35] <poolie> lifeless: in short i wonder if they should return matches as well as mismatches
[09:35] <lifeless> matchers are taking off organically in lp development
[09:35] <poolie> also i would like to just call them, getting rid of the self.assertThat
[09:35] <poolie> which is a bit longwinded
[09:36] <jam> poolie: golang seems to just use "assert(...)"
[09:36] <poolie> raising an exception is a clear indication of failure
[09:36] <jam> using matchers
[09:36] <jam> at least from niemeyer's examples that I've seen
[09:37] <lifeless> a key part of the point of matchers is to separate [mis]matching and error conditions
[09:38] <lifeless> things raising AssertionError are pretty awkward to layer upon
[09:39] <poolie> well, this is the tradeoff
[09:39] <poolie> perhaps it is possible to find something that is not so longwinded but does allow layering
[09:40] <poolie> jam i think there assert() is a semi builtin
[09:40] <poolie> like in python in fact
[09:40] <poolie> though not crippled
[09:40] <jml> It would be easier in a language that had better partial function application syntax
[09:40] <jam> poolie: http://paste.ubuntu.com/593640/
[09:40] <jam> it is on an object
[09:41] <jam> I don't know what "c" is
[09:41] <jam> case ?
[09:41] <poolie> too much python :)
[09:41] <jml> There are some issues with the matcher traceback that make it harder to read (duplication, layers of stack that are boring to most people)
[09:41] <poolie> i think it's a good step forward,  just not utopia
[09:42] <jml> sure
[09:42] <jml> I don't have solutions for the syntax issues that you are raising, so I'd welcome ideas.
[09:42] <poolie> jam i'd guess it's basically a typedef for TestCase
[09:43] <jam> poolie: yeah, that was my guess, too. though having "s *S" and "c *C" is really odd to me. :)
[09:43] <jam> also, declarations are backwards from c, so c *C is "C *c" in C-code
[09:43] <jam> I might have been able to fit more letter C in that sentence
[09:45] <poolie> jml: stephane says "why are they having a thing called Thunderdome in Dublin? Shouldn't it be in Silverton?"
[09:45] <jml> :)
[09:45] <poolie> "the cracked lookingglass of a servant, a symbol of irish art"
[09:45] <lifeless> c.Assert(result.Host, Not(Equals), host)
[09:45] <lifeless> looks almost exactly like our Matcher syntax
[09:46] <lifeless> slightly less curried
[09:46] <lifeless> or more, depending on point of view
[09:46] <poolie> mm the half-currying is a bit odd too
[09:46] <poolie> maybe it's good if it makes the expected bit clear
[09:46] <poolie> anyhow, i really have to go...
[09:46] <poolie> have a good weekend
[09:46] <lifeless> ciao
[09:46] <poolie> congrats on your appservers
[09:50] <lifeless> it will be nice to be running lp on something more powerful than your pqm machine :P
[09:51] <lifeless> [thats a slight troll, we do have some seriously powerful machines in play already :))
[09:59] <jml> poolie: one of my many favourite lines from that book :)
[10:18] <maxb> jelmer: We need to fix the dulwich branches - PPA and daily builds are now being impacted by something similar to what I saw in bug 707170
[10:33] <kgoetz> can i list all files modified modified between certain revisions without a full diff?
[10:34] <lifeless> bzr st -r x..y
[10:40] <kgoetz> thanks
[11:08] <Odd_Bloke> I have accidentally branched from a non-trunk branch and created my branch ready to merge into trunk.  How can I remove the changes introduced in branch I based it on?
[11:48] <tasslehoff> we went from svn to git a while back, and find that git on windows is slow and sad. does bzr-git work well/fast on windows?
[11:48] <tasslehoff> we thought to start there, and then maybe move everything to bzr if it works out
[11:49] <maxb> I think bzr-git works pretty well. I don't use Windows, though
[11:53] <jelmer> tasslehoff: bzr-git on Windows doesn't work with ssh yet
[12:07] <tasslehoff> jelmer: ah. that was important to know. thanks.
[12:10] <jelmer> tasslehoff: it shouldn't be hard to fix, it just hasn't happened yet
[18:50] <knighthawk> I'm still trying to figure out bzr-svn. I did a successful svn-import then pulled a branch from that. but now I have no idea how to do an update or a commit back to the svn repo
[18:51] <knighthawk> I thought a merge from my branch to the import then I could commit back.
[18:51] <knighthawk> but I'm still stuck on doing the update.
[18:53] <knighthawk> it seems my biggest issue right now is that I don't have a working tree in the import (and I don't think I should need one) but then I can't update from there.
[19:14] <maxb> knighthawk: It sounds like you have some terminology confusion besides other things. I think many places where you're saying "update" you don't mean "bzr update", the command.
[19:14] <maxb> For clarity, best to avoid that confusable.
[19:15] <maxb> The key point to understand about bzr-svn is that it presents the virtualization that svn branches operate just like bzr branches
[19:16] <maxb> Also, there's nothing special about a bzr branch produced by "bzr svn-import" - it's just a shortcut to individually "bzr branch"ing each branch in the subversion repository
[19:17] <maxb> So, if you want to land a branch developed in bzr back into svn, then you have much the same options as you do when landing a branch developed in bzr back onto its parent bzr branch.
[19:17] <maxb> So, one option is that if the parent branch has not diverged, you can simply push your changes
[19:18] <maxb> Or, if the upstream branch has diverged, it's usually appropriate to merge your development into a local copy of upstream, and push the result
[20:24] <wizonesolutions> I'm getting an I/O error on one of my repository packs :( can't do anything to it, and it's in the repository for a branch I want to check out...
[20:25] <wizonesolutions> So I don't think I could bzr branch it somewhere else and check out from there either since it'd probably have to touch that pack
[20:25] <wizonesolutions> e2fsck came back clean, but I think the drive is just old and starting to run into some probs...not really sure how to recover this file or proceed...
[20:26] <wizonesolutions> as suggested by smartctl
[20:44] <maxb> wizonesolutions: You should pastebin the exact error, "an I/O error" is insufficiently detailed to best understand your project
[20:44] <maxb> erm
[20:44] <maxb> s/project/problem/
[21:13] <wizonesolutions> maxb: It really is just "input/output error" though from Bazaar's standpoint it's a ShortReadvError or something. But an underlying I/O error is the cause. My box decided to go crazy though so when it comes back...will let you know.
[21:13] <wizonesolutions> lol @ sed on IRC
[21:14] <maxb> Hrm. Well, if you can't even copy the file from that disk to elsewhere, then you do have serious problems
[21:15] <wizonesolutions> maxb: Yeah :/ I'm not sure if bzr branch is working cuz my system is acting weird. Probably cuz of bzr using 100% CPU again or something. But it did seem to be getting farther with that approach than before.
[21:15] <wizonesolutions> The issue's in the shared repo, not the branch itself.
[21:15] <maxb> If it's a younger pack which is broken, it's possible that there might be scope for recovering older parts of history. But some dataloss is almost certain
[21:15] <wizonesolutions> so if I can branch elsewhere then I can save it and I'm good
[21:15] <wizonesolutions> ah
[21:15] <maxb> Can you run "find .bzr/repository -ls" and pastebin it?
[21:17] <wizonesolutions> Sure...couple mins, gotta see if I can still SSH in or something and what it's up to
[21:28] <wizonesolutions> maxb: http://pastebin.com/Q4Ldj5nF
[21:29] <maxb> wizonesolutions: And which packs have problems?
[21:30] <maxb> In any case, if the disk is in doubt, I think your first priority should be to get the files off as intact as possible
[21:30] <wizonesolutions> maxb: 34d110e625509acc103c649ed7cc6cb7.pack is the culprit. The couple-gigger
[21:30] <maxb> Ouch, it had to be, didn't it
[21:31] <maxb> Being that that's the oldest pack in the repository, recovery prospects are not good
[21:31] <wizonesolutions> Well, I've got the files backed up elsewhere fortunately. Perhaps I can try to restore it from there, .bzr and all, and hope that it comes back sane. This is where every branch containing the full history starts to hold its salt, eh :)
[21:32] <wizonesolutions> Seems like branching to another dir actually did fail. I mean that makes sense given that the whole point of a shared repository is that it gets touched when doing stuff on the branches under it and that some revs are shared, etc. so I'm not surprised.
[21:33] <wizonesolutions> maxb: Oh, but it's a checkout, the one I have. But I should be able to unbind it without probs...yeah so I have the files at least. Well that's the main thing
[21:34] <maxb> lightweight or heavy checkout?
[21:34] <wizonesolutions> heavy
[21:34] <maxb> oh
[21:34] <maxb> well, no problem then
[21:35] <wizonesolutions> yeah so I'll see if restoring it from backup does the trick...probably should
[21:35] <wizonesolutions> these hard drives man, they always obey Murphy's Law
[21:35] <wizonesolutions> I love and hate how hard drives just keep working even as the problems build up
[21:36] <wizonesolutions> and then eveeeeeentually they nail you when you least expect it
[21:36] <wizonesolutions> It's one of those things I never test until there's a problem, but by the time there's a noticeable problem things are bad. :/
[21:36] <wizonesolutions> ah well
[21:37] <wizonesolutions> thanks a lot maxb for the time and help!
[23:57] <poolie> hi all