[00:32] <jelmer> hi poolie
[00:32] <jelmer> Did you have a good easter weekend?
[00:33] <poolie> hi there
[00:33] <poolie> i did
[00:33] <poolie> how are you?
[00:34] <jelmer> I'm well too, we had amazing weather over the weekend
[00:34] <poolie> we had pretty much continuous rain
[00:34] <poolie> i'm leaving just under a week from today
[00:35] <poolie> for uds etc
[00:36] <jelmer> this was our hottest easter in recorded history, around 25 degrees
[00:36] <jelmer> hopefully we'll have similar temperatures in Budapest :)
[00:46] <poolie> 25C is nice
[00:46] <poolie> prague was quite hot
[00:53] <poolie> jelmer did you have any opinion about python 2.4/5/6
[00:55] <jelmer> poolie: not really
[00:55] <jelmer> poolie: I personally would like to move to 2.5, but I only have Debian Unstable and Natty machines...
[00:57] <jelmer> poolie: the input from various people running or packaging for older versions of RHEL or backporting to older versions of Ubuntu is probably most interesting
[00:58] <maxb> Where older versions of Ubuntu == just hardy, I think
[00:58] <poolie> it seems like the main issue is now py2exe
[00:58] <maxb> (assuming intrepid and jaunty are disregarded for being both EOL)
[00:58] <poolie> hardy has python2.5
[00:59] <maxb> Oh, yes. Sorry, I was still thinking about 2.6
[01:00] <poolie> np
[01:00] <spiv> Morning folks.
[01:00] <poolie> it's just a small additional thing in favor of 2.5
[01:00] <poolie> hi spiv
[01:00] <maxb> py2exe was a reason that 2.6 was bad but 2.5 was OK?
[01:04] <poolie> right
[01:10] <poolie> how was your weekend spiv?
[01:10] <jelmer> hi spiv
[01:15] <spiv> poolie: long :)
[01:27] <poolie> it was wasn't it?
[01:29] <mgz> ah, poolie.
[01:30] <mgz> oh, I should put up my alternative to jam's compat breaking branch if that's on the table for today
[01:54] <poolie> mgz: so you have a thing that fixes the same bug but without using try/yield/finally?
[01:54] <mgz> yup.
[01:54] <mgz> sec, nearly done, will post.
[01:55] <poolie> hm, i know we can fix them one by one
[01:55] <mgz> it defers the decision for a bit at least :)
[01:56] <poolie> otoh it is O(n) to keep reconsidering it every few months
[01:56] <mgz> jam's made some reasonable arguments, and august is still quite a few months of coding away, so I'm not sure I can really justify keeping the old version alive
[01:57] <mgz> but there was someone on rhel in here the other day looking for support who managed to mangle a (working) 2.4 trunk bzr by trying python 2.6
[01:57] <mgz> where the easy fix was just cleaning up and using 2.4 again (a plugin was broken)
[01:57] <poolie> what do you mean?
[01:58] <mgz> hm, I'd need to look at the log, but he was trying to install bzr.dev and didn't have pyrex on 2.6 and got some .so files from the wrong version.
[01:59] <poolie> ok i see
[01:59] <poolie> so he had a kind of half-installed python2.6,because that wasn't included in the original rhel release?
[01:59] <poolie> this does happen from time to time
[01:59] <poolie> especially on mac os it seems
[01:59] <mgz> http://irclogs.ubuntu.com/2011/04/25/%23bzr.html#t00:45
[02:00] <poolie> i'm not sure that it's all that correlated with what we require
[02:01] <mgz> I agree most people probably aren't trying to combine bleeding edge bzr with ancient python.
[02:02] <poolie> like if we require 2.4, people still sometimes trip up because they have a half-installed python2.5
[02:04] <mgz> sure, but in his case using the system python got it working again.
[02:04] <mgz> next week, bzr.dev will not work with his system python.
[02:06] <poolie> maybe we should ask emacs-devel
[02:07] <lifeless> poolie: btw I have bzr-search test suite failing with the maverick build
[02:07] <lifeless> poolie: I commented on the bug for you
[02:08] <mgz> lifeless: good work on py3ing subunit the other night
[02:08] <mgz> I filed a bug on the remaining failures I got, as they're a problem in trunk too
[02:08] <lifeless> cool, thanks
[02:08] <poolie> i saw the mail, i haven't looked into it yet
[02:09] <mgz> mostly shallow, but I have two problems
[02:09] <lifeless> mgz: you live in a yellow submarine?
[02:09] <mgz> #1 how do you want skips done? currently you're using unittest.TestCase which... I think I need to switch to testtools.TestCase for the skip method?
[02:09] <mgz> ^that would hardly be a problem
[02:10] <lifeless> sure, using testtools.testcase would be fine
[02:10] <mgz> well, coming up for air regularly might get old.
[02:10] <mgz> should I switch the whole file? or have a mix-and-match?
[02:11] <mgz> problem #2 ExecTestCase
[02:11] <lifeless> mgz: whatever you like is fine with me
[02:11] <mgz> the very concept is... problematic
[02:11] <lifeless> having bitten the bullet and depending on testtools, I've no intrinsic limits onuse
[02:12] <lifeless> well, exectestcase is clearly not for windows users :)
[02:12] <lifeless> erm
[02:12] <lifeless> actually
[02:12] <lifeless> isolatedtestsuite isn't
[02:12] <lifeless> exectestcase is
[02:12] <mgz> currently, the tests exec some python scripts (with the system python, not the one running subunit), and then fake-print some subunit looking output
[02:12] <mgz> ^yeah, exec could work, apart from the design is... I don't like it
[02:13] <mgz> getting shell script blobs from docstrings isn't very portable
[02:13] <mgz> anyway, the test fails (and leaks the streams) because neither end sets the pipe to binary
[02:14] <lifeless> heh
[02:14] <mgz> but just fixing that doesn't really make it any saner, and the paths are still wrong
[02:14] <lifeless> uhm
[02:14] <lifeless> so, I'd like to just fix it in the first instance
[02:14] <mgz> because you're doing path_join|(script_dir, shell_script_blob)
[02:15] <mgz> which happens to work for (".", "some_script.py -some_arg") -> "./some_script.py -some_arg"
[02:15] <mgz> but doesn't for arbitrary paths or commands.
[02:16] <mgz> so, you'd get failures depending on where your test suite was in your directory tree
[02:17] <mgz> (most specifically, if you had any shell-significant characters like spaces)
[02:29] <quotemstr> lifeless: Thanks.
[02:43] <lifeless> mgz: external scripts should be usint libsubunit or some other language binding
[02:43] <mgz> I agree.
[02:43] <lifeless> which sould set binary
[02:45] <mgz> making the sample scripts do that is hard though.
[02:45] <lifeless> yeah
[02:46] <mgz> okay, it's way too late, I need to get a train tomorrow.
[02:46] <mgz> night all!
[02:46] <lifeless> ciao
[02:47] <poolie> night mgz, hae a good break
[07:36] <bignose> yay, Gitorious lets me set up an account logging in via my existing OpenID!
[07:36] <bignose> that means I can have full-featured hosted Mercurial and Git repositories
[07:37] <bignose> the only one left is Launchpad <URL:https://bugs.launchpad.net/launchpad/+bug/210943>
[07:39] <bignose> does anyone have comments on using Gitorious or Bitbucket as back-end repository for Bazaar?
[07:43] <glyph> bignose: Neither is possible.
[07:43] <glyph> bignose: Maybe bitbucket is, but I'm not nearly crazy enough to try it :)
[07:56] <poolie> bignose: interesting; do you then give them an ssh key for actual access, or is it all over openid?
[08:01] <spiv> We should just provide HTTP-over-SSH ;)
[08:02] <poolie> o/ spiv
[08:02] <fullermd> I've got a friend who did some work on SSH-over-HTTP...
[08:03] <bob2> bitbucket least supports http push with passwords
[08:07] <poolie> hi jam
[08:08] <jam> morning poolie
[08:12] <poolie> thanks for all the bug cleanups
[08:12] <poolie> jam if your queue is getting reasonably empty i wondered if you could give some relief to bug 602614
[08:12] <poolie> maybe even just a config knob to delay repacking
[08:14] <jam> poolie: sure. My queue is actually filling up because of backlog stuff with TreeReference while I switch over to the fetch-sends-tags stuff.
[08:14] <jam> but I can put it on my 'stuff to get to' queue
[08:22] <poolie> jam i didn't really understand your last comment on gz's sftp traceback patch
[08:22] <poolie> > As for a focused 2.4 branch, that is ok, but really, I don't want to try
[08:22] <poolie> and "fix all hacks" before we break compatibility. I'd rather break it,
[08:22] <poolie> and then land things that cleanup the code as someone wants to do so. I
[08:22] <poolie> don't think we should require cleaning everything up first.
[08:22] <jam> poolie: his comment was "we should land a separate branch that cleans up our hacks"
[08:22] <jam> I'd rather land a compatibility break
[08:22] <jam> and as we want to clean up code, do so
[08:23] <jam> don't block on us cleaning up all the code first
[08:23] <poolie> oh, right
[08:23] <poolie> i agree with that
[08:23] <poolie> "clean up all the code" doesn't have a very clear end point
[08:23] <sobersabre> hi.
[08:23] <poolie> oh wow it's wednesday already
[08:24] <poolie> that was quick
[08:24] <sobersabre> I'm trying to determine whether I need to commit something.
[08:24] <sobersabre> poolie: indeed wednsday, depending on you timezone though.
[08:25] <sobersabre> I have found already I need to commit if wt.changes_from(wt.basis_tree()).has_changes()
[08:25] <sobersabre> and also if wt.get_parents_ids() array has > 1 items.
[08:25] <sobersabre> anything else I'm missing ?
[08:26] <poolie> sobersabre: you're reimplementing bzr's commit function?
[08:29] <spiv> sobersabre: why not just try the commit with allow_pointless=False, and catch the PointlessCommit error for when there's nothing to commit.
[08:38] <jam> sobersabre: or worst case: "wt.has_changes()" ...
[08:38] <jam> which implements all of that logic as well
[08:38] <jam> Though that was introduced in "recent" versions. (2.2 maybe?)
[08:44] <poolie> i'm not completely sure that would catch a do-nothing merge
[08:55] <jelmer> hi poolie, spiv, jam
[08:55] <jam> morning jelmer
[08:55] <jam> poolie: it checks the get_parent_ids() stuff, not sure what you're thinking
[08:56] <poolie> hi guys
[09:00] <poolie> hi jelmer, jam, spiv
[09:00] <poolie> shall we have a chat?
[09:06] <jelmer> poolie: which VOIP systems would you like to use today ? :)
[09:06] <jam> jelmer: mumble today
[09:06] <jam> jelmer: are you in #canonical?
[09:06] <poolie> i would like to use sip but i guess we'll actually use mumble
[09:28] <bialix> and what's better?
[09:28] <jelmer> jam: https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/58567
[09:30]  * jelmer groans
[09:30] <jam> jelmer: would you rather just IRC chat?
[09:30] <jam> or direct skype?
[09:31] <jelmer> jam: let's try skype
[09:36] <poolie> bialix: they all have tradeoffs i guess
[09:36] <poolie> hi, btw
[09:38] <bialix> hi poolie
[09:39] <bialix> poolie, don't take my words about python 2.5 and py2exe too high
[09:39] <bialix> it's so strange to see jam around at this half of the day
[09:40] <bialix> skype has chat mode
[09:40] <poolie> he lives in the Netherlands now
[09:40] <poolie> so it's 11am or so
[09:40] <bialix> really?
[09:40] <poolie> srsly
[09:40] <jam> bialix: yeah, for about 2 years before I go back to the US
[09:40] <jam> my wife got a promotion that needs some training
[09:41]  * bialix is very surprised, but that's great
[09:41]  * fullermd of course has no such sensible excuse for being around at this hour   :p
[09:48] <bialix> fullermd: we know you never sleep, so you don't need any excuses
[10:00] <jam> jelmer: what is up with your audio system?
[10:00] <jam> Overall, I think skype was working better than mumble, though
[10:16] <poolie> night all
[10:23] <jam> night po
[10:23] <jam> poolie: g'night
[10:23] <jam> jelmer: you just cut out again
[12:18] <jelmer> jam: Do you think we need to deprecate update_revisions first? I'm not aware of anybody using it and I couldn't imagine everybody using it, it's a pretty odd interface compared to e.g. push or pull.
[12:19] <jam> jelmer: you would be the most aware of any implementations using it
[12:19] <jam> if bzr-svn, for example, uses it
[12:19] <jam> then we should probably deprecate it
[12:19] <jam> we'll move away from it, but we don't want to kill people with version ske
[12:19] <jam> skew
[12:19] <jelmer> the foreign plugins all provide update_revisions but none of them uses it
[12:20] <jelmer> so I'd be more than happy to axe it, as it means being able to remove that update_revisions() implementation too
[12:20] <jam> jelmer: so just watch out for skew, you can't axe it until it isn't actually being used.
[12:20] <jam> But yes, I don't think anyone was directly calling it
[14:03] <mterry> In Ubuntu 11.04, I'm doing "cd dir; bzr init; bzr add" and nothing is getting added, no errors or anything.  How do I figure out what's going on?
[14:04] <jelmer> mterry: what does "bzr st" say?
[14:04] <mterry> unknown:
[14:04] <mterry>   ubuntu-application/
[14:04] <mterry>   ubuntu-cli/
[14:04] <mterry>   ubuntupygame/
[14:04] <mterry> jelmer, ^
[14:13] <jelmer> mterry: is that correct, were those the directories you wanted to add?
[14:14] <mterry> jelmer, yes.  But bzr add seems to ignore them
[14:14] <jelmer> does "bzr add ." give different behaviour?
[14:15] <mterry> jelmer, no.  Nor does specifying directories or files
[14:16] <mterry> jelmer, oh!!
[14:16] <jelmer> mterry: that's really odd - are there any symlinks involved perhaps?
[14:16] <mterry> jelmer, the directories are also bzr repos
[14:16] <jelmer> mterry: You found it ? :)
[14:16] <jelmer> mterry: that would explain it
[14:16] <mterry> jelmer, I just realized
[14:16]  * mterry wishes at least bzr add -v would have said something
[14:16] <mterry> jelmer, thanks for the help!
[14:19] <jelmer> mterry: I think the idea is that they would be added as nested trees, but the support for that is half finished
[14:19] <mterry> hmm, k
[15:11] <jelmer> jam: This might be a noobish question, but is there any reason we couldn't do in-place updates of timestamps/shas in dirstate if there are no changes in the file list?
[15:11] <jam> jelmer: the original design was so that we could (which is why we take OS locks, etc). we don't because, a it wasn't implemented, b, I'm not sure if things are truly fixed width
[15:11] <jam> and c) we want to get rid of OS locks
[15:12] <jelmer> jam: ah, thanks
[15:13] <jam> jelmer: if we new it was going to be reasonably atomic, we probably could update in place, though that logic still needs to be worked out
[15:13] <jam> well, as long as any failure mode would fail gracefully
[15:13] <jam> rewriting pages has some bad habits when things crash
[15:13] <jam> like random NULLs, etc.
[15:14] <jam> I think our current thought is that we'd rather have a separate journal file
[15:14] <jam> also, dirstate was written such that we could only read some of the file (it is bisectable, etc)
[15:15] <jam> but we always read and write the whole thing right now
[15:22] <bialix> jam: isn't atomic write require write to some temp file and then mv over the old?
[15:24] <jelmer> jam: ah, interesting - thanks
[15:43] <bialix> jam: if I want to improve auto-refresh in bzr-explorer to reflect new changes in working tree then I think I can add filesystem wathcer for dirstate file and maybe conflicts file, right?
[16:09] <jelmer> jam: still there?
[16:09] <jelmer> jam: I'm double checking the behaviour of text revisions. is it correct that we record a new text when:
[16:10] <jelmer> * a file's executability changes
[16:10] <jelmer> * a symlink's target changes
[16:10] <jelmer> * during a merge one of the texts of the parents is taken verbatim (no sha1/executability changes) but the text of another parent is discarded
[16:11] <jelmer> but not when a right hand side parent introduces a new text and that text is taken verbatim
[17:40] <lallenlowe> can someone tell me, in GNOME, when I go to pull new revisions of a project from launchpad and the little dialog pops up asking for my password to unlock my ssh key, what program provides that dialog? and caches the password for future pulls?
[17:49] <mterry> lallenlowe, gnome-keyring stores it
[17:49] <mterry> I believe...
[17:49] <lallenlowe> mterry: yeah, that's what I thought
[17:50] <lallenlowe> mterry: for some reason it is asking me for the passphrase on the cli
[17:50] <mterry> lallenlowe, hmm.  You know, for bzr, it might be ssh-agent that's doing the asking
[17:50] <lallenlowe> mterry: right
[17:51] <Peng> I've seen the magic GNOME thing come up when using ssh in a terminal.
[17:51] <lallenlowe> Peng: I used to also
[17:51] <mterry> I don't know how it decides whether to prompt with GUI or not.  I assume if DISPLAY is valid, but not sure now who actually owns the GUI dialog
[17:52] <lallenlowe> ok
[18:26] <jam> jelmer: more complex than that, I think
[18:27] <jam> it depends more on the ancestry
[18:30] <jam> for example, one side could take an old revision, modify it, then revert it, then merge it, and we would create a new revision
[18:30] <jam> even though both sides have the same final content
[20:26] <LeoNerd> Dear bzr community: is it so much to ask that "bzr: ERROR: No push location known or specified."  could in fact become "bzr: No push location known so pushing to branch"   instead?
[20:27] <LeoNerd> 99.999% of the time I am pushing I am pushing to my (bound) branch. In fact I don't think in a single checkout I've ever made, do the branch/parent/push/missing locations ever differ
[20:30] <levu> how do i push only the last commit to a new branch, not the whole history?
[20:30] <LeoNerd> push -r   I believe
[20:31] <levu> LeoNerd: thx
[20:31] <LeoNerd> Ohwait... the -last-.. er.. you can't, as such
[20:31] <LeoNerd> A commit applies a change to its parent. A commit implies the entire history that came before it
[20:32] <levu> LeoNerd: how do i push it as if i am doing the initial import?
[20:32] <LeoNerd> Hrm?
[20:33] <levu> there is lp:foo as the main branch of a software and i want to create an own branch for fixing a bug. in my branch (lp:~levu/foo) i don't want to have lp:foo be cloned
[20:34] <levu> i did bzr pull lp:foo and bzr push lp:~levu/foo for that, but that's cloning the whole lp:foo into my branch
[20:35] <lifeless> levu: what is foo
[20:35] <lifeless> I can look for you
[20:35] <levu> *bzr branch lp:foo not bzr pull lp:foo
[20:36] <levu> lifeless: https://bugs.launchpad.net/ubuntu/+source/conglomerate/+bug/771735 this is the case where i done it wrong, i assume
[20:36] <lifeless> levu: so lp:conglomerate ?
[20:36] <levu> the linked branch is mine and when you look at the history of the linked branch, you see the whole history of lp:ubuntu/conglomerate
[20:36] <lifeless> ok, lp:ubuntu/conglomerate
[20:37] <lifeless> and you are pushing to lp:~levu/ubuntu/natty/conglomerate/branchname ?
[20:37] <levu> lifeless: no, to lp:~levu/conglomerate/771735
[20:37] <levu> https://code.launchpad.net/~levu/conglomerate/771735
[20:38] <levu> i did commit 12 im my branch and commits 1 to 11 are cloned from the official branch
[20:38] <lifeless> levu: so, you're pushing *upstream* bbut you branched from *ubuntu*
[20:38] <lifeless> levu: thats why this is happening.
[20:39] <levu> lifeless: well, my point is, i want to create a new branch, where there's only one commit, not the whole history of commits
[20:39] <lifeless> levu: right, try this:
[20:39] <lifeless> bzr ush lp:~levu/ubuntu/natty/conglomerate/771735
[20:39] <lifeless> *push*
[20:39] <lifeless> shold be a lot faster
[20:40] <levu> lifeless: are the names important?! wow, that's interesting, i thought, i can choose the name as i want :D
[20:40] <levu> ok, i'll try this, thanks :)
[20:40] <lifeless> levu: the upstream name and the distro package name can differ
[20:40] <lifeless> levu: so yes, they are important.
[20:40] <levu> lifeless: ok, thanks :)
[20:41] <lifeless> levu: you can choose the branchname - the last component - anyway you want
[20:41] <levu> lifeless: aaah, ok
[20:41] <lifeless> levu: the first component - your name - has to be your name or a team you are a member of
[20:42] <lifeless> the components in between tell launchpad what project - 'foo' is upstream 'distro/series/sourcepackage' is a distro branch
[20:42] <levu> where in the documentation i can find such interresting things? :D
[20:43] <lifeless> bzr help lp
[20:43] <lifeless> might have some stuff
[20:44] <levu> here it says, ERROR: No help could be found for 'lp'.
[20:45] <lifeless> bzr help launchpad
[20:45] <lifeless> sorry ;)
[20:46] <levu> lifeless: thanks a lot :)
[20:46] <lifeless> it may not be helpful - please do file a bug if thats the case
[20:46] <levu> there is a link to http://help.launchpad.net/ which should help