[04:39] <mkanat> The buildbot release notes say that they're going to drop Bazaar support for their next release unless somebody maintains it.
[04:46] <lifeless> baz or bzr
[04:46] <lifeless> whats unmaintained about it ?
[05:22] <mkanat> lifeless: I'm not sure if they mean baz or bzr.
[05:23] <mkanat> lifeless: I'm not sure, I just noticed it in the release notes. I'm guessing they mean baz, because it would seem weird to drop bzr support.
[05:25] <mkanat> Hmm, yeah, I think they refer to baz as "Bazaar" and bzr as "Bzr".
[05:35] <mkanat> Yeah, they removed baz and said they were removing Bazaar.
[14:01] <cnd> I'm trying to use bzr fast-import with git fast-export
[14:01] <cnd> but every time I try it aborts on a specific commit
[14:01] <cnd> anything I can try to make it work?
[14:02] <jelmer_> hi cnd
[14:02] <jelmer_> cnd: That depends on why/how it is failing..
[14:03] <cnd> ABORT: exception occurred processing commit :25
[14:03] <cnd> bzr: ERROR: exceptions.IndexError: list index out of range
[14:05] <jelmer_> cnd: I think I've seen that error before; have you checked the bzr-fast-import bugtracker to see if there are any similar issues listed there?
[14:06] <cnd> jelmer_, not yet
[14:06] <cnd> I'll look now
[14:37] <jelmer_> cnd: Alternatively, have you considered doing the import with bzr-git or the Launchpad import service ?
[14:38] <cnd> yeah, I haven't yet
[14:38] <cnd> are there differences in how bzr-git and bzr fast-import work?
[14:38] <cnd> as in, will the outputs be the same or different?
[14:39] <jelmer_> cnd: bzr-git generates consistent output, bzr fast-import will generate different output if run by different people independently.
[14:39] <jelmer_> cnd: The output they generate is different.
[14:39] <jelmer_> (The Launchpad import service uses bzr-git)
[14:40] <cnd> ahh, ok
[14:40] <cnd> thanks
[14:47] <cnd> jelmer_, I think I got it working using bzr-git instead
[14:47] <cnd> thanks!
[15:16] <jam> jelmer_: morning. I have a question about meliae
[15:16] <jam> looking here: http://packages.debian.org/sid/python/python-meliae it looks like it only built 0.3.0 for 1 platform?
[15:16] <jelmer_> cnd: No problem
[15:16] <jelmer_> jam: 'morning
[15:16] <jelmer_> jam: Uhm, aren't you generally the person providing *answers* about meliae ? :-P
[15:17] <jelmer_> jam: yes, so far it's only built on my local machine (I use amd64).
[15:17] <jelmer_> jam: At some point the Debian buildds will also build it for other architectures.
[15:18] <jam> jelmer_: k, I just wanted to request a sync to Maverick, and I wasn't sure what I need to wait for there.
[15:18] <jam> james_w: ping if you are around
[15:18] <james_w> jam: pong
[15:18] <jelmer_> jam: You should be able to request a sync
[15:18] <jam> james_w: any chance you could sync meliae 0.3.0? I can do the official thing if you're busy
[15:20] <james_w> jam: I can
[15:20] <jam> james_w:  /thank /cheer /train :)
[15:30] <MacSlow> james_w, there I am
[15:31] <james_w> hi MacSlow
[15:31] <james_w> jam: MacSlow is having an odd problem pulling from lp
[15:31] <james_w> bzr hangs, but ssh works fine
[15:31] <james_w> https://pastebin.canonical.com/35554/
[15:32] <james_w> MacSlow: there's no extra lines in your ~/.bzr.log now are there?
[15:35] <MacSlow> james_w, these are just the last 10 lines... my whole ~/.bzr.log is 36716 lines long (2234253 bytes)
[15:35] <james_w> MacSlow: yeah, I just wondered if it had written any subsequent debugging information
[15:36] <MacSlow> james_w, nope... the "bzr -Dhpss branch lp:clutk" command still hangs
[15:37] <MacSlow> and I don't expect it to move anytime soon
[15:39] <james_w> MacSlow: could you do a "pstree -p | grep -C2 bzr" please?
[15:42] <MacSlow> james_w, pastebin taking its time to respond
[15:42] <MacSlow> james_w, http://pastebin.ubuntu.com/474081/
[15:42] <james_w> MacSlow: and "strace -p 2206"
[15:43] <MacSlow> james_w, wait... it (bzr) moved
[15:43] <jam> james_w, MacSlow: strange, I just did "time bzr branch lp:clutk" and it finished in about 19s
[15:43] <MacSlow> seems it just finished the branch
[15:44] <jam> it isn't a very large branch
[15:44] <james_w> MacSlow: odd, in response to the strace, or before you got to that?
[15:44] <MacSlow> james_w, before that
[15:45] <MacSlow> why do I always have to run into such kind of problems
[15:46] <MacSlow> james_w, doing a "bzr -Dhpss branch lp:clutk" again and doing a strace on it's process id
[15:46] <MacSlow> that just sits there at "read(6 ,"
[15:47] <james_w> jam: synced
[15:47] <jam> thanks james_w
[15:47] <james_w> MacSlow: seems that lp is taking its time in talking to you for some reason
[15:47] <james_w> that's my guess, maybe 6 is something else
[15:49] <jam> MacSlow: any chance to do an strace across the whole run?
[15:49] <MacSlow> james_w, ~/.bzr.log -> http://pastebin.ubuntu.com/474085
[15:49] <jam> 50s to do an open() call? that is strange
[15:49] <jam> now, that includes the ssh handshake, etc
[15:49] <jam> MacSlow: what is your ping time to bazaar.launchpad.net?
[15:50] <jam> (I wonder if there is something strange is the ssh handshake, but if normal ssh/sftp doesn't take that long then it is probably something else)
[15:50] <MacSlow> jam, ~33 ms
[15:50] <jam> MacSlow: do you have a lot of ssh keys in your agent?
[15:51] <MacSlow> jam, how to check?
[15:52] <jam> MacSlow: if you don't know, then I expect it will be small :), let me find it real quick
[15:54] <jam> MacSlow: ssh-add -l
[15:54] <MacSlow> jam, that reports just  one line, my key
[15:54] <jam> yeah, that's what I figured
[15:55] <jam> so it isn't like launchpad is spending a lot of time determining which key to use
[15:55] <jam> MacSlow: is it repeatable? (as in, if you try to branch again, it still takes >1min?)
[15:56] <MacSlow> jam, certainly... just trying it again... it just sits there
[15:56] <MacSlow> jam, on my desktop machine (running lucid) it works super fast
[15:58] <MacSlow> jam, other network-traffic (e.g. browsing some webpage) works at normal speeds
[16:00] <jam> MacSlow: try typing this:
[16:00] <jam> echo hello | ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes
[16:01] <jam> that should at least connect, talk to the remote server and stop
[16:01] <jam> and then we can try adding "-v" to the ssh command
[16:03] <MacSlow> jam, waiting for 10 seconds now after triggering that "echo hello | ..." command... nothing
[16:03] <MacSlow> ah wait
[16:03] <MacSlow> now it tells me again I don't ahve a registered ssh key
[16:06] <jam> MacSlow: probably your lp username is different from your local one
[16:06] <jam> just add "lpuser@bazaar." for whatever your launchpad username is
[16:07] <MacSlow> jam, figured that out... trying... but still sitting there doing nothing
[16:07] <jam> MacSlow: so trying again with "ssh -v" would be worthwhile I think
[16:07] <jam> it should tell us if ssh is sitting there waiting for something
[16:07] <jam> or if it is something in bzr
[16:08] <MacSlow> jam, "ssh -v ..." what else?
[16:08] <jam> (note that it is about 7s here, and that is *with* typing in my ssh passphrase)
[16:08] <jam> echo hello | ssh -v lpuser@bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes
[16:09] <jam> MacSlow: I have an idea, there was an issue I've seen in the past with dns reverse lookups
[16:09] <MacSlow> ok
[16:09] <jam> let me see if I can find the ssh config
[16:09] <jam> wait, maybe it was kerberos
[16:09] <MacSlow> right now it sits at: "debug1: expecting SSH2_MSG_KEXDH_REPLY"
[16:09] <jam> I wish I could remember better, checking
[16:10] <jam> MacSlow: http://llbb.wordpress.com/2007/07/11/ssh-takes-exactly-1-minute-20-seconds-or-80-seconds/
[16:11] <jam> or
[16:11] <jam> http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2007-02/msg00033.html
[16:13] <MacSlow> jam, there they talk about sshd
[16:14] <jam> well, they talk a little bit about both, I'm still looking
[16:14] <jam> https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/174168
[16:14] <jam> seems pretty close to what you are seeing
[16:14] <jam> claims to be fixed in ssh v5.2
[16:15] <jam> what does ssh --version give ?
[16:15] <jam> and this: http://www.snailbook.com/faq/mtu-mismatch.auto.html
[16:16] <jam> MacSlow: so you might try ifconfig eth0 mtu 576 and see if that "fixes" it.
[16:17] <jam> MacSlow: what platform are you on?
[16:17] <jam> (the bug report is about Jaunty)
[16:17] <MacSlow> jam, that would be wlan1 on my laptop here... does the MTU also apply to wifi-nics?
[16:17] <MacSlow> jam, maverick
[16:17] <jam> MacSlow: it should apply to any TCP/IP network
[16:19] <MacSlow> jam, still hangs at "debug1: expecting SSH2_MSG_KEXDH_REPLY"
[16:21] <MacSlow> jam, this is taking too long... I need to work-around this some other way... thanks for the help sofar.
[16:22] <jam> MacSlow: just to check, what was your "ssh --version" ?
[16:22] <jam> (though as you say, if it was just that, lucid should be older than maverick)
[16:23] <jam> regardless, it is an ssh handshaking bug
[16:23] <jam> not something with bzr
[16:23] <pickscrape> Hi, I seem to have managed to "lose" a revision by a combination of bzr rebase, switch and rebase-abort. Anyone know of any tricks to find revisions?
[16:23] <jam> pickscrape: bzr heads --dead
[16:23] <pickscrape> jam: unfortunately that hasn't found the revision I'm looking for :(
[16:24] <MacSlow> jam, ssh -version reports "OpenSSH_5.5p1 Debian-4ubuntu3, OpenSSL 0.9.8o 01 Jun 2010"
[16:24] <pickscrape> It has actually found a parent of it though
[16:24] <pickscrape> Or it could be a parent: may have previously been rebased away of course.
[16:25] <jam> pickscrape: if it found a parent and not a child, then it would be tricky to find (a head is the most recent *child* with no other children)
[16:26] <jam> which would indicate that the revision really isn't there
[16:26] <jam> or the parent wouldn't be a head
[16:26] <pickscrape> Ah, the parent I thought I'd found must have been due to a rebase then.
[16:27] <pickscrape> What's happened is I tried rebasing branch A, which must have failed, though I didn't notice the message telling me so. Later on I swithed to branch B, and tried to rebase.
[16:27] <pickscrape> It said there was already one in process, so I opted to rebase-abort. That left me with branch B looking like branch A.
[16:28] <pickscrape> I'm wondering if it's a bug for switch to be allowed while there's a pending rebase in process?
[16:29] <jam> pickscrape: perhaps. If you're in the same repository, though, rebase shouldn't be deleting any revisions, just changing the branch pointers
[16:29] <jam> so they should all still be there
[16:35] <pickscrape> jam: I actually have found the head I was looking for in the heads output. There's quite a few listed there. :) Thanks for your help.
[16:39] <jam> james_w: I just got a "The source meliae - 0.3.0-1 is already accepted in ubuntu/maverick and you cannot upload the same version within the same distribution." error message
[16:39] <jam> did you try to upload it 2x ?
[16:39] <jam> Was it already synced by someone else?
[16:39] <jam> (ISTR that gary poster had some interest in getting the latest Meliae for launchpad developers)
[16:40] <james_w> jam: I made a mistake and attributed the sync to "jam", and then unsuccessfully tried to cancel that and set you as the requester.
[16:40] <james_w> jam: so it's there, just you don't get the credit for it. I forgot you would get a failure mail too.
[16:41] <jam> james_w: well, I can live without credit. I'm glad it got in
[16:43] <jam> anyway, back in a bit
[17:24] <rubbs> quick question. It's been a while since I've used bzr, if I want to connect to a server via ssh, I can't tell bzr to use a key right? I have to have it in some sort of agent correct?
[17:27] <abentley> jam, the revision-id requiring a username is a strict requirement with bzr 2.2b4.  My traceback shows that it is.
[17:27] <jam> abentley: I'm saying that to create Revision content we require Whoami, I think that requiring it to create revision-ids is not much of a step beyond that
[17:28] <abentley> jam, we require a committer_id, not a whoami, to create Revision content.  But we require a Whoami to create a revision-id.
[17:29] <jam> abentley: and if you don't supply a commiter_id directly, we get it from whoami, right?
[17:30] <abentley> jam, correct.  The committer_id replaces Whoami for generating Revision content, but not for generating a revision-id.
[17:32] <abentley> jam, which is what I'm saying is a bug.  If the commiter is me@example.com, the revision-id shouldn't contain aaron@aaronbentley.com
[17:33] <jam> abentley: it looks like we will pull the username from the "EMAIL" env variable, and the bzrlib test suite sets that
[17:33] <jam> abentley: sure
[17:33] <jam> abentley: line 244 of repository.py
[17:33] <jam> _gen_revision_id() could know if the commit has a committer id and take it from that
[17:33] <jam> rather than always using _config.username()
[17:34] <abentley> jam, right.
[17:34] <jam> self._committer is available there, and happens to be self._config.username() if it wasn't supplied anyway
[17:34] <jam> so probably we could just change that line
[17:49] <mgz> selftest should pass on Python 2.6 right?
[17:49] <jelmer_> mgz: yeah
[17:49] <mgz> just tested a failure from upstream changes to gzip.py and it's from a change that shipped with Python 2.6
[17:50] <mgz> ...maybe the struct side of it is Python 2.7 only...
[17:50]  * mgz goes to see
[17:51] <jam> mgz: probably a 2.6.5/6 thing, as I believe they broke some stuff in the recent 2.6 releases
[17:51] <jam> I'm running 2.6.4 here
[17:52] <jam> (I think it is stuff they are officially allowed to break, but it broke nonetheless)
[17:52] <mgz> if you do... `python -c "import struct;print struct.pack('<L', -1)"` what happens?
[19:34] <GaryvdM> Hi all.
[19:34] <GaryvdM> What is the 2.2.0 status?
[20:05] <mgz> well, nominally frozen I guess garyvdm
[20:06] <mgz> ...two bugs to blame on lifeless-of-2006 in one day
[20:10] <mgz> jam is doing a bug-closing spree.
[20:11]  * mgz gets one before jam arrives there
[20:11] <jam> GaryvdM: I'm releasing today
[20:11] <jam> and cleaning up the bug tracker while I'm there
[20:11] <mgz> I'm not sure bug 531746 is fixed so much as mostly hacked around, but I guess that's nitpicking.
[20:13] <mgz> okay, two more Python 2.7 bugs to file, will do that later this evening.
[20:13]  * mgz wanders off for food
[20:13] <jam> mgz: you are welcome to post-triage however you want. For some things, a new bug is more relevant as it can be more focused
[20:14] <mgz> yeah, really that code just needs changing from a different angle, can quite happily be another bug.
[20:17]  * jelmer_ makes a note to ignore all bzr-related email traffic for the next couple of hours.. too much :-)
[20:18] <jam> jelmer_: you generated at least as much as I did in the last week :)
[20:21] <jelmer_> jam: Sorry :-)
[20:22] <jam> but yeah, a bigger storm of updates than I realized at first
[20:22] <jam> we had a *lot* of bugs that were fixed but not marked that way
[20:22] <jelmer_> are you using the script to check?:
[20:22] <jam> jelmer_: yeah, though after trimming just the 2.2 series over to a new file
[20:30] <GaryvdM> jam: Ok thanks.
[20:30] <GaryvdM> jam: I want to get the installers built as soon as possible.
[20:30] <jam> I'll have a tarball real-soon-now and I've submitted the code to pqm
[20:30] <jam> do you want me to spin up ec2?
[20:31] <jam> GaryvdM: ^^
[20:31] <GaryvdM> but not tonight, so tomorrow evening or sunday.
[20:31] <GaryvdM> jam: So yes please.
[20:31] <jam> well, I can't guarantee to be around, but we can leave it running for you, I guess
[20:32] <jam> GaryvdM: the instance is now launching, I can ping you when I know it is up if you want
[20:35] <GaryvdM> jam: I'm planing to make 2 releases. one with old paramiko, and one with my patch. I'll upload the old paramiko to launchpad, and the one with my patch, i'll mention it on the mailing list so that people who test understanding what they are testing.
[20:37] <jam> GaryvdM: I would just do your new paramiko
[20:37] <jam> up to you, though
[20:38] <GaryvdM> jam: Ok - then I would just like for someone to review my changes.
[20:38] <jam> GaryvdM: has robey noticed yet?
[20:38] <GaryvdM> Nope :-(
[20:39] <jam> GaryvdM: the big thing I saw, is that I think it breaks compatibility with pycrypto 2.0*
[20:39] <GaryvdM> jam: Yes, but if we control the pycrypto, that does not matter.
[20:40] <GaryvdM> For robey that probably does matter.
[21:41] <jelmer_> jam: w00t!
[21:41]  * jelmer_ looks into building 2.2.0 for debian
[21:53] <jelmer_> lifeless: 'moin
[21:53] <jelmer_> lifeless: I know you already have quite a few MPs to review on your list, but just wanted to make sure you were aware of the open ones for bzr-dbus.
[22:00] <lifeless> jelmer_: don't block on me :)
[22:28] <jelmer_> lifeless, ok :-)
[22:29] <lifeless> jelmer_: get john or jamesh or poolie to review
[22:29] <lifeless> or jfdi
[22:30] <jelmer_> lifeless: right
[22:31] <jelmer_> 140 more tests to go :-)
[23:02] <mgz> okay, that's the last Python 2.7 issue turned up from running the testsuite
[23:03] <mgz> just need to put up some more fixy branches now.
[23:04] <jelmer_> jam: still there
[23:04] <jam> jelmer_: just about to leave
[23:04] <jelmer_> jam: I have trouble merging bzr 2.2 into the debian unstable branch :-(
[23:04] <jelmer_> bzr: ERROR: An inconsistent delta was supplied involving u'bzrlib/help_topics/es', 'bzrlibhelp_topicses-20091223160038-qyu0zdzjfbx76ud7-1'
[23:04] <jelmer_> reason: Attempt to add item at path already occupied by id 'bzrlibhelp_topicses-20100104142927-3zk9dhyzgw3dqtkl-1'
[23:04] <jelmer_> any idea?
[23:05] <jam> sounds pretty odd to me. Looks like a wt.update() failure. Something thinks a dir shouldn't exist but it is already there
[23:06] <jam> anyway, I need to get going
[23:06] <jam> eo-week for me
[23:06] <jelmer_> Sorry, didn't mean to hold you up.
[23:06] <jelmer_> Enjoy your weekend!