[00:53] <spiv> Good morning.
[01:02] <poolie> hi spivvo!
[01:02] <poolie> nice to see pjkeating getting an outing again
[01:13] <poolie> jelmer, do you know off hand how many importer branches have succeeded?
[01:35] <wallyworld_> poolie: did you know "bzr xmlls" is broken on natty?
[01:36] <poolie> that's from bzr-xmloutput?
[01:36] <poolie> i did not
[01:37] <wallyworld_> poolie: it's a python 2.7 incompatibility. i'll raise a bug
[01:38] <wallyworld_>   File "/usr/lib/python2.7/dist-packages/bzrlib/plugins/xmloutput/xml_errors.py", line 30, in __str__
[01:38] <wallyworld_>     _escape_cdata(str(e))
[01:38] <wallyworld_> TypeError: _escape_cdata() takes exactly 2 arguments (1 given)
[01:38] <wallyworld_> well i think it's python 2.7 related. haven't really looked into it
[01:39] <wallyworld_> it worked fine before i upgraded to natty
[01:41] <jelmer> poolie: Sorry, was afk. I'm not sure how many successful imports we have.
[01:42] <poolie> np, i took a reasonable guess
[01:42] <poolie> have a good night
[01:42] <jelmer> wallyworld_: I'm pretty sure that's been fixed in trunk, any chance you can give lp:bzr-xmloutput a try?
[01:42] <poolie> wallyworld, bug 732881
[01:42] <poolie> thought it rang a bell
[01:42] <wallyworld_> jelmer: sure can. i'm just finishing up something. will do it soon. thanks for letting me know :-)
[01:43] <jelmer> poolie: That's the plan :)
[01:43] <jelmer> ttyl
[01:43] <poolie> :) cheerio
[01:52] <wallyworld_> poolie: jelmer: xmloutput works fine from trunk. thanks!
[02:38] <spiv> poolie: Hey :)
[02:38] <spiv> poolie: ah, I guess freenode shenanigans or something kept you from seeing me earlier.
[02:39] <poolie> hi there
[02:39] <poolie> ah i wondered if it was something like that
[02:39] <poolie> either that or you'd abandoned 90s irc technology for tweeting
[02:39] <spiv> Hah.
[02:42] <poolie> how are the failures?
[02:43] <spiv> The LP workaround has passed ec2 and so landed on lp:launchpad
[02:44] <poolie> ok, and i guess will go live on the next downtime rollout?
[02:44] <spiv> I guess so
[02:45] <spiv> Hmm
[02:46] <spiv> I assume code changes on codehosting ssh aren't rolled out until there's downtime to restart the service
[02:46] <spiv> But because it's really split into the 'listens on ssh port' process and the 'bzr lp-serve' worker processes, in principle improvements to the latter could often be deployed without restarting the former.
[02:47] <poolie> yeah
[02:48] <poolie> ok, and so now ... the twisted upstream fix?
[02:48] <spiv> I guess when the ssh service can be brought down gracefully by being run behind haproxy there won't be as much incentive to try take advantage of that.
[02:48] <spiv> s/brought down/upgraded/
[02:48] <spiv> Is still waiting for a hopefully final review.
[02:49] <spiv> All the review points so far have been addressed.
[02:49] <poolie> great
[02:51] <poolie> i guess i will look into this possible whoami related selftest regression first
[02:51] <poolie> since a lot of other outstanding stuff hangs off that
[02:52] <poolie> how about you?
[02:52] <spiv> Patch piloting
[02:52] <spiv> As opposed to jelmer, who's been patch bombing ;)
[02:57] <poolie> :)
[02:57] <poolie> he certainly has
[02:57] <poolie> john too
[02:57] <poolie> good idea
[04:11] <spiv> poolie: hmm, hydrazine is now broken for me on maverick
[04:11] <spiv> TypeError: login_with() got an unexpected keyword argument 'application_name'
[04:12] <spiv> I do want to upgrade to natty quite soon, but perhaps not *right now* ;)
[04:13] <poolie> :/
[04:14] <poolie> i guess it needs some version-conditional code then
[04:14] <poolie> could you have a go at it?
[04:16] <spiv> I took a quick stab at backing out just that one revision to see the difference and got a surprisingly large conflict, so I just reverted to the version I was using before.
[04:16] <poolie> ok i'll try when i can get unity going
[05:20] <poolie> spiv could you glance at https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/55872
[05:26] <spiv> glanced, and approved :)
[05:26] <poolie> thakns
[07:33] <vila> Heigh Ho, Heigh Ho, hi all !
[07:35] <fullermd> OK, you've exhausted your allocated supply of "h"'s for the day...
[07:35] <spiv> vila: ¡hola!
[07:36] <vila> fullermd: I don't tink so
[08:16] <jam> i vila, ow's it going?
[08:16] <jam> fullermd: I tink e stole mine
[08:16] <vila> hehe
[08:17] <fullermd> jam: Try substituting an aitch.
[08:17] <vila> fullermd: fail
[08:17] <fullermd> I gotta stick with my strengths...
[08:18] <jam> I'm surprised ow readable tings are witout te letter. I say we get rid of it. It clearly is 'arming the language
[08:19] <jam> sucks, missed one
[08:19]  * fullermd invokes Mark Twain...
[08:19] <jam> fullermd: I do like that quote
[08:19] <fullermd> "Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld."
[08:19] <vila> dunno if it exists for English but I remember a text about mutating French to simplify it
[08:20] <vila> fullermd: yeah, like that ;)
[08:20] <jam> fullermd: I can probably read 90% of that, enough to understand it.
[08:20] <jam> A bit like reading Dutch for me :)
[08:21] <vila> this also reminds me of Perec who managed to write a book without the letter 'e'...
[08:21] <fullermd> If we'd just switch over to Lojban and be done with it..
[08:21]  * spiv h̶mms
[08:21] <vila> . o O (Probably never translated ;)
[08:21] <jam> vila: hard to write his name, though
[08:22] <vila> jam: hehe, good point, I wonder if he used a pseudo :)
[08:22] <fullermd> Authors are best kept out of their work anyway   :p
[08:23] <vila> te autor
[08:24] <vila> zomg, they *did* translate it: http://en.wikipedia.org/wiki/A_Void
[08:26] <vila> all: poolie said hi !
[08:28]  * fullermd turns up the music and drags himself back to pretending to work.
[08:29] <jam> vila: sure, but http://en.wikipedia.org/wiki/Gadsby_(novel) was done 30 years earlier
[08:30] <vila> fullermd: not so fast ! What about http://pycon.blip.tv/file/4878868/ ? Can FreeBSD do that ?
[08:30] <fullermd> Show me a big grey box saying something about a plugin that would crash my browser regularly if it existed?  Looks like...
[08:30] <vila> . o O (Totally unrelated but worth trying to distract fullermd )
[08:30] <jam> vila: well, he did it on a mac, which is technically just a glorified BSD machine, right?
[08:30] <vila> jam: don't spoil it ! ;D
[08:31] <vila> jam: what with Gatsby ? (Obviously I don't know)
[08:31] <jam> vila: and there is http://en.wikipedia.org/wiki/Lipogram
[08:31] <jam> describing earlier works as well.
[08:31] <jam> vila: Gadsby was the first long text without the letter E
[08:31] <vila> hoooo, I didn't know that
[08:32] <vila> interesting... sort of ;) Hackers all over the place ;D
[08:32] <jam> vila: "Hamlet without the letter I".
[08:32] <jam> To be or not to be, that's the query
[08:32] <jam> (since question has an I)
[08:32] <fullermd> Eh.  You haven't experienced Shakespeare until you've read it in the original Klingon.
[08:33] <vila> wow 'the quick brown fox...' omits S !
[08:34] <spiv> jumps?
[08:34] <jam> http://en.wikipedia.org/wiki/The_Klingon_Hamlet
[08:35] <vila> spiv: The quick brown fox jumped over the lazy dog
[08:35] <jam> I'm pretty sure the full "quick brown" text has all English letters
[08:35] <vila> could be
[08:35] <jam> as it is supposed to be a text for showing typography
[08:35] <fullermd> Yeah, I gave my mother a copy for Christmas some years back.
[08:35] <jam> http://en.wikipedia.org/wiki/The_quick_brown_fox_jumps_over_the_lazy_dog
[08:35] <vila> yup, may be just a variant to explain lipogram
[08:36] <vila> ok, back to liprogramming config without the letter 'bug' :D
[08:41] <vila> jam: by the way, congrats on your efforts around the sha1s !
[08:41] <jam> vila: thanks
[08:42] <jam> unfortunately, I still need to track down all the other paths
[08:42] <jam> like merge
[08:42] <jam> and revert
[08:42] <jam> and ...
[08:42] <vila> jam: I'm not surprised :-/
[08:42] <jam> I could cheat and recompute the sha1 in create_file, but that would just move the processing time around.
[08:42] <vila> jam: feel free to find shortcuts along the way !
[09:06] <jam> vila, jelmer, spiv: Are we doing the standup now?
[09:07] <vila> jam: I think it was decided to do it tomorrow (as an exception)
[09:08] <jam> vila: I think you're right
[09:08] <jam> I always have trouble with "you have a meeting" emails
[09:08] <jam> for some reason the *date* of the meeting is never clear to me
[09:08] <vila> jam: easy short, I did accept the invitation this night :) You made me doubt about the *week* ;)
[09:09] <vila> s/short/shot/
[09:09] <jam> yeah, it definitely has @ Thu
[09:09] <jam> I just need to pay more attention :)
[09:50] <jelmer> looking at the date isn't a guarantee, I've seen a few evolution timezone bugs ;)
[11:07] <fullermd> Gaah.  And once again, I waste a bunch of time because of bug 315399  :(
[11:24] <hrw> hi
[11:26] <hrw> will there be bzr-fastimport 0.10.0 package for ubuntu natty?
[11:28] <vila> fullermd: any chance you can point to a public branch allowing to reproduce (for the record ?)
[11:38] <fullermd> Not that I know of.
[11:39] <jelmer> hrw: it's not planned; we should be able to get the new snapshot from Debian synced if there's a good reason to
[11:42] <hrw> jelmer: trying to get git-bzr-ng working again - it lists 0.10.0 as requirement
[11:43] <jelmer> hrw: natty has a 0.9 snapshot IIRC, I think it has the fixes required by git-bzr-ng
[11:44] <hrw> jelmer: bzr: ERROR: unknown command "fast-export"
[11:46] <hrw> http://paste.ubuntu.com/590170/ is whole output
[11:47] <jelmer> hrw: does "bzr plugins" list the fastimport plugin?
[11:48] <hrw> ha! nice catch. http://paste.ubuntu.com/590175/ shows that it is installed but bzr does not know that
[11:52] <hrw> but why it happened? no idea
[11:54] <vila> hrw: python version mismatch ?
[11:55] <hrw> vila: fastimport landed in /usr/lib/pymodules/python2.7/bzrlib/plugins/ when all other plugins are in /usr/lib/python2.7/dist-packages/bzrlib/plugins directory
[11:56] <hrw> this is under natty (which was upgraded from maverick in beginning of development cycle)
[11:56] <vila> hrw: 'bzr plugins -v' will tell you where plugins have been  found
[11:57] <hrw> vila: already used -v to find where normally they reside. only bzr-fastimport got into other place
[11:57] <vila> hrw: I'm not *that* familiar with packaging to say what the right directory is, but it's weird that two different ones are used (not counting link farms)
[11:59] <jelmer> I bet it's the switch to python-support that's related
[12:00] <hrw> jelmer: sure. but why bzr does not check python-support dirs too?
[12:00] <vila> hrw: could be a bug in packaging, you're using the daily ppa ? (Obviously no: bzr-fastimport 	0.9.0+bzr311~ppa129~natty1  there)... where did your package come from ?
[12:01] <jelmer> hrw: bzr simply uses the standard python import mechanism
[12:01] <vila> ha, no, you're using stock natty
[12:01] <hrw> vila: plain natty package
[12:02] <vila> yup, rmadison told me
[12:02] <hrw> anyway - symlinked it to ~/.bazaar/plugins/fastimport for now
[12:02] <jelmer> hrw: it's definitely some sort of packaging issue, any chance you can file a bug?
[12:02] <vila> you meant s/to/from/ ?
[12:03] <hrw> vila: ln -sf /usr/lib/pymodules/python2.7/bzrlib/plugins/fastimport/ ~/.bazaar/plugins/fastimport/
[12:03] <vila> but yeah, easiest work-around if you don't want to put a branch there
[12:03] <hrw> jelmer: sure
[12:04] <jelmer> vila: what's the problem with try/finally in tests?
[12:04]  * vila nods ln -s will confuse me until my death, there is no way I will get it right now after getting it wrong for the past 30 years
[12:04] <vila> jelmer: error-prone, less clear generally
[12:05] <vila> jelmer: there are some exceptions but as a rule, avoiding them is generally better
[12:05] <jelmer> vila: I understand less clear, but in what way is it error-prone?
[12:05] <jelmer> I don't have any objection to using self.addCleanup(), just curious.
[12:05] <vila> hmm, yeah, what did I mean...
[12:06] <vila> you can define the try/finally scope wrongly
[12:07] <jam> jelmer: try/finally also tends to lead to terrible scopes when you have 3-4 of them
[12:07] <vila> or more generally forget it, whereas using addCleanup *unless* you can't wait the end of the test to cleanup is generally safer
[12:07] <jelmer> ah, fair enough
[12:07] <vila> jelmer: so it's kind of error-prone to *not* use addCleanup
[12:08] <vila> jelmer: which may be more precise than saying try/finally is error-prone
[12:08] <vila> jelmer: yeah, I think that's what I meant :D
[12:09] <vila> zomg, when did the ppa pages got the stop signs in 'Latest updates' ?
[12:10] <vila> for ever but I never look at the page while failures where pending ?
[12:10] <spiv> jelmer: the two basic problems with try-finally vs. addCleanup are
[12:11] <hrw> jelmer: bug 752396
[12:11] <spiv> 1) if the cleanup is distant from the initial action (i.e. many lines away) it's easier for skew between those to be missed, and
[12:11] <jelmer> hrw: thanks, marked confirmed
[12:12] <spiv> 2) an error in a finally block will override a prior error
[12:12] <hrw> git-bzr-ng now works in both directions - finally no need to touch bzr directly ;D
[12:12] <spiv> So you can get e.g. TooManyConcurrentRequests or some odd pack exception rather than the actual problem.
[12:14] <spiv> And there's related things like if you have code like "if cond: foo.lock_read()" then you need to say "if cond: foo.unlock()" in your finally, so you're repeating yourself
[12:14] <jelmer> spiv: that makes sense, thanks
[12:14] <spiv> Basically, default to using addCleanup everywhere it's conveniently available… and if it's not conveniently available, consider using it anyway ;)
[12:15] <vila> jelmer: and I don't remember a case where migrating from try/finally to addCleanup made the test harder to read or maintain
[12:15] <vila> jelmer: but a lot of cases where it fixed some nasty bugs
[12:16] <jelmer> just to be clear, I'm not arguing for try/finally, I was only wondering why addCleanup is better.. I think I know now :)
[12:16] <vila> well, may be no a lot, but some lock checks failures were fixed this way
[12:17] <vila> jelmer: I think you got a good summary :)
[12:28] <jam> vila: some more "Welcome to Europe" things for you.
[12:29] <jam> 1) The EU "Queen" size is 8cm wider than the US one.
[12:29] <jam> (for matresses)
[12:29] <jam> so it isn't a trivial "buy a split foundation". We did so, and now it doesn't fit with the frame, etc.
[12:29] <jelmer> jam: isn't it supposed to be the other way around?
[12:29] <jelmer> generally stuff is larger in the US :)
[12:29] <jam> jelmer: that's what they say :)
[12:30] <jam> 2) ... dang, I swear I had 2
[12:30] <jam> jelmer: http://en.wikipedia.org/wiki/Mattress
[12:30] <jam> has a big table of "crazy" sizes
[12:31] <jam> apparently UK has yet-another standard set of sizes
[12:31] <jam> I believe the phrase is "Standards are great, we should clearly have more of them"
[12:31] <jelmer> heh, indeed :)
[12:31] <jam> jelmer: apparently the US "King" size is bigger. 193cm vs 180cm.
[12:32] <jelmer> jam: At least this is standardised, so many things are still different across EU countries
[12:33] <jam> jelmer: of course as mentioned, depends if UK is part of the EU or not :)
[12:33] <jelmer> jam:
[12:34] <jelmer> I don't really think they are :)
[12:35] <vila> jam: 8=/
[12:35] <vila> Yup, I can confirm that, they aren't :D
[12:36] <jam> vila, jelmer: And AIUI neither is Switzerland or Czech, or ...
[12:37] <jelmer> jam: well, the UK is formally a part of the EU, just not in spirit :)
[12:37] <jelmer> jam: Switzerland is a part of some treaties (like Schengen, the customs treaty) but not of the EU
[12:39] <jam> jelmer: being able to half-join is like having yet-another-standard
[12:39] <vila> jam: oh, no, Switzerland, pfff of course not ;) You know, while the EU is far younger than the US, the family history if far longer and some episodes goes really far into the past ;)
[12:40] <vila> jam: can you imagine that the parliament is moved, twice a month, including all admin people and of course all of the paper archives ?
[12:42] <jelmer> vila: good business for Strasbourg though, no? :)
[12:43] <jam> wow, seems crazy
[12:43] <jam> or like a rock-and-roll show
[12:43] <spiv> A parliament with roadies!
[12:43] <jam> spiv: just watch out for the groupies
[12:43] <spiv> jam: ITYM "public servants"
[12:43] <jam> :)
[12:44] <jam> spiv: and 'pay-to-play' politics
[12:46] <vila> jelmer: that's what they say ;)
[13:49] <jelmer> maxb_: Do you know if there was anything in the newer debhelper that we actually needed?
[13:51] <jelmer> nevermind
[13:58] <maxb_> jelmer: --buildsystem
[13:58] <maxb> and override_dh_foo
[14:00] <gypsymauro> hi
[14:00] <maxb> hello
[14:01] <gypsymauro> I'm trying to use the syntax bzr serve --port=localhost:1234 --directory=/srv/bzr/repo
[14:04] <gypsymauro> but when I try to bzr log bzr://localhost:1234/ .. does nothing
[14:04] <gypsymauro> any hint?
[14:05] <maxb> "does nothing" is not a helpful problem description. It certainly does something - even if that something is "hang" or "exit with no error and no output"
[14:06] <gypsymauro> it "hangs"
[14:07] <gypsymauro> even ctrl-c on server doesn't kill it
[14:08] <maxb> What is your platform? Linux?
[14:09] <gypsymauro> yes
[14:09] <maxb> If  you re-run the "bzr log" command adding the "-Derror" option, and Ctrl-C it after a while, what error do you get?
[14:09] <maxb> Whilst in the hung situation, can you see any tcp connections using "netstat -tn | grep 1234" ?
[14:10] <gypsymauro> tcp        0      0 127.0.0.1:41908         127.0.0.1:1234          ESTABLISHED
[14:10] <gypsymauro> tcp       85      0 127.0.0.1:1234          127.0.0.1:41908         ESTABLISHED
[14:11] <gypsymauro> so it seems a connection
[14:11] <gypsymauro> after ctrl-c noone error I waitd 5 mins
[14:16] <maxb> Please check the ~/.bzr.log file for any potentially useful information
[14:23] <gypsymauro> maxb: nothing usefull
[14:23] <gypsymauro> it's like is bzr serve that freezes
[14:31] <trond->  I'm using bazaar for webdevelopment of a service that I
[14:31] <trond-> (gr.) starting over
[14:32] <trond-> I'm using bzr for webdevelopment, and I have created a solution that is available for a few customers. I have branched those versions. Now, If I change something in one branch, and want this change to be available for the others, how do I do this?
[14:50] <jam> trond-: can you just go to the other branch and "bzr merge" the first one?
[14:57] <maxb> If you have multiple customer specific branches, it can be worth maintaining a central generic branch from you merge changes
[17:15] <jelmer> maxb: I'm considering splitting bzrlib.tests into its own (Arch: all) package
[17:15] <jelmer> maxb: it's 16Mb (vs 29Mb in all of bzrlib/)
[17:16] <maxb> gosh. Quite a saver. Sounds great, though we might need to patch other stuff to fail helpfully, I suppose?
[17:16] <jelmer> maxb: yeah
[17:17] <jelmer> AFAIK "bzr selftest" is the only thing that really imports from bzrlib.tests
[17:20] <maxb> Oh, and presumably anything that matters will already have a conditional to react nicely to the absence of python-testtools?
[17:20] <jelmer> maxb: presumably, but in practice that isn't actually the case
[17:20] <jelmer> nothing outside of bzrlib.tests uses testtools though
[17:21] <maxb> Oh
[17:21] <jelmer> one of the nice things of splitting bzrlib.tests out is that it can actually depend on python-testtools properly
[17:23] <maxb> Perhaps "No module named testtools" was sufficiently informative to class as "reacting nicely" in my head :-)
[17:23] <jelmer> heh, fair enough
[17:25] <maxb> OK, so we could either patch cmd_selftest upstream to say something like "The testsuite is not part of this bzr installation", or we could patch it in the packaging branch to suggest 'apt-get install python-bzrlib-tests' similar to what the debian mercurial package does for this sort of thing
[18:04] <jelmer> maxb: sounds reasonable to me
[20:40] <mrnuke> hi
[20:41] <mrnuke> I'd like to know how to merge two bzr branches, and keep the commit history from both branches
[20:42] <mrnuke> if I just bzr merge /path/to/other/bbranch, it discards the commit history from the other branch
[20:43] <luks_> it doesn't discard anything
[20:44] <mrnuke> so after bzr merge, I can simply bzr commit without fear?
[20:44] <luks_> but I think that bzr log doesn't display it by default (wow, it's been a long time since I used log)
[20:44] <luks_> you can use bzr log -n0
[20:44] <luks_> or better, bzr qlog
[20:44] <luks_> yes
[20:48] <mrnuke> oh, thanks :)
[20:48] <mrnuke> I was afraid to commit fearing the history would be lost
[21:58] <trond-> jam, ref my question and your reply - go to other branch and bzr merge. Do you mean go to the main code and merge, or to the branch and merge?
[21:58] <trond-> maxb, I agree. (central generic branch)
[22:19] <mwhudson> huh, this isn't how i expected bzr-hg to choke on pypy: http://launchpadlibrarian.net/68480618/mwhudson-pypy-hg-trunk.log
[22:19] <mwhudson> (for the click-shy it's "IOError: [Errno None] connection ended unexpectedly")
[22:19] <mwhudson> jelmer: hi :-)
[22:20] <jelmer> hey Michael :)
[22:21] <jelmer> mwhudson: I guess we wait too long reading all of the data and meanwhile the connection times out
[22:21] <mwhudson> yeah, i guess so
[22:22] <mwhudson> bitbucket have a really crappy router doing nat? :)
[22:24] <jelmer> mwhudson: we're too slow parsing hg data?
[22:25] <mwhudson> i guess that's a more realistic explanation yes
[22:31] <jelmer> mwhudson: can you file a bug? I don't think we have that one yet
[22:33] <mwhudson> jelmer: ok