[00:01] <spiv> Good morning.
[00:02] <poolie> hi there spiv
=== medberry is now known as med_out
[01:16] <poolie> hm jubany might be a bit jammed, i'm going to investigate
[01:37] <poolie> spiv so is the bug you're working on the likely cause of the BzrCheckErrors in http://package-import.ubuntu.com/status/ ?
[01:38] <spiv> I think so.
[01:39] <poolie> what number?
[01:54] <spiv> https://bugs.launchpad.net/udd/+bug/806348
[01:54] <ubot5> Ubuntu bug 806348 in Ubuntu Distributed Development "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [High,In progress]
[01:55] <spiv> Although there other BzrCheckError bugs that I suspect have the same root cause.
[01:55] <poolie> thought so, thanks
[01:55] <poolie> i'll add it to the categorization
[01:55] <spiv> Thanks!
[05:06] <AuroraBorealis> so....is there a reason why bzr explorer on mac doesn't have a dock icon?
[05:06] <AuroraBorealis> isn't it just like a ...one line call?
=== beaumonta is now known as abeaumont
[07:16] <sameerynho> hi, i'm completely new to bzr , does bzr is a distributed vcs like git or hg?
[07:19] <spiv> Yes
[07:19] <spiv> Very much like those.
[07:21] <sameerynho> spiv: so my local repo can be a stand alone repository and others can push to or pull from it, am i right?
[07:22] <spiv> Yes.
[07:23] <spiv> (Although others can only push directly to your repo if you grant them write access to your local repo somehow.)
[07:23] <sameerynho> spiv: is there any script or anything like that for running a bzr server easily? like gitolite or gitosis for git?
[07:24] <spiv> I'm not familiar with those, but you can serve bzr repositories quite easily over HTTP, SFTP, TCP, or SSH.
[07:25] <spiv> For providing write access, SSH (the bzr+ssh protocol) is most common method.
[07:25] <spiv> There are docs about those methods at http://doc.bazaar.canonical.com/bzr.2.3/en/admin-guide/
[07:26] <sameerynho> spiv: thanks alot man
[07:28] <spiv> Or if it's an open source project, you could use a free hosting service like Launchpad :)
[07:30] <sameerynho> spiv: i see thanks
[07:53] <jam> morning all
[07:53] <jam> hey spiv
[07:53] <jam> (just good to see you around)
[07:54] <spiv> Hey :)
[08:15] <poolie> hi there spiv
[08:15] <poolie> s//jam
[08:44] <poolie> maybe i'll land my patches before it's too late...
[09:05] <jelmer> vila: Is there any way I can use babune to run the testsuite from the 2.3.4 SRU ?
[09:05] <poolie> o/ jelmer
[09:06] <jelmer> hey poolie, how's your day ?
[09:06] <poolie> i don't know if you can do that without vila's help, but it would definitely be good to get it set up
[09:06] <poolie> making a new schroot should be pretty cheap and easy
[09:06] <poolie> we had a talk about how to do it a few weeks ago
[09:06] <poolie> great thanks
[09:06] <jelmer> ah, cool
[09:07] <jelmer> I realized all my machines are on oneiric now, perhaps I should've held one back..
[09:07] <poolie> i installed the natty proposed version
[09:07] <poolie> it hasn't broken yet
[09:07] <poolie> :)
[09:07] <poolie> in fairly light use though
[09:07] <poolie> how's oneiric today
[09:08] <vila> jelmer: there is a way but it doesn't fit the babune model very well so far (a job want a bzr branch to test and here we want to test the installed version)
[09:08] <jelmer> poolie: apart from mumble+bluetooth still being flaky together, it's doing well
[09:08] <poolie> couldn't we have a job that's not related to a branch and that just fires on demand?
[09:08] <vila> testing SRUs *can* be done but with a dedicated schroot and a dedicated job
[09:09] <vila> poolie: yup
[09:09] <poolie> that would be nice to set up
[09:09] <poolie> or, fires ever 24h or something
[09:09] <vila> yup
[09:11] <vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-hardy/ is another kind of job that is not well supported so far
=== zyga-afk is now known as zyga
[09:11] <vila> (see description there)
[09:14] <jelmer> vila: thanks for the review of help-location-special-chars
[09:16] <vila> jelmer: I could find a better way to express that that your proposal documents the actual behavior and still mentions the related issue that url encoding is not user-friendly (which we don't want to address for now)
[09:16] <vila> grr
[09:16] <vila> s/could/couldn't/
[09:17] <jelmer> vila: Yeah - I agree with your comments, but was wondering if there's anything specific you'd like me to change to make it clearer?
[09:18] <vila> jelmer: make the explanation more detailed to nail it good
[09:18] <vila> specifically: bzr url-encode paths, use encoded URLs if you know better
[09:19] <vila> which was the key thing (for me) in our Dublin discussion
[09:19] <jelmer> ah, ok
[09:19] <jelmer> that makes sense, I think
[09:19] <vila> that gives us a good set of rules for devs
[09:19] <jelmer> but perhaps it would be good if you can have another look after I fix it?
[09:19] <vila> a bit less good for unaware users
[09:20] <vila> jelmer: sure, just ping me
[09:23] <poolie> vila, right, i guess we probably want a set of jobs, that can run on the existing schroot builders, for previous series
[09:24] <vila> poolie: almost, I think we really want different schroot to start
[09:24] <poolie> oh i was talking about testing 2.3 on hardy
[09:24] <poolie> for ppa tests, i agree we need more schroots
[09:24] <poolie> could i give you a task for setting them up? maybe after your break
[09:25] <poolie> we can possibly do them more cleanly using snapshot-based schroots
[09:27] <poolie> i'd be happy to pair on that with you
[09:37] <vila> yeah, I'm thinking about union-based chroots, pairing welcome, I was planning to give babune some love today
[09:38] <vila> but it's late for you
[09:41] <poolie> i have a little more time
[09:41] <poolie> so i think you remember how we bootstrapped the existing ones
[09:41] <poolie> the main thing i think you should try is using aufs or something else to make a snapshot-based image
[09:41] <vila> yup, and I have a python script to create the new ones
[09:41] <poolie> which is explained a bit in the schroot manpage
[09:41] <vila> yup
[09:41] <poolie> then it will discard the changes after each run
[09:42] <vila> the main issue I'd like to address is getting rid of the babune HOME mounting if only to get rid of the possibility that a job remove anything vital there
[09:43] <poolie> mm
[09:43] <poolie> that would be good
[09:43] <vila> yeah, getting rid of the changes will probably works well for -proposed
[09:43] <poolie> why does it need it?
[09:43] <vila> because for jenkins the job runs on the master and the tested branch is checked out there
[09:46] <poolie> but that shouldn't be an issue in this case as we're installing it from a package
[09:47] <vila> indeed, hence the need for  a different chroot (at least for the config part which specifies the mounts)
[15:59] <jml> mgz: around?
[15:59] <mgz> aha, I was considering pinging you
[16:00] <mgz> I've got an idea that might help some of the assertThat issues
[16:01] <mgz> how about just putting the Mismatch object in the AssertionError rather than stringifying it? avoids a bunch of __str__ vs __unicode__ issues
[16:02] <mgz> also puts the formatting entirely in the hands of the Mismatch rather than printing the Matcher at all
[16:03] <mgz> I don't think there are any bad side effects from having a non-string type argument to an exception
[16:19] <mgz> jml: anything in particular?
[16:20] <jml> mgz: oh huh
[16:20] <jml> mgz: just wanted your feedback on a bug
[16:20] <jml> mgz: https://bugs.launchpad.net/testtools/+bug/675323
[16:20] <ubot5> Ubuntu bug 675323 in testtools "assertThat style gives overly verbose output" [Wishlist,Triaged]
[16:23] <mgz> how would you feel about just printing the "Difference" portion and none of the rest?
[16:26] <mgz> in cases like assertThat(something_long, DoctestMatches(pattern, doctest.REPORT_UDIFF)) that'll be much better anyway
[16:27] <mgz> and trivial things like assertEqual(1, 2) are clear anyway without being explicit about what the Matcher and matchee are
=== med_out is now known as med
=== med is now known as medberry
[16:46] <jml> mgz: basically, that's my plan.
[16:46] <jml> mgz: maybe adding a verbose option to assertThat to print its current output
=== beuno is now known as beuno-lunch
[17:11] <jml> mgz: patch up.
[17:12] <jml> mgz: regarding your earlier comment, you mean doing something like 'raise AssertionError(mismatch)' and relying on AssertionError to call __str__ (and thus, describe)
[17:13] <mgz> I do.
[17:13] <mgz> Then we can get the logic right on the Mismatch classes, and avoid the python version variations on exception instances
[17:13] <jml> Hmm.
[17:14] <jml> mgz: That would change the API for mismatches, not sure that would be a problem.
[17:15] <mgz> In which respect?
[17:15] <jml> we don't currently insist on inheriting from Mismatch
[17:15] <jml> and we don't currently use mismatch.__str__
[17:15] <jml> so third-party mismatches that don't inherit will break
[17:16] <mgz> hm.
[17:16] <jml> where 'break' means, "<testtools.matchers.Mismatch object at %x attributes=%r>" % (id(self), self.__dict__)
[17:17] <mgz> the other option is raising an AssertionError subclass on some python versions.
[17:17] <mgz> which is also a tricky api change.
[17:17] <jml> well, we could _always_ raise an AssertionError subclass
[17:17] <jml> that would only break people who were expecting an exact class
[17:18] <jml> but would still go alright w/ 'except AssertionError' or isinstance() checks
[17:19] <jml> mgz: in some ways, I wouldn't mind raising a specialized exception for assertThat anyway. I think it would be nice to attach the matchee & matcher objects explictly and make them programatically available
[17:19] <mgz> that sounds reasonable.
[17:21] <jml> hmm.
[17:21] <jml> I guess the break there is that if someone sets failureException, assertThat failures become errors.
[17:22] <jml> I think that's as unlikely to be a problem in practice as third-party mismatches that don't inherit from Mismatch.
[17:23] <mgz> nice unreadable failure with py3k on trunk testtools: http://paste.ubuntu.com/648412/
[17:23] <Buttons840> i am leaving my current company, we have two programmers, and the other programmer will not use any version management, but i have tracked my changes with bzr; since they dont actually know how to use bzr, is there a way i can generate a pretty report to show the changes i've made that is independent of bzr?
[17:24] <Buttons840> i think it would be nice to say, "here are the changes i've made, and why" -- they company has been good to me, so I want to be helpful as I can be
[17:27] <mgz> just the forward slashes in test from gassy-failure-660852 branch I think, amusing commit message, "Oh man I hope this works."
[17:27] <mgz> Buttons840: I'm not clear what the setup you were working from is
[17:28] <mgz> if you imported the existing code somehow, then segregated your commits from imports of the trunk, you could get diffs of all of your commits and present those
[17:29] <mgz> if you just committed your stuff and his stuff without demarkating them, that would be a bit more annoying to resolve
[17:31] <mgz> Buttons840: put a post on the mailing list with some detail of how exactly you were working and what output you want, and you're likely to get useful responses
[17:37] <jml> mgz: just saw #660852
[17:38] <jml> mgz: which Python?
[17:38] <mgz> ...wrong bug?
[17:39] <jml> mgz: your comment is on the MP: https://code.launchpad.net/~jml/testtools/gassy-failure-660852/+merge/66470
=== beuno-lunch is now known as beuno
[17:43] <mgz> it's some weird merge issue.
[17:43] <jml> mgz: yeah. I did a weird criss-cross merge in that branch. I had thought that it was merged into trunk alright though.
[17:44] <jml> mgz: and since the tests pass in trunk for me, I am justified in thinking so.
[17:44] <mgz> os.sep is "/" for you
[17:45] <jml> mgz: oh, I see.
[17:45] <mgz> test_traceback_formatting is bogus basically, I'm just trying to work out where it came from, it's not in the review diff
[17:46] <mgz> or... I'm blind and it was.
[17:46] <jml> mgz: it *is* in the review diff
[17:46] <jml> mgz: that's the branch that added that test.
[17:46] <mgz> okay, so it's not a merge thing, it's just a test copying a (previously removed) test style and confusing me
[17:46] <jml> mgz: so it's "just" that we're broken on Windows?
[17:47] <mgz> yup, that and DoctestMatches makes it impossible to tell what the issue is *grr* *grr*
[17:47] <jml> mgz: I get better error messages from DoctestMatches than you do.
[17:47] <jml> mgz: I think.
[17:48] <mgz> the REPORT_UDIFF thing isn't as bad, and will be better again with your new proposal
[17:48] <jml> hmm. do I don't.
[17:48] <mgz> currently you *four* copies of a traceback are printed, and working out which is which is a nightmare
[17:48] <jml> heh heh
[17:48] <jml> I'd like to make REPORT_UDIFF the default. Thought I did, tbh.
[17:49] <Mkaysi> Hi, I have problem with bzr. Every time when I am trying to bzr branch something I get this error (traceback) http://pastebin.com/hUNbZxg0 . What should I do? I have tried removing and installing all bzr packages.
[17:50] <jml> mgz: can you please test this patch on windows? http://paste.ubuntu.com/648434/
[17:51] <jml> mgz: also, I've put down a todo item to get jenkins up and running. I'd like to get proper testing across supported Pythons and OSes.
[17:52] <mgz> looks like the right thing
[17:52] <jml> mgz: looks can be deceiving :)
[17:53] <jml> Mkaysi: weird.
[17:53] <jml> Mkaysi: what OS are you using?
[17:53] <Mkaysi> jml: Ubuntu 11.04
[17:54] <mgz> jml: does pass, go ahead and push
[17:54] <jml> mgz: thanks.
[17:55] <jml> mgz: fixed in trunk. Thanks for catching that.
[17:56] <jml> Mkaysi: that's just weird.
[17:56] <jml> Mkaysi: which version of Bazaar do you have installed?
[17:57] <Mkaysi> jml: How do I see it? I was using latest from Ubuntu repos, but when that problem came I moved to Daily PPA
[17:57] <Mkaysi> (just because I noticed that there is daily PPA)
[17:57] <jml> Mkaysi: $ dpkg -s bzr | grep ^Version
[17:58] <Mkaysi> jml: Version: 2.4.0~bzr6033~ppa3957.3940~natty1
[17:58] <jml> Mkaysi: ok. try this
[17:58] <jml> Mkaysi: run python on the command line
[17:58] <jml> Then do...
[17:58] <jml> >>> import bzrlib
[17:58] <jml> >>> bzrlib.__file__
[17:58] <jml> '/usr/lib/python2.7/dist-packages/bzrlib/__init__.pyc'
[17:58] <jml> >>> bzrlib.version_info
[17:59] <jml> tell me what __file__ and version_info print.
[17:59] <Mkaysi> '/usr/lib/pymodules/python2.7/bzrlib/__init__.pyc'
[18:00] <Mkaysi> Traceback (most recent call last):
[18:00] <Mkaysi>   File "<stdin>", line 1, in <module>
[18:00] <Mkaysi> AttributeError: 'module' object has no attribute 'version_info'
[18:00] <jml> Mkaysi: ok, thanks.
[18:00] <jml> Mkaysi: I'm guessing it's a bug in the daily build
[18:01] <Mkaysi> jml: But this happened while I was using latest version from Ubuntu repos too.
[18:01] <jml> I'm not sure how that's even possible.
[18:03] <jml> Mkaysi: I can't think of how to progress further. Sorry.
[18:04]  * jml is off home
[18:04] <Mkaysi> Is there any way to download .zips or .tar.gzs from LP?
[18:05] <mgz> yup, from the downloads page. you might have luck just purging the package then not using the daily.
[18:06] <Mkaysi> Ok
[18:06] <Mkaysi> Thanks
=== marienz_ is now known as marienz
[18:43] <lamalex> hi, i can never remember the syntax to just revert the changes from a single commit
[18:43] <LeoNerd> merge -rafter..before
[18:45] <lamalex> when i do that, it shows MANY more changed files than were changed in the commit i'm trying to undo
[18:45] <lamalex> so i want to revert commit 666
[18:45] <lamalex> i would do bzr merge -r 667..665?
[18:46] <luks> no, it should be 666..665
[18:46] <fullermd> No, 666..665
[18:46] <luks> or, bzr merge -r666...before:666
[18:46] <luks> which correctly handles non-mainline revisions
[18:47] <luks> er, only two dots
[18:47] <fullermd> Unless it's life or death, then you want -r666...___...665   8-}
[18:50] <lamalex> :{
[18:50] <lamalex> :P
[18:50] <lamalex> thanks
[19:16] <awilkins> the log widget in qbzr has a convenient reverse-cherry-pick this revision option
[19:37] <Buttons840> i can i see commit diffs 1 through 10 excluding 5 (for example)?
=== yofel_ is now known as yofel
[22:04] <poolie> hi all
[22:05] <jelmer> g'day poolie
[22:08] <jelmer> hi amanica
[22:08] <amanica> hi jelmer! :)
[22:14] <jelmer> poolie: I think you mean s/Jelmer/vila/ in your email?
[22:47] <maxb> jelmer: Hi. The bzr-beta PPA is now completely installable except for bzr-svn. Do you think you might be making a 2.4-compatible snapshot soonish?
[22:49] <poolie> hi, i did, just a typo
[22:49] <poolie> hi maxb
[23:01] <dOxxx> I'm wondering what to do about the QBzr release that bialix just made for bzr 2.3 series, since I've already built the installer with an older version.
[23:15] <poolie> hi dOxxx
[23:15] <poolie> maybe rebuild with a further dot revno?
[23:16] <poolie> or, save it for a later 2.3.x?