[00:05] <urbanape> jelmer: http://paste.lisp.org/display/123948
[06:27] <poolie> hello all?
[06:35] <spiv> poolie: hi ;)
[06:35] <poolie> hello
[06:35] <poolie> could you sanity check https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71154
[06:45] <spiv> poolie: ugh, but +1
[06:47] <vila> Morning all !
[06:47] <poolie> hi vila, and goodbye
[06:47] <poolie> i might be back later
[06:47] <vila> hi poolie, cu later
[08:08] <jam> morning vila and poolie (if you are back)
[08:08] <vila> hello jam
[08:09] <jam> brb, pidgeon forgot who I am again
[08:41] <jelmer> hi jam, vila, poolie
[08:41] <jam> morning jelmer
[08:41] <vila> jelmer: hey !
[08:44]  * fullermd continues in his quest to outlaw mornings...
[08:45]  * vila suggests to shut down the sun
[08:45] <vila> oh wait Oracle did that already
[08:45]  * fullermd *rimshot*
[08:46] <fullermd> Shutting down the sun would have the added bonus of the temperature staying out of the 3 digit range.  For a while, anyway.
[08:48] <vila> nah, bad plan, it will make it harder to boil water (that's what the 3 digit temperatures are about really) and as such coffee production will become harder, definitely a no-go
[08:49] <fullermd> You can cold press coffee, in extremis.  I just wish it would stop trying to boil water everywhere outside my front door.
[08:50] <vila> :)
[08:51] <vila> In other news, with tag fetching being optional and equality_funcs.clear workaround in place and bug #822571 fix backported to 2.4, I'm ready to freeze 2.4.0
[08:51] <jelmer> vila: \o/
[08:51] <jelmer> hi Riddell
[08:52] <vila> jam, poolie, jelmer: pqm was very slow the day before yesterday, dunno if this has changed, but to be safe, please leave pqm alone (or I'll ask losas to kill the submissions ;)
[08:52] <Riddell> hello jelmer
[08:52] <vila> Riddell: hey ! You're back :)
[08:52] <vila> Riddell: welcome back then :)
[08:53] <jelmer> Riddell: how's the desktop summit?
[08:53] <vila> Riddell: please leave pqm alone too ;)
[08:53] <jelmer> vila: :)
[08:53] <Riddell> jelmer: desktop summit was fun, I got some ideas for Bazaar
[08:53] <fullermd> Apparently I'm still allowed to ridicule pqm about its childhood etc though.
[08:54] <vila> fullermd: sure :)
[08:55] <jelmer> Riddell: cool
[09:40] <maxb> poolie: I'm curious about your UDD change today, because the previously existing code in udd should have already accounted for the issues concerned
[09:53] <jam> vila: babune just stopped responding for me, did something happen?
[09:54] <vila> jam: nothing I'm aware if
[09:54] <vila> of
[09:54] <vila> even
[10:05] <spiv> maxb: that probably explains why his change didn't make any difference on production :)
[10:06] <jam> vila: seems it was just slow because I was loading multiple pages at once
[10:07] <jam> or maybe something on my end, given I just DCd from IRC
[10:08] <jam> vila: I can't reproduce the "PermissionError" bugs, but some of the others I can fix
[10:12] <vila> \o/
[10:29] <jam> vila, mgz: One of the tests is a testtools bug
[10:29] <jam> well, test_selftest is asserting the output
[10:29] <jam> however the "if" check says "if version <= (0,9,11)"
[10:30] <jam> but my testtools.__version__ == (0, 9, 11, 'final', 0)
[10:30] <jam> which is > version
[10:30] <jam> anyway, "testtools_version[:3] <= " works
[10:31] <vila> jam: I plan on upgrading testtools on the slaves asap, will that workaround the issue ? (a fix would be better nevertheless)
[10:31] <jelmer> I guess we could fix the check to use testtools_version[:2]
[10:31] <jam> jelmer: [:3]
[10:31] <jam> :2 is (0,9)
[10:31] <jam> (it is an exclusive range)
[10:33] <jelmer> jam: ah, right
[10:33] <jam> vila: both selftest failures were because of that
[10:33] <jam> I don't know if there is anything else, though, and this is an easy fix
[10:34] <vila> jam: you mean for windows or you looked at all slaves ?
[10:34] <jam> vila: https://code.launchpad.net/~jameinel/bzr/2.5-win32-fixes/+merge/71176
[10:35] <jam> vila: On the windows slave is what I was looking at
[10:35] <vila> k
[10:35] <jam> it was checking against 0.9.11 but the checks had the wrong bounds because of the 3-tuple vs 5-tuple
[11:23] <poolie> hello maxb
[11:25] <poolie> maxb, i think my change was misguided anyhow, as it doesn't seem to have fixed it
[11:27] <vila> poolie: I think I lost track about what was planned for pqm, but landing a patch takes more than 3 hours these days so we probably want to do *something* ;)
[11:28] <poolie> ah, maybe due to it syncing a lot while running the tests?
[11:28] <vila> ouch
[11:30] <vila> I was hoping for some unusual load there or some other misbehavior of the host instead :-}
[11:30] <poolie> that's possible too
[11:30] <poolie> ask a losa for help?
[11:31] <vila> poolie: sure, I wanted to check if I was up-to-date first. So nothing has occurred lately right ?
[11:31] <poolie> i'm not aware of anything else that could have broken it
[11:31] <vila> ok
[11:31] <fullermd> What sort of hardware does it sit on?
[11:31] <poolie> oh, tom was doing some work on setting up a new pqm box, but i didn't read anything about him having changed the existing machine
[11:32] <poolie> fullermd: an old DL-series hp server i think
[11:32] <fullermd> Running raw, not virtualized?
[11:32] <poolie> in a chroot
[11:32] <poolie> biab
[11:34] <fullermd> Wouldn't expect the fsync stuff to make a night and day change.
[11:34] <vila> fullermd: I don't have hard numbers but it seems we went from < 2 hours to > 3 hours
[11:35] <fullermd> Though the cost isn't trivial.  Still, sounds like an OOM-ish hit on PQM from whatever.
[11:35] <fullermd> Hm.  I figured pqm ran the test suite in 20, 30 minutes.
[11:35] <jelmer> vila: are you done with pqm?
[11:36] <fullermd> The timing poolie gave in the MP for fdatasyn showed ~20% increase.
[11:37] <vila> jelmer: not yet, still at least one submission to open 2.4.1 (which requires the current one to finish) and potentially a second submission to merge 2.4 to trunk
[11:38] <jelmer> vila: *nod*
[11:38] <vila> jelmer: thanks for your patience (though mine is running thin....)
[11:39] <poolie1> hi vila, jelmer
[11:40] <jelmer> hey poolie1
[11:40] <vila> poolie1: so, tom said the new pqm may be ready in a week or two
[11:40] <vila> also, it seems we're racing with u1 on the actual one which may explain the slowing
[11:44] <poolie1> ok
[11:44] <poolie1> we should see about turning off fdatasync during tests
[11:45] <jam> poolie1: did you see that your config stuff for fdatasync doesn't work?
[11:45] <jam> the new ConfigStack doesn't know about 'bool'
[11:45] <jam> so setting it to "False" returns a string which evaluates to True always
[11:45] <jam> I think you could set it to the empty string
[11:45] <jam> or an empty list
[11:45] <jam> (btw, you don't have any tests for it working. :)
[11:46] <poolie1> :/
[11:46] <jam> poolie1: I only found out because I was trying to copy your work for my config
[11:46] <jam> and hey, setting it to False doesn't do anything wth?
[11:46] <poolie1> we'd better fix that for 2.4.0 then
[11:51] <vila> that would be for 2.4.1, 2.4.0 is already cut and landing on pqm, with tag
[11:54] <poolie1> are the criticals all fixed+
[11:54] <poolie1> apparently yes,that's great
[11:55] <poolie1> jam, did you file a bug for that?
[11:55] <vila> yes, I downgraded one since it was covered by the optional tag fetching
[11:55] <vila> we way still want to bump it to critical for udd though
[12:04] <vila> poolie1: I'm talking about bug #806348
[12:06] <vila> surprising... ubot5, why do you report about launchpad when bzr is the first project listed on the page and the primary project seems to be udd...
[12:06] <vila> (primary as in: http://pad.lv/806348 resolves to https://bugs.launchpad.net/udd/+bug/806348)
[12:07] <vila> bah
[12:07] <poolie1> mm?
[12:11] <Riddell> vila: can I send things to PQM yet?
[12:11] <vila> Riddell: nope
[12:11] <vila> Riddell: :)
[12:11] <vila> Riddell: or rather, you can, but I will ask a losa to kill it ;)
[12:16] <poolie1> vila, when did you first notice problems?
[12:17] <vila> I think I asked to jelmer a couple of days ago
[12:17] <vila> I tried toying with webnumber but it's not accurate enough to be conclusive
[12:18] <vila> http://webnumbr.com/bzr-pqm-queue-length.from%282011-06-27%29.to%282011-06-28%29
[12:18] <vila> http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-09%29
[12:43] <poolie1> i don't think that's going to really correlate with much though
[12:44] <poolie1> i guess we could look at mail that was sent to pqm and when it was returned but it's probably easier to see if the sysadmins can find a log for you
[12:52] <vila> poolie1: yeah, but since the new hardware is expected soon-ish, I'm not sure it's worth investigating either (tom prefer to focus on the new hardware and I see no point disturbing it)
[12:52] <jam> vila:  because L comes before U, but magically after B?
[12:52] <poolie1> ok i think i understand the httperror bug
[12:53] <vila> poolie1: \o/
[12:53] <vila> jam: I killed your windows fixes submission and re-submitted it
[12:53] <jam> vila: you're the one that killed my submission?
[12:53] <jam> k
[12:53] <jam> I was a bit concerned about a failed test run with no failures
[12:53] <vila> jelmer, Riddell : feel free to overload pqm now ;)
[12:54] <jelmer> \o/
[12:54] <Riddell> vila: what happened?
[12:55] <poolie1> vila, did you actually kill it or just ask for it to be killed?
[12:56] <vila> Riddell: cutting a release requires two submissions: one for the release and its tag, one to open the branch for bugfixes, I prefer to pull between the two and not leave the branch in the transient state where nobody can land
[12:56] <vila> poolie1: I asked a losa
[12:57] <urbanape> jelmer: sorry I didn't get back to you earlier last night.
[12:58] <jam> poolie1: he rooted the machine via DDOS and a bug in pqm's web front end, I think :)
[12:58] <jam> he's really determined that his patch be next
[12:58] <jelmer> urbanape: np, I'm afraid I don't really have an answer either though. It seems like the issue is with the way the vcs-bzr script in emacs runs
[12:58] <jelmer> urbanape: (without a tty)
[12:58] <urbanape> gotcha. okay, bummer
[13:01] <urbanape> aha!
[13:01] <urbanape> awesome
[13:01] <urbanape> I added --no-tty to my agent-gpg script
[13:01] <urbanape> ta-da
[13:01] <jam> poolie1, vila: Even more fun. If you do "c = ConfigStack(); c.set('foo', True); c.get()" Returns True the object. But if you write it out, and then create "c2 = ConfigStack(); c2.get()" it returns u'True' the string.
[13:02] <jelmer> urbanape: ah, that was easy :)
[13:02] <poolie1> yuk
[13:02] <urbanape> jelmer: it was
[13:03] <vila> jam: see my boolean-option (submitted to pqm)
[13:04] <jam> vila: sure. I'd put it pretty high in the 2.4.1 queue, given that one of the caveats for fdatasync is that people can disable it if they notice a slowdown
[13:04] <poolie1> thanks vila
[13:05] <jam> vila: I'm a bit concerned that it requires an api break for a stable series. Should we just switch the code to config.get_user_option_as_bool() ?
[13:06] <jam> (I guess it isn't a major break)
[13:06] <vila> jam: the easiest may be to not use configstack at all for the datasync options then. Alternatively, options are strings unless specified otherwise (and in 2.4 nobody specifies otherwise ;)
[13:06] <vila> jam: yup, that's another alternative, whatever works
[13:07] <vila> jam: but I agree, backporting boolean-option to 2.4 is a no-go
[13:08] <vila> jam: and thanks for spotting the issue
[13:08] <jam> bug #824513
[13:10] <vila> the 2.4.1 milestone has been created and the lp:bzr/2.4 is almost opened for bugfixes (you have to wait for the current submission to land to base your branch and get the proper news file)
[13:10] <vila> Riddell: see above for why I don't like to leave the branch in this transient state :0D
[13:12] <vila> poolie1: the suspense is killing me, what caused the httperror ??
[13:12] <vila> :)
[13:13] <poolie1> see the bug
[13:18] <vila> wow
[13:20] <jonathanj> where does bzr cdiff get its colour information from?
[13:24] <poolie1> that was such an annoying api break
[13:24] <poolie1> i have some uncommitted changes that i think ought to fix it, but perhaps they don't
[13:42] <fullermd> Gruuh, LP makes bzrtools difficult...
[13:42] <fullermd> It says the latest is 2.3.0.  You have to dig to find that (a) there's a 2.3.1 succeeding that, and scroll way down in a list to find 2.4.0.
[13:55] <vila> fullermd: gigo :-/
[13:57] <fullermd> It always makes me laugh (funny dear-god-no, more than funny ha-ha...) at how every new bzr release makes me have to work with CVS   :|
[13:59] <urbanape> jelmer: hmm, I must have done something slightly odd, because now subsequent commits are now blocked. Getting errno 13: Permission denied. I don't see any lock files in the branch-lock directory under .bzr.
[14:16] <jelmer> urbanape: are you sure it's bzr that's blocked, not gpg?
[14:36] <Chex> hello there, can someone help me with a bzr branch issue I am having, trying to deploy branches for ISD ?
[14:36] <Chex> jelmer: I was given your name to try to see if you could help me. :)
[14:37] <jelmer> Chex: hey!
[14:37] <jelmer> Chex: Of course, happy to help
[14:37] <Chex> jelmer: awesome, thank you.. look here: https://pastebin.canonical.com/51102/
[14:37] <Chex> and here, for related info: https://bugs.launchpad.net/config-manager/+bug/823010
[14:39] <Chex> jelmer: this is a private branch, you wont be able to pull it yourself, but the account we are using has proper access to the branch
[14:58] <gour> is colo-branches same thing as hg's named branches?
[15:01] <jelmer> hi gour
[15:02] <gour> jelmer: hiya
[15:02] <jelmer> gour: in some regards
[15:02] <gour> I'm now pulling via bzr-hg from google
[15:02] <jelmer> gour: it's not exactly the same thing, but they both allow using multiple branches under one file system location.
[15:02] <jelmer> gour: did 2.4 work any better for the large branch for you yesterday?
[15:03] <gour> jelmer: not much...i killed it...however repo @google is 24M..it makes a difference
[15:04] <gour> it was more speedy, but still too slow
[15:05] <gour> ahh...conection with google dies after 8mins
[15:05] <jelmer> gour: well, it's almost 600Mb of compressed data
[15:06] <gour> jelmer: right...it's big repo
[15:06] <gour> now tryingto pull from google with 2.4
[15:07] <gour> otoh, hg's named branches are cool...they're, iirc, in mtn, fossil
[15:08] <jelmer> gour: branch nicks in bzr are pretty similar
[15:08] <jelmer> gour: when tracking what branch a revision came from
[15:08] <jelmer> colo-branches is more like git branches
[15:08] <jelmer> the combination gives you something similar to hg branches
[15:09] <gour> hmm...it looks i've to re-read bzr docs a bit
[15:09] <gour> based on taht i read in hg docs, bookmarks are similar to git branches
[15:10] <jelmer> gour: that's hg bookmarks probably, though?
[15:10] <gour> yes, hg bookmarks
[15:13] <gour> too bad LP does not have project wikis like bitbucket...
[15:13] <jelmer> there was somebody working on that
[15:13] <jelmer> jml: do you know how far that's gotten?
[15:14] <gour> well, bug is quite old and still not on horizon (low priority)
[15:15] <gour> jelmer: how do bzr & hg compare today, considering 2.4 & 1.9.x ?
[15:15] <gour> (in general)
[15:15] <jelmer> gour: There was a community developer actively working on it a month or two ago
[15:16] <jelmer> gour: I'm not sure, my familiarity with hg doesn't really extend beyond the lower levels
[15:20] <gour> ok
[15:21] <jelmer> vila: when is 2.4.0 scheduled for?
[15:21] <gour> pulling with bzr-hr from google is slow..
[15:22] <jelmer> gour: sure, bzr-hg is still fairly experimental and not really optimized yet
[15:22] <vila> jelmer: next Tuesday
[15:23] <jelmer> vila: roger
[15:23] <vila> jelmer: if pqm can handle the load :-/
[15:23] <vila> err :)
[15:26] <jml> jelmer: how far what?
[15:26] <jelmer> jml: the wiki LEP, do you know what happened to it?
[15:28] <jml> jelmer: yeah. it's finished & rotting.
[15:28] <jelmer> jml: :-(
[15:29] <jml> jelmer: I didn't expect otherwise. Long drawn-out conversations about how we should do something that no one is actually planning to do tend to end this way.
[15:29] <gour> ok...16mins...let's try to push to LP now
[15:37] <jelmer> jml: I guess it means at least we have *some* idea of the constraints and requirements
[15:39] <jml> jelmer: yeah, I hope so. Although until people are actually using it, it's all just waste.
[15:49] <urbanape> jelmer: not sure. But removing arguments from my vc-bzr-gpg script so that it just calls '/usr/bin/gpg $@' doesn't clear it up, and adding -v to the bzr ci doesn't offer any more information.
[15:53] <mthaddon> anyone able to help me troubleshoot the new PQM server?
[15:54] <mthaddon> getting https://pastebin.canonical.com/51118/ and test suite has been running for 50 mins or so
[16:05] <vila> mthaddon: for bzr ?
[16:06] <mthaddon> vila: yeah, for the new bzr pqm server
[16:07] <vila> 50mins is not unusual
[16:07] <vila> the warnings are a bit worrying though, pqm needs some update obviously
[16:07] <mthaddon> vila: but this is on much faster hardware, with nothing else happening on the box
[16:08] <vila> do you have /tmp on a tmpfs ?
[16:08] <mthaddon> vila: it's running the same version of PQM as the current PQM instance
[16:08] <mthaddon> vila: nope (nor does the current one)
[16:08] <mthaddon> (will be doing that later once we get one successful run)
[16:08] <vila> huge boost for bzr test suite, but you're the judge
[16:09] <vila> anyway, there should be one or two files to track progress, let me check the makefile
[16:09] <vila> 'selftest.log' in the directory where the command run
[16:10] <vila> mthaddon: running 'subunit-stats < selftest.log' may even gives you a summary
[16:11] <mthaddon> vila: that doesn't seem to have updated since 2011-07-27...
[16:11] <mthaddon> nm, my mistake
[16:11] <vila> np
[16:12] <mthaddon> vila: https://pastebin.canonical.com/51122/
[16:15] <vila> mthaddon: something bad is going on, NoSuchFile in _check_safety_net... doesn't make sense
[16:15] <mthaddon> vila: what kind of bad?
[16:15] <vila> unless the tmp dir was deleted before the end of the run ???
[16:15] <vila> mthaddon: a kind I don't understand
[16:16] <vila> check_safety_net is there to protect against some test bugs, but I almost never see it fail
[16:17] <vila> spiv changed it recently IIRC but that was for performance reasons and I never see it fails either
[16:17] <vila> mthaddon: does /tmp/testbzr-W7TYpR.tmp/ exists ?
[16:18] <mthaddon> vila: https://pastebin.canonical.com/51124/
[16:18] <vila> -R ?
[16:19] <mthaddon> https://pastebin.canonical.com/51125/
[16:21] <vila> mthaddon: do you get the same result if you do that again ? (ls I mean)
[16:21] <vila> a lot of files are missing there
[16:22] <vila> and dirs
[16:22] <mthaddon> yeah, same result
[16:23] <vila> mthaddon: my best guess would be that something went wrong very early in the test suite and failed to build the safety net (a bzr tree that no test should modify)
[16:24] <vila> and now all tests fail because the net has been damaged (in fact, it looks like a branch lock failed halfway)
[16:24] <vila> mthaddon: but that's a wild guess as I said, I never saw such a failure
[16:24] <mthaddon> hmm
[16:24] <vila> mtaylor: the begining of selftest.log may shed some light ?
[16:27] <vila> mtaylor: sry, silly auto-completion
[16:27] <vila> mthaddon: the begining of selftest.log may shed some light ?
[16:29] <mthaddon> vila: chinstrap:~mthaddon/selftest.log.gz
[16:36] <micahg> does bzr + pristine-tar have the ability to reproduce .bz2 tarballs?
[16:36] <vila> mthaddon: wow
[16:36] <vila> KeyError: 'getpwuid(): uid not found: 2005
[16:36] <maxb> micahg: Yes, I think it's just .xz that's the problem at the moment.
[16:37] <micahg> hmm, ok, I guess it was a bad merge-upstream then...
[16:37] <vila> mthaddon: and indeed it was in _create_safety_net
[16:37] <mthaddon> vila: so is that an environment issue, or a test suite issue?
[16:38] <vila> mthaddon: I suspect it's a chroot issue as we are trying to expand ~ and fails
[16:38] <vila> mtaylor: /etc/passwd missing entries in the chroot kind of stuff
[16:39] <mthaddon> vila: I think I can reproduce - thx, will get that fixed and retry
[16:40] <vila> mthaddon: cool, './bzr selftest -s bb.test_add.TestAdd.test_add_control_dir' in the chroot should reproduce it without running the full test suite
[16:40] <mthaddon> k
[16:43] <jelmer> maxb: .xz should work too, it's just fairly inefficient because pristine-tar doesn't have proper support for xz
[16:43] <jelmer> micahg: are you running oneiric?
[16:44] <micahg> jelmer: not on the machine I was doing this on
[16:44] <jelmer> micahg: there's a bug with bz2 support in natty, that might explain the issue you were seeing
[16:45]  * micahg tries in oneiric
[16:47] <micahg> jelmer: nope, still fails to make a .bz2 tarball
[16:48] <jelmer> micahg: what fails exactly?
[16:48] <micahg> jelmer: I have no guarantee a bz2 tarball was even imported into the branch
[16:48] <micahg> it makes a .orig.tar.gz
[16:48] <jelmer> micahg: what command are you running?
[16:49] <micahg> bzr bd  --orig-dir=../tarballs/
[16:50] <jelmer> micahg: how was the upstream tarball imported into the branch?
[16:50] <micahg> no idea
[16:50] <jelmer> micahg: it's likely that it went wrong there
[16:50] <micahg> supposedly using bzr merge-upstream, will have to find out later, too close to FF to debug
[16:50] <jelmer> micahg: is the branch public?
[16:51] <micahg> jelmer: let me get some more information from the committer and get back to you, wouldn't want you to go on a wild goose chase
[16:53] <jelmer> micahg: thanks
[18:13] <jml> mgz: this bytes/unicode thing is doing my head in
[18:13] <mgz> ehhee
[18:14] <mgz> jml: and if you've not read PEP 383 yet, which poolie linked the other day, know that it only gets messiuer
[18:14] <mgz> -u
[18:15] <mgz> I think testtools is basically there, on a hard problem, apart from two things
[18:15] <jml> I haven't.
[18:16] <mgz> 1) Matcher and Mismatch classes need to not use %s, specifically StartsWith and MatchesRegex
[18:17] <mgz> 2) __str__ on Python 2 should mangle to ascii rather than return unicode and blow things up
[18:17] <jml> Ahhh, you *say* that.
[18:18] <mgz> testtools can be smart and try __unicode__ first, and other if the objects leak into other less careful libraries they won't be harmed
[18:18] <mgz> in fact, testtools already is smart.
[18:18] <jml> mgz: you mean something like http://paste.ubuntu.com/663608/?
[18:19] <mgz> I'd have spelled it differently, but yup, looks about what I was thinking
[18:19] <mgz> did it cause issues?
[18:20] <mgz> the only issue remaining from there is to not let non-ascii bytestrings in, which is why StartsWith etc needs chaning
[18:20] <jml> mgz: yeah
[18:20] <mgz> *changing
[18:20] <jml> mgz: even on Equals(), you get an unprintable assertion.
[18:21] <mgz> that's the describe() return issue.
[18:23] <mgz> I think it might be best to check the type in that __unicode__ function and do something similar to how bytes() get repr-ed in Python 3, rather than trying to fix every method...
[18:23] <mgz> hm.
[18:24] <jml> http://paste.ubuntu.com/663616/ for something to muck around with.
[18:24] <mgz> yup, that's the kind of assertion that we want to work for people.
[18:25] <mgz> okay, I'll think a bit and throw some code up
[18:25] <mgz> ...not as in vomit, though I don't guarentee it won't look like that
[18:25] <jml> http://paste.ubuntu.com/663619/
[18:26] <jml> more data
[18:26] <jml> mgz: heh heh
[18:26] <jml> mgz: also, I didn't really know how to turn your demo tests into actual tests.
[18:27] <jml> mgz: just pushed up my latest changes, fixes the _exception_to_text abstraction violation.
[18:28] <jml> mgz: but, however you choose to project your code onto the internet, it would be much appreciated.
[18:31] <mgz> yeah, I left the demo file as was because getting into another layer of assertions gets really confusing, it's clearer to just see the output as a testtools user would
[18:31] <jml> fair enough
[18:31] <mgz> tests for the things that then make those cases work as intended are writable
[18:32] <mgz> (what type the describe() method returns on non-ascii mismatches etc)
[18:32] <jml> cool. I tried naively turning them into tests, and they all passed, which isn't really what we want.
[18:32] <jml> yeah
[18:32] <jml> fwiw, https://bugs.launchpad.net/testtools/+bug/686807 might be relevant
[18:32]  * mgz looks
[18:34] <mgz> yeah, that change could probably just be made, the __str__ methods already return things that should work as object creation code, and str() falls back to repr()
[18:36] <mgz> ids in reprs only matter when the object identity is significant, newer Python code tends to omit them from the repr string when the objects are interchangable
[18:37] <mgz> repr(Exception("whatever")) has gone from '<exceptions.Exception instance at 0x00B097D8>' to "Exception('whatever',)"
[18:43] <jml> cool
[18:43] <jml> I might do that post release
[18:44] <jml> (I want to have this assertThat bug fixed for the next release though)
[18:44] <jml> I also just tried to reproduce the only remaining critical bug (https://bugs.launchpad.net/testtools/+bug/672056) and failed.
[18:45]  * jml goes to make some dinner
[18:46] <mgz> me too :)

[18:47] <mgz> ^I have hope that the issues involved in that bug have been seperately resolved,
[18:48] <jml> mgz: me too. I'm going to give Thomi a few days to reproduce the bug, and close it if he doesn't respond.
[21:08] <matttbe> Hello jelmer.
[21:08] <matttbe> micahg said to me that I've to chat with you about a bzr issue.
[21:08] <matttbe> I used this command (I think but pretty sure, on natty but it was with another computer...)
[21:08] <matttbe> bzr merge-upstream --version 2.1.1 --distribution=oneiric http://ftp.gnome.org/pub/GNOME/sources/latexila/2.1/latexila-2.1.1.tar.bz2
[21:08] <matttbe> And it seems that if 'bzr bd' is used to create the source package, it creates a .tar.gz tarball from bzr instead of a .tar.bz2. So a problem to import the right package.
[21:12] <micahg> merge proposal with branch here: https://code.launchpad.net/~latexila/ubuntu/oneiric/latexila/2.1.1/+merge/70964
[21:31] <jelmer> sorry, was away for a bit
[21:31] <jelmer> matttbe: thanks
[21:53] <poolie> hi all
[21:56] <jelmer> moinmoin
[22:03] <poolie> hi mgz
[22:03] <mgz> hey poolie!
[23:18] <jimis> How can I switch branch on a lightweight checkout, but keep uncommitted changes in that branch for when I come back? The only way I've found is shelve everything, unshelve when I switch back...
[23:18] <jimis> But can't I somehow tell switch to preserve local changes, and do it in one step?
[23:22] <spiv> jimis: oh, you mean you want the uncommitted changes to be hidden until you switch back?
[23:23] <spiv> jimis: shelving and unshelving is currently the best way to do what you want, I think.
[23:23] <spiv> jimis: It would be fairly easily to write a switch-and-auto-shelve plugin to automate that, I think.
[23:24] <spiv> (it'd override the 'switch' command to first shelve uncommitted changes to a shelf named after the current branch, do the switch, then unshelve from the shelf corresponding to the new branch)
[23:25] <jimis> thanks spiv
[23:25] <jimis> would be very useful as a switch option too
[23:25] <jimis> --shelve for example
[23:26] <spiv> jimis: hmm, could be.  File a bug asking for the feature :)
[23:26] <spiv> jimis: (just paste in this IRC chat as the description if you want to be lazy)
[23:27] <jimis> spiv: the reason it's important for changes to be hidden when switching, is avoid unwanted conflicts
[23:27] <spiv> That said, a good way to prototype that feature would be to write the plugin :)
[23:27] <jimis> I've had such conflicts before and it took lot of my time
[23:28] <spiv> jimis: hmm, I think that's just as much an argument for a cheap way to undo the switch (and its conflicts)
[23:28] <jimis> spiv: that's doable?
[23:28] <jimis> it would be a live-savour, for *after* the conflict happened :-p
[23:29] <spiv> jimis: or perhaps an argument for being able to shelve the original changes after the switch
[23:29] <jimis> whatever
[23:29] <spiv> (i.e. a way to say “please shelf the unconflicted changes I had a moment ago”)
[23:29] <spiv> I think it's doable, I don't think it's *easy* currently.
[23:29] <jimis> but after the conflict, you are left with various files injected with conflict marks etc... it's a mess
[23:29] <spiv> Yeah, I know the feeling.
[23:30] <jimis> yeah, that's why I think it's better to watch out during the switch
[23:30] <spiv> And often you don't realise that conflicts are going to be messy until after you've got them.
[23:31] <jimis> I'd personally advocate for shelving on switch always and transparently, and only taking changes with you if you provide a special flag to switch
[23:31] <jimis> but I don't think current behaviour can be broken :-s
[23:31] <spiv> A cheap-ish alternative might be an option on switch to abort (and undo) if there are going to be conflicts
[23:31] <jimis> true
[23:32] <spiv> And then you can either commit/shelve/revert/whatever, or you can pass a --force or --allow-conflicts switch to say “that's ok, I'll cope”
[23:32] <jimis> Will submit feature request later, hopefully I'll find some time
[23:32] <spiv> In fact, 'bzr merge' already behaves somewhat like that
[23:32] <spiv> You have to --force for it to even start in the presence of uncommitted changes.
[23:32] <jimis> I wonder why switch is that dangerous...
[23:33] <spiv> (Although the rationale for merge doing that is not quite the same, there is some overlap)
[23:33] <jimis> probably because most people work with multi-directory branches, not single-dir checkouts
[23:33] <spiv> Yeah
[23:34] <spiv> Although as bzr-colo becomes more popular (and is slowly integrated into the core), your workflow will be more common.
[23:34] <jimis> but when you have huge projects with thousands of files, checkouts are one-way
[23:34] <spiv> Right
[23:34] <jimis> spiv: are you on the bzr team?
[23:36] <jimis> Because I wonder if any dev agrees with my experience
[23:38] <spiv> jimis: yes (was a fulltime developer working for Canonical until a couple of weeks ago, have just switched jobs but I still care and have commit rights etc)
[23:38] <jimis> cool
[23:39] <spiv> jimis: I'm pretty sure most, maybe all, the core devs agree with you that we should do better for that case
[23:41] <spiv> And there's been serious talk about switching to single-dir checkouts as the default way of working in a future release (i.e. integrating and polishing the bzr-colo plugin into the core, and then promoting its workflow to be more prominent than the current multi-dirs of branches in shared repo model)
[23:41] <jimis> very interesting
[23:41] <spiv> Obviously we'd want to smooth out as many kinks as possible before doing that, including yours :)
[23:41] <jimis> single-dir checkout of a no-trees branch is my current way
[23:42] <jimis> It's the only usable way for huge branches like lp:gcc
[23:42] <spiv> Right.
[23:42] <jimis> but I've never used colo plugin
[23:42] <jimis> generally I tend to avoid installing extras
[23:42] <spiv> bzr-colo is basically intended to make that a bit nicer to use
[23:53] <kwmiebach> Hi. I have used "bzr fetch ..." from a launchpad repository. How can I switch to an earlier revision locally?
[23:54] <kwmiebach> Lets say I am aat rev. 500 now and would ike to see rev 450
[23:56] <spiv> 'bzr pull -r 450 .'  (the dot is significant, it says to pull from the branch in the current directory, which will be a bit faster than looking for that same revision on the remote branch)
[23:57] <spiv> Depending on what you want to do,
[23:57] <spiv> 'bzr update', 'bzr revert', 'bzr cat', or 'bzr qlog' (that one from the qbzr plugin) may be better suited to your needs though.
[23:58] <kwmiebach> spiv, thank you so much, couldnt find it in the docs.
[23:58] <kwmiebach> i will go and try now