[00:07] <mkanat> mwhudson: What version of pygments is installed on codebrowse?
[00:10] <mwhudson> mkanat: whatever's in hardy i guess
[00:11] <mkanat> mwhudson: Okay.
[00:11] <mwhudson> mkanat: 0.9-2
[00:11] <mkanat> mwhudson: Thanks! :-)
[00:11]  * igc building Windows installers for 2.2b2 today
[00:38] <blueyed> krisives-gearbox: well, the old commit would still be there.. you're creating only a new one. I would go with several "uncommits", fix the one in question, then redo the latter ones. edgimar ^^
[00:40] <igc> spiv, bug 496813 has landed into 2.1 now right?
[00:51] <poolie> hi all
[00:59] <spiv> igc: yes, thanks, bug updated
[01:00] <igc> spiv: thanks
[01:04] <poolie> lifeless (if any), I was thinking last night
[01:04] <poolie> perhaps we could test pqm in the real environment but on a different branch
[01:04] <poolie> so that it doesn't block development like bug 568100
[01:07] <lifeless> poolie: so thats not pqm itself; thats the subunit version in the chroot
[01:08] <poolie> because it changed recently and 2.0 is incompatible?
[01:08] <poolie> ok, but even beyond that specific bug
[01:08] <lifeless> the lack of feedback is hopefully fixed at this point, or at least, one less cause removed
[01:08] <lifeless> poolie: an edge/testing environment would be good
[01:08] <lifeless> I'm not dismissing that
[01:08] <poolie> needing to test it in the deployed environment seems not to be quite the same as needing it to be tested within our main workflow
[01:08] <lifeless> just noting the details of that particular problem
[01:09] <poolie> so we need to land a change to 2.0 that makes it pass with current subunit?
[01:09] <lifeless> yes
[01:09] <poolie> i see
[01:09] <lifeless> I've commented with a reasonable pointer in the bug
[01:10] <lifeless> I think an edge/staging environment for our CI stuff would be great
[01:10] <lifeless> that way when we move to tarmac, or whatever changes we want, we can be more confident before making changes.
[01:12] <poolie> so that would be i guess a different mail address and a different destination branch?
[01:12] <lifeless> and different test chroot
[01:12] <lifeless> and different pqm tree
[01:13] <lifeless> possibly even a different machine [perhaps a UEC vm] as there are dependencies involved like launchpadlib version
[01:33] <igc> hi poolie. Trip back to the big smoke all go ok?
[01:34] <poolie> it was fine
[01:34] <poolie> i really liked seeing brisbane again
[01:34] <jbowtie> Hi, does anyone have any pointers on integrating NTLM support?  I've been using python-ntlm and urllib2 directly in my TFS plugin and would like to switch to using the HTTP transport.
[01:34] <poolie> and seeing you
[01:34] <igc> poolie: we even put on some rain for you :-)
[01:35] <igc> poolie: ditto
[01:35] <rephormat1> greetings everyone.
[01:36] <rephormat1> I was wondering if anyone would have some time to discuss the workflow for a standard bazaar development environment
[01:36] <poolie> lifeless: is it possible at all that pqm could put the failures on its own webserver and just post a link to the mp?
[01:36] <jbowtie> Mostly I want to make sure I interact correctly with the credentials support so I can prompt for a password; should I just look at the urllib2 wrapper stuff?
[01:37] <poolie> jbowtie: it sounds good; you probably want to come in through the bzr authentication layer
[01:37] <rephormat1> I have successfully used bazaar in both a local and bzr+ssh fashion, but when I use the bzr+ssh fashion it always commits to the server rather than locally.
[01:37] <poolie> but ntlm has an intimate connection to http so it may be complex
[01:37] <poolie> j: vila knows the most about this but he may be asleep
[01:38] <mkanat> lifeless (or whoever): The lru_cache thread fix is in 2.1.0, right?
[01:38] <mkanat> (That's what the bug says, I just want to be sure it's right.)
[01:40] <jbowtie> poolie: I was hoping I could just plug in the urllib2 provider that python-ntlm provides, but since all that stuff appears to be wrapped I was unsure how straightforward it was going to be.
[01:41] <jbowtie> rephormat1: I usually create a branch locally, commit there, then push to the remote server.
[01:43] <jbowtie> If we get NTLM support integrated I can publish my bzr-tfs plugin, that's really the only missing piece.
[01:50]  * igc out for a few hours
[01:51] <igc> (2.2b2 builds for windows kicked off)
[01:55] <rephormat1> j: does that mean you would do a bzr checkout bzr+ssh://server/project/
[01:55] <rephormat1> J: make changes to the code, test, commit
[01:55] <rephormat1> j: then do a bzr push?
[01:59] <jbowtie> rephormat1: Well, I would do a bzr branch; if I did a bzr checkout I wouldn't need to push (bound branches commit to both the server AND the local branch)
[02:00] <rephormat1> ahhh
[02:02] <rephormat1> jbowtie: so I would do a bzr branch bzr+ssh://server/path/project ~/project
[02:02] <rephormat1> jbowtie: make my changes, test, commit, then bzr push?
[02:04] <jbowtie> rephormat1: Yes - with that workflow everything stays locally until you push to the server.
[02:04] <mwhudson> mkanat: +1 to working on bug 420738
[02:04] <rephormat1> EXCELLENT!
[02:05] <rephormat1> jbowtie: What happens if I make changes to the same file as one of my other editors?
[02:05] <rephormat1> jbowtie: just tell me if I'm being lazy and I'll try to make sense of the documentation again.
[02:05] <mkanat> mwhudson: Thanks. :-)
[02:07] <jbowtie> rephormat1: Usually that stuff just merges seamlessly. If there was a merge conflict I imagine you'd have to pull down the server changes, resolve the conflicts locally, then push again.
[02:08] <rephormat1> jbowtie: Thank you very much for your help, jbowtie. I appreciate it. Trying to get my programming group at our university to switch to bazaar
[02:08] <jbowtie> rephormat1: I have Subversion habits so I usually pull just before pushing as a safety precaution, but bzr has never bitten me.
[02:09] <rephormat1> Now all I have to do is find a bug tracking web gui for bazaar
[02:09] <jbowtie> rephormat1: No worries, doing the same at work which is why I'm working on a TFS plugin.
[02:09] <mkanat> rephormat1: Bug-tracking and version-control are unrelated....
[02:09] <rephormat1> I can't do it on launchpad.. at least not right now as all this code is inhouse and can't be public
[02:09] <rephormat1> TFS?
[02:10] <jbowtie> TFS = Team Foundation Server. Horrible Microsoft proprietary thing.
[02:10] <rephormat1> mkanat: my apologies. What I meant was being able to reference a bug ticket like you can when doing a commit with launchpad.
[02:11] <rephormat1> jbowtie: DUDE! I feel for you man.
[02:11] <mkanat> rephormat1: Ahhh. bzr can do that with Bugzilla out of the box.
[02:11] <rephormat1> jbowtie: I finally got my group AWAY from SHAREPOINT!!!!!!
[02:11] <rephormat1> mkanat: YOU ARE AWESOME!!!!
[02:12] <rephormat1> Now if only I can kill off the microsoft group. LOL!!
[02:12] <mkanat> rephormat1: Although I don't currently know of any integration within Bugzilla for bzr.
[02:12] <jbowtie> rephormat1: That might be my next project after this.
[02:12] <rephormat1> mkanat: I don't understand. Your saying it works out of th box, but that there is no integration?
[02:13] <mkanat> rephormat1: bzr supports noting that a particular commit is associated with a particular bug in Bugzilla.
[02:13] <jbowtie> rephormat1: I think Trac is also well supported; there's a bzr plugin IIRC.
[02:13] <mkanat> rephormat1: It's a feature in bzr.
[02:13] <rephormat1> Can you imagine.. a primarily open-systems group using SHAREPOINT!!!
[02:13] <rephormat1> so I showed them the light with Mediawiki
[02:13] <rephormat1> LMAO!!
[02:14] <rephormat1> jbowtie: yeah I was looking at bzr-trac at launchpad. The only thing I didn't like about it was that it required a directory to be completely empty to create a "trac"d branch
[02:15] <rephormat1> mkanat: I'm going to have to research that. Do you know if bugzilla can be downloaded and setup as a local private bug reporting system?
[02:15] <rephormat1> just curious..
[02:15] <mkanat> rephormat1: Yes, for sure.
[02:16] <rephormat1> mkanat: I TRIED to install a local private setup of launchpad... MAN that was a pain in the a$$..
[02:16] <mkanat> rephormat1: I can imagine.
[02:17] <rephormat1> mkanat: so I gave up... I'm a quitter.. I know... lol
[02:18] <rephormat1> but both of you have just peaked my curiousity and made my convincing arguement that much easier
[02:18] <mkanat> Okay, I have spent six hours reading this effing log, it's time to take a break.
[02:19] <rephormat1> mkanat: What log?
[02:19] <mkanat> rephormat1: Unrelated to our conversation.
[02:19] <mkanat> rephormat1: Related to loggerhead work I'm doing.
[02:19] <rephormat1> mkanat: excellent
[03:07] <zeroseven0183> Hi
[03:08] <zeroseven0183> I need help
[03:08] <zeroseven0183> I was trying to download the Ubuntu Manual project files
[03:08] <zeroseven0183> via bzr branch lp:ubuntu-manual last night
[03:09] <zeroseven0183> I was able to start it, but in the middle of the download, I decided to cancel (since I'm going to bed already)
[03:09] <zeroseven0183> Now, when retrying to download it gives me "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."
[03:09] <zeroseven0183> How do I correct this?
[03:10] <zeroseven0183> I've tried with different directory/folder (with the same name, and with a different name), but still the same error
[03:11] <jbowtie> zeroseven0183: So you're trying to branch it again?
[03:11] <zeroseven0183> Yes, correct
[03:13] <zeroseven0183> "Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."
[03:13] <jbowtie> zeroseven0183: OK, I seem to be branching it without a problem. Can I assume you've checked your connectivity?
[03:13] <zeroseven0183> Yes, I did and it's working fine
[03:15] <jbowtie> zeroseven0183: Can you branch other projects from launchpad?  For example, lp:quickly?
[03:15] <zeroseven0183> On the same directory?
[03:15] <zeroseven0183> Ok, wait
[03:16] <zeroseven0183> Sadly, now
[03:16] <zeroseven0183> Same error "Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."
[03:16] <jbowtie> Hmmm...does bzr info output anything?
[03:17] <zeroseven0183> bzr: ERROR: Not a branch: "/home/tutdek/Quickly/".
[03:17] <jbowtie> zeroseven0183: OK - is there a .bzr subdirectory in that directory?
[03:18] <zeroseven0183> No, there is no .bzr
[03:18] <zeroseven0183> But what I see in my /home folder is .bazaar
[03:20] <jbowtie> zeroseven0183: Well if there's no .bzr directory then it's not even getting far enough to start creating the branch. The other possibility is permissions; maybe send off an email to the launchpad admins?
[03:20] <zeroseven0183> Alright but how come I was able to do that last night?
[03:21] <zeroseven0183> Something to do with my Public Key
[03:22] <zeroseven0183> I already generated and reposted my public key twice this morning
[03:22] <jbowtie> zeroseven0183: I don't know - at this point I'm speculating (note that the error message does say 'Permission denied' ).
[03:22] <zeroseven0183> Yup
[03:23] <jbowtie> zeroseven0183: Best bet is to  contact the admins, they can probably tell you what's going on; maybe some spammer got your ISP subnet blacklisted.
[03:24] <fullermd> The error means it's not succeeding at key auth.  Which probably means the key you're using locally and the key on LP are different.
[03:24] <fullermd> Try just connecting manually with ssh, and sprinkle on -v's to taste to see what key it's expecting to use.
[03:25] <zeroseven0183> I have two SSH keys in my Launchpad account
[03:25] <zeroseven0183> Are they both being scanned when branching?
[03:26] <fullermd> I'd imagine.
[03:26] <fullermd> But don't guess.  See what ssh says.
[03:28] <zeroseven0183> Never thought the efects of cancelling that download would be harder
[03:36] <zeroseven0183> Alright, fullermd, how do I do the ssh -v thing?
[03:36] <zeroseven0183> Sorry I'm not good in command lines
[03:36] <spiv> zeroseven0183: "ssh -v bazaar.launchpad.net"
[03:37] <spiv> zeroseven0183: and see which keys it tries
[03:37] <zeroseven0183> The last line still says Permission denied (publickey)
[03:38] <fullermd> May need a couple (-vv or -vvv) to see all the details; I don't know offhand what levels reports everything you need.
[03:38] <spiv> zeroseven0183: right, but hopefully the other lines will give you some information about which keys ssh is trying to use
[03:43] <zeroseven0183> Ok. Here's what I got http://pastebin.com/i17EkVBB
[03:43] <zeroseven0183> http://pastebin.com/raw.php?i=i17EkVBB
[03:45] <spiv> zeroseven0183: oh, I forget
[03:46] <spiv> zeroseven0183: you should also explicitly use your launchpad username with "ssh -v"
[03:46] <spiv> zeroseven0183: e.g. "ssh -vv bazaar.launchpad.net -l zeroseven0183" or whatever
[03:46] <spiv> (Unless your Launchpad username is tutdek?)
[03:47] <zeroseven0183> Nope
[03:47] <spiv> Otherwise that debug output just tells us that none of your local keys match the public key on launchpad for 'tutdek' :)
[03:47] <zeroseven0183> Here's the changes http://pastebin.com/raw.php?i=bEWWMRAd
[03:48] <zeroseven0183> Just added -l zeroseven0183
[03:49] <spiv> Ok, then none of the keys you have locally in .ssh match any of the ones on your Launchpad account.
[03:50] <spiv> It says it is trying 3 different keys in your .ssh directory, but none of them are right.
[03:52] <spiv> zeroseven0183: take a look at your .ssh/id_rsa.pub file, does it match one of the ones at https://edge.launchpad.net/~zeroseven0183/+sshkeys ?
[03:53] <zeroseven0183> Now that's a lot of characters! :-)
[03:54] <zeroseven0183> Yes, I think they're match
[03:54] <spiv> Hmm!  Then I'm not sure why it would fail :(
[03:55] <zeroseven0183> Wait
[03:55] <zeroseven0183> I have two keys in edge.launchpad.net
[03:55] <spiv> Yes.  That's fine.
[03:55] <zeroseven0183> The last one matched with what's in the .pub
[03:55] <spiv> You can have twenty if you like ;)
[03:56] <zeroseven0183> Hmmm... I wish I was more patient last night
[03:57] <zeroseven0183> The download was just 50% when I cancelled it
[03:57] <spiv> I don't know why that key would have stopped working overnight.
[03:57] <mkanat> This is the second time that a loggerhead bug has taken me weeks or months to track down and ended up being a tiny, tiny fix.
[03:57] <spiv> mkanat: heh
[03:58] <zeroseven0183> spiv: I guess I should go and e-mail the Launchpad admins?
[03:58] <spiv> zeroseven0183: at this point I only have increasingly unlikely theories, e.g. that the permissions on your .ssh directory or the .ssh/id_rsa file are wrong, but I'd expect ssh to warn if that's the case.
[03:59] <spiv> ("ls -ld ~/.ssh" should show "drwx------", and "ls -l ~/.ssh/id_rsa" should show "-rw-------")
[04:00] <spiv> Hmm: "debug2: we did not send a packet, disable method" is odd
[04:01] <zeroseven0183> :-(
[04:02] <spiv> It should have lines like "Offering public key: /home/andrew/.ssh/id_rsa", but it doesn't.
[04:03] <zeroseven0183> OK wait... I think I'm seeing some light
[04:03] <spiv> It definitely shows signs of being a local configuration problem, but I don't know what.
[04:03] <zeroseven0183> You mentioned the ls -l ~/.ssh/id_rsa
[04:03] <zeroseven0183> being in the ~/.ssh directory
[04:03] <zeroseven0183> I don't have that
[04:03] <spiv> Oh!  I see.
[04:03] <zeroseven0183> So I moved the id_rsa and id_rsa.pub on that directory
[04:04] <spiv> I guess that's what the "((nil))" parts mean.
[04:04] <zeroseven0183> Actually, the filename was originally idko and idko.pub
[04:04] <zeroseven0183> then ran bzr branch lp:ubuntu-manual
[04:04]  * fullermd blinks.
[04:04] <spiv> You can set the filename in your .ssh/config.
[04:04] <spiv> Not that there's much reason to use anything other than the default if you only have one key on that system.
[04:04] <zeroseven0183> And now it's trying to fetch the revisions
[04:05] <zeroseven0183> Yup
[04:05] <spiv> Ah good.  Glad I could help!
[04:05] <zeroseven0183> I think I can breathe now
[04:05] <zeroseven0183> Sure
[04:05] <zeroseven0183> Everyone who chatted with me here were very helpful
[04:05] <zeroseven0183> What a learning experience
[04:06] <zeroseven0183> Thank you very much, people
[04:06] <spiv> Well, you've reminded me of some details of how to interpret ssh -vv output :)
[04:07] <zeroseven0183> And now for the most exciting part of the day... LUNCH!
[04:07] <zeroseven0183> I'm off now, guys
[04:07] <zeroseven0183> Thank you very very much!
[04:07] <zeroseven0183> You did very well in helping me
[04:07] <zeroseven0183> See you around next time
[04:07] <zeroseven0183> :-)
[04:17] <mkanat> mwhudson: Okay, MP: https://code.launchpad.net/~mkanat/loggerhead/limit-pygments/+merge/23900
[04:20] <mwhudson> mkanat: if (): looks like C :)
[04:20] <mkanat> mwhudson: Oh, right. I'm sleepy. :-)
[04:49]  * spiv -> lunch
[06:16]  * man_in_work waves
[06:18] <man_in_work> i'm trying to branch a bzr repo and i'm getting "No repository present"
[06:19] <man_in_work> using command: bzr branch sftp://user@server/path/to/branch/
[06:20] <man_in_work> /path/to/branch exists as an absolute path on the server, and includes a .bzr directory
[06:20] <man_in_work> inside that, there is a file "branch-format", which reads: Bazaar-NG meta directory, format 1
[06:21] <man_in_work> my bzr --version reads: Bazaar (bzr) 2.1.1
[06:21] <fullermd> The whole output would be helpful.  Also an 'info' of that URL.
[06:22] <man_in_work> bzr: ERROR: No repository present: "sftp://user@server/path/to/branch/"
[06:22] <man_in_work> ^^ whole output
[06:22] <man_in_work> what do you mean by info?
[06:22] <fullermd> bzr info $URL
[06:22] <man_in_work> same output
[06:23] <fullermd> What all is in the .bzr?
[06:24] <man_in_work> branch-lock, branch directories, branch-format and README files
[06:26] <man_in_work> is bzr-ng a different tool to bzr 2.x?
[06:26] <fullermd> bazaar-ng is bzr.  I'm not sure what bzr-ng is.
[06:26] <fullermd> What about in /path/to and /path?  That doesn't list a repository.
[06:29] <man_in_work> there is a .bzr in the 2nd-level directory in /path/to
[06:29] <fullermd> Does the user have access to it?
[06:31] <man_in_work> perms are 755 on directories and 644 on files
[06:31] <man_in_work> so, yes
[06:31] <fullermd> Well, bzr is telling you that for some reason it can't get its hands on it.
[06:31] <fullermd> Maybe .bzr.log says something?  There's some -D flag to get it to tell more about what it's doing...
[06:33] <fullermd> -Dsftp maybe?  Though I suspect that talks more about the interaction with sshd itself than the activity happening over it.
[06:33] <fullermd> I thought there was a -Dtransport or something, but I don't see it in the docs.
[06:33] <man_in_work>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 684, in find_repository
[06:33] <man_in_work>     raise errors.NoRepositoryPresent(self)
[06:33] <man_in_work> ^^ that's the end of the backtrace in the log
[06:33] <fullermd> If you've got bzr on the server, bzr+ssh has some more options (and is a better all around choice anyway)
[06:33] <fullermd> Yeah, but that doesn't tell us where it {was looking,had looked}.
[06:34] <man_in_work> some smart fellow decided to use a bzr repo on a server that doesn't have bzr installed
[06:34] <man_in_work> don't ask me why
[06:35] <fullermd> Well, you could try pretending to be bzr.  Use sftp(1) yourself to go in as that user and poke around, make sure you can reach into the repo.
[06:36] <fullermd> spiv: ^^ am I missing a -D option to tell what files it's trying to look up?
[06:36] <man_in_work> don't see any problems
[06:36] <man_in_work> with direct sftp access
[06:38] <man_in_work> i don't see -D on the manpage anywhere
[06:38] <man_in_work> is it a flag to bzr or to branch?
[06:38] <fullermd> To bzr.
[06:38] <fullermd> `bzr help debug-flags`
[06:46] <poolie> igc, source is properly frozen now
[06:46] <poolie> https://edge.launchpad.net/bzr/2.2/2.2b2
[06:47] <fullermd> poolie: Oh, you're around to bug instead of spiv    :)
[06:48] <igc> poolie: thanks. I'll check the installer builds now
[06:48] <fullermd> poolie: Am I misremembering that there used to be a -Dtransport or the like?
[06:48] <poolie> not for much longer  :)
[06:48] <poolie> fullermd: there is log+sftp:// etc
[06:48] <poolie> i would like a debug option that puts this onto all transports but i don't think it exists yet
[06:48] <fullermd> Ooh, maybe that's what I'm trying to think of.
[06:48] <fullermd> man_in_work: Try that  ^^^
[06:49] <man_in_work> got some useful info
[06:51] <man_in_work> No such file: '/path/to/branch/.bzr/checkout/format': [Errno 2] No such file
[06:51] <fullermd> Probably irrelevant.  'branch' doesn't really do anything meaningful with that.
[06:53] <man_in_work> what about repository/format?
[06:55] <fullermd> That's more what we're be looking for.
[06:56] <man_in_work> well, that also doesn't exist
[06:56] <man_in_work> there's no repository directory
[06:57] <man_in_work> i see a repository.backup in an ancestor directory's .bzr
[06:58] <man_in_work> looks like someone's been screwing around
[07:07] <man_in_work> fullermd: thanks for your help
[07:36] <naoki> ping: vila
[07:36] <vila> naoki: yeah ! pong
[07:36] <naoki> vila: https://code.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
[07:36] <vila> naoki: yup, can you break it ?
[07:37] <naoki> vila: bzr uses win32utils.get_unicode_argv. So bzr recieve args by unicode
[07:40] <vila> naoki: meh
[07:40] <bialix> _o/
[07:40] <bialix> _o|
[07:40] <bialix> _o/
[07:41] <naoki> Please wait some minutes. (I'l
[07:42] <naoki> I'll test your branch from now.
[07:43] <naoki> I'm using Japanese WinXP.
[07:43] <naoki> add new file in Chinese name. commit, and modify it.
[07:45] <naoki> vila: http://paste.ubuntu.com/420255/
[07:45] <naoki> This is your fix.
[07:46] <vila> naoki: great, can you send me a tarball of the wt/branch/repo
[07:47] <vila> what is cp932 ?
[07:47] <naoki> Japanese codepage. It's Shift_JIS + some extra chars.
[07:48] <vila> is the filename valid in this encoding ?
[07:48] <naoki> No. It isn't.
[07:48] <vila> then we have a far larger problem
[07:48] <naoki> But I can add that file name from TortoiseBZR, qbzr, etc.
[07:49] <naoki> Because bzr recieves args by unicode.
[07:49] <bignose> I'm trying to convert a repository stored on a remote server to which I have only SSH and SFTP access; it doesn't have Bazaar installed.
[07:49] <bignose> $ bzr check sftp://bzr@fs/~/
[07:49] <bignose> Format RepositoryFormatKnit3() for sftp://bzr@fs/~/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
[07:49] <vila> naoki: from the command line ?
[07:49] <bignose> $ bzr upgrade sftp://bzr@fs/~/
[07:49] <bignose> bzr: ERROR: Cannot convert from format RepositoryFormatKnit3() to format RepositoryFormat2a().    Does not support nested trees
[07:50] <bignose> am I correct in thinking that current Bazaar 2.1 should be able to convert any previous Bazaar repository format to 2a?
[07:50] <bignose> if not, what are the limits? if so, why is this not working?
[07:50] <naoki> vila: I'ts very difficult. I can't input chinese from keyboard. But I can copy&paste the filename.
[07:51] <naoki> vila: I can do diff in cmd.exe http://paste.ubuntu.com/420255/
[07:52] <maxb> bignose: Knit3 is dirstate-with-subtree, you can only convert it to other formats which also support -subtree. That's what the "Does not support nested trees" is about
[07:52] <vila> naoki: 'bzr diff' alone works right ?
[07:53] <naoki> vila: filename is broken. But others are all right.
[07:53] <vila> naoki: I smell something wrong about bzr receiving unicode...
[07:53] <vila> naoki: broken how ?
[07:54] <vila> naoki: is GetCommandLineW documented somewhere ? My feeling is that this function handle the conversion from the input encoding to unicode
[07:55] <naoki> vila: This is how to reproduce http://paste.ubuntu.com/420255/
[07:55] <vila> naoki: well, almost, I don't have winmerge nor your branch :-/
[07:56] <naoki> vila: No. On Windows, filenames and commandline arguments are unicode internally.
[07:56] <naoki> vila: So, sys.argv is encoded string. Not original.
[07:56] <vila> naoki: yes, in bzr too, yet there are encoded.edecoded at appropriate times
[07:56] <vila> you mean decoded ?
[07:57] <vila> python use decode to go from one encoding to unicode and encode to go from unicode to one encoding
[07:57] <bignose> maxb: okay. so what current format could I convert this repository to?
[07:57] <naoki> vila: I means Python's default sys.argv. It is from main(int argc, char *argv[]). And argv is encoded.
[07:58] <naoki> (Python3's sys.argv is from main(int argc, wchar *argv[]). So it's native unicode)
[07:59] <bignose> ‘bzr help current-formats’ doesn't mention subtree anywhere in its list.
[07:59] <bignose> is there any currently-supported format that supports subtree?
[07:59] <vila> naoki: AFAIK you can't *type* unicode on the command line, you always use the user encoding *then* python decodes it into unicode
[08:01] <naoki> vila: Windows command prompt is based on unicode. So I can use unicode on command line.
[08:01]  * vila scratches head
[08:01] <bignose> naoki: it's important to realise that “encoded string” is *not* Unicode. Those are two different data types.
[08:02] <bignose> either you have an encoded string, which is not unicode
[08:02] <naoki> vila: And win32utils.get_unicode_argv() recieves command line by unicode.
[08:02] <bignose> or you have unicode, which is not an encoded string.
[08:02] <bignose> you need to be clear about which you have at any given moment.
[08:03] <vila> naoki:  win32utils.get_unicode_argv() relies on GetCommandLineW and I suspect the later handles the decoding, where is it documented ?
[08:04] <naoki> vila: commandline is UTF-16 in Windows. GetCommandLineW gets the commandline without encoding/decoding.
[08:04]  * vila blinks
[08:05] <vila> naoki: there are several places in bzr where we use osutils.get_user_encoding() even on win32 (see win32utils), I'd really like to understand what is happening here
[08:05] <vila> bialix: can you help here ?
[08:06] <naoki> bzr uses that encoding when output to console.
[08:07] <naoki> And then, console decode it to utf-16 and show.
[08:08] <naoki> On windows API, everything is Unicode based. And encoded string is used for compatibility to ascii based application.
[08:08] <vila> naoki: no, we use different encodings for: use, terminal and file system
[08:09] <vila> http://stackoverflow.com/questions/846850/how-to-read-unicode-characters-from-command-line-arguments-in-python-on-windows seems to imply that GetCommandLineW is indeed decoding into unicode
[08:10] <vila> naoki: i.e. the command-line itself is not in unicode, it's decoded by GetCommandLineW
[08:11] <naoki> vila: GetCommandLineW doesn't decode anything. commmandline is unicode and GetCommandLineW pass it.
[08:13] <vila> naoki: why does python needs GetCommandLineW then ?
[08:13] <naoki> vila: sys.argv is **encoded** arguments. So it may be broken.
[08:14] <naoki> vila: It is why we should use GetCommandLineW to get unicode arguments.
[08:15] <vila> naoki: ok, so we disagree on that, you say the command line is unicode, I say it's encoded in user encoding, what code can you use to decide on that ?
[08:15] <vila> naoki: 'sys.argv is **encoded**' by who ?
[08:16] <vila> naoki: and how ? That's what we need to find to be able to replicate around subprocess.Popen
[08:16] <naoki> vila: MSVCRT encode arguments and pass it to main()
[08:16] <vila> naoki: then Popen most probably will do the same
[08:16] <naoki> vila: Python3's subprocess module uses CreateProcessW. So it can pass unicode arguments to child process.
[08:17] <naoki> vila: But Python2's subprocess can't handle unicode.
[08:17] <vila> haaaaa, but we are stuck with python2 so far
[08:17] <vila> naoki: can we trick it into accepting utf8 encoding ?
[08:17] <naoki> vila: So, there are 2 ways: 1. Use CreateProcessW manually like GetCommandLineW.
[08:18] <bialix> vila: on Windows command line is unicode
[08:18] <naoki> vila: 2. replace chars that doesn't represent in user_encoding.
[08:19] <vila> bialix: meh, when is the user encoding used then ?
[08:19] <vila> naoki: 1) sounds better,
[08:20] <bialix> vila: internal Windows API is unicode (functions end with W), but there is also ANSI API (functions end with A), under the hood A functions do encoding on the fly, IIUC
[08:20] <vila> naoki: about 2) replacing chars means losing some info, what are we trynig to preserve here and can't we switch to a purely arbitrary name with ascii only chars ?
[08:20] <bialix> python uses A
[08:21] <bialix> I guess for Windows 98 compatibility
[08:22] <MvG> Hi guys! I've just offered the bzr-bash-completion plugin for merging into bzr.dev, as distro packagers as well as users mostly prefer this over an independent plugin. https://code.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 open for comments. I'll be around.
[08:24] <vila> bialix, naoki: Sorry to sound dense, but how to you guys can be sure that the command line is unicode ? The fact windows *internally* uses a unicode API doesn't guarantee that the command line itself doesn't respect the user encoding
[08:24] <vila> otherwise what's the point of the user encoding ? Why do we use it in win32utils.get_appdata_location() for example ?
[08:24] <bialix> vila: it depends on how program is launched
[08:25] <vila> bialix: all right, let's focus to subprocess.Popen then since that's where the bug seems to be actually
[08:25] <bialix> user encoding? what's wrong with user encoding?
[08:25] <bialix> vila: subprocess.Popen can't use unicode API
[08:26] <bialix> there is some code in subprocess.py explicitly disabled unicode on Windows.
[08:26] <vila> bialix: nothing wrong with user encoding, my question is why do we use it to *decode* some data if it's already unicode ?
[08:26] <bialix> vila: lemme look at get_appdata...blah-blah-blah
[08:27] <bialix> vila: I don't see there user_encoding
[08:27] <vila> naoki: to be clear, I'm not saying you're wrong, just that I don't understand the logic here :)
[08:28] <vila> bialix: wtf
[08:28] <bialix> vila: os.environ holds data as plain strings
[08:28] <vila> bialix: oh, it's in the docstring
[08:29] <bialix> Mark Hammond said it's actually should be 'mbcs' encoding
[08:29] <vila> bialix: hmm, mbcs is the file system encoding right ?
[08:30] <bialix> well, mbcs it's a ... mbcs!
[08:30] <bialix> file system encoding depends on file system. AFAIK NTFS s unicode
[08:31] <vila> bialix: ha, look at _ensure_unicode which call get_user_encoding
[08:31] <bialix> I'm not quite understand internals of mbcs, but it's a very strange thing
[08:31] <bialix> vila: yep
[08:32] <bialix> vila: on my Russian system mbcs == cp1251
[08:32] <bialix> cp1251 is also russian
[08:32] <bialix> maybe on Japanese/Chinese systems mbcs means something different, I really don't know
[08:34] <naoki> 'mbcs' is an alias. It is set by site.py
[08:35] <bialix> I suspect something like that
[08:41] <naoki> spawn is easier than CreateProcess: http://paste.ubuntu.com/420255/
[08:41] <vila> naoki: I just pushed a new revision (forcing mbcs for subprocess.Popen), can you re-try
[08:42] <vila> naoki: that's still the same url you've been pasting for the third time, is this intended ?
[08:42] <naoki> miss. http://paste.ubuntu.com/420272/
[08:43] <vila> naoki: that one is about spawn
[08:44] <naoki> spawnw uses unicode.
[08:44] <naoki> So I think we can use it instead of subprocess.call
[08:44] <naoki> AFK, sorry.
[08:45] <vila> naoki: you mean _wspanlp uses unicode, ok, but what was 'miss' referring to ?
[09:42] <lifeless> its kindof sad shutting down my persistent IRC server
[09:42] <spiv> Heh.
[09:43] <spiv> Try to think of it as liberating!
[09:43] <lifeless> sure
[09:43]  * lifeless tries
[09:43] <spiv> Just etch "/win" on your glasses and you won't miss a thing.
[09:43] <lifeless> rotfl
[09:54]  * igc dinner
[10:16] <naoki> I'm back.
[10:16] <naoki> http://paste.ubuntu.com/420312/
[10:16] <naoki> I find that subprocess can use pywin32's CreateProcess.
[10:17] <naoki> I confirm that changeing if 0: => if 1: fixes this problem.
[10:17] <naoki> So, win32utils can replace some subprocess attributes with pywin32.
[10:18] <naoki> Or, we can just copy subprocess.py into bzrlib and fix that.
[10:19] <cbz> When i have a branch inside a repository, and i've deleted branches inside that shared repository, is there a way of getting that repository t throw away the stuff it doesn't need any more?
[10:20] <AfC> cbz: the bullet-proof way is to make a new repository, branch the branches you like from under the old repository to locations within the new one, then ta-da, remove the old repository & all its branches.
[10:20] <AfC> cbz: there is a "garbage collector" floating around somewhere, too
[10:22] <cbz> Okay. If I choose the first option, is bazaar able to work out the rlationships between the branches and store things effectively?
[10:22] <spiv> Yes.
[10:23] <cbz> I assumed the shared repository only really worked because you were branching within it, and so bazaar kept track of the relationships between versions that way
[10:24] <spiv> Even if you branch from somewhere outside the shared repo into the shared repo, bazaar will avoid storing duplicate records.
[10:25] <cbz> Okay.
[10:25] <spiv> (Mostly; the small amount of redundancy that can occur will be continually tidied up by the regular autopacking that occurs as new data is added to a repo.)
[10:26] <MvG> I assume that branching everything over into a new repo will still loose non-versioned data like parent branches, push branches, merge branches and so on, right?
[10:28] <AfC> MvG: yes
[10:28] <AfC> (good point)
[10:29] <cbz> so the best thing is probably to get to the point where every project has one branch and then just branch that to the new location and then rebind?
[10:30] <cbz> (I'm tracking remote subversion repositories)
[10:30] <MvG> Copying .bzr/branch/branch.conf files might work as well.
[10:31] <MvG> I'd suggest one repo per project in any case, as there is little point in sharing a repo between branches with no common history.
[10:33] <MvG> lifeless: are you around?
[10:46] <vila> naoki: sorry, just noticed you're back
[10:48] <vila> naoki: yeah, I've seen the if 0 in subprocess too, since that's part of python standard lib, it's... a problem to touch it, and I thought you said we needed CreateProcessW not CreateProcess (whatever the correct spelling is)
[10:48] <naoki> pywin's CreateProcess uses CreateProcessW
[10:49] <vila> naoki: re-reading your patch, I see you also use 'mbcs' encoding so my last patch should work no ? (the tests should fail though)
[10:50] <lifeless> MvG: a little; last stages of house packup before moving country
[10:50] <MvG> lifeless: You're moving, too? Funny, I'm amidst boxes as well.
[10:51] <MvG> lifeless: Anyway, I was wondering whether you could review https://code.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 as you reviewed its predecessor.
[10:51] <naoki> vila: Maybe, getfilesystemencoding() is better on non-win32
[10:51] <lifeless> MvG: realistically, not until tuesday/wednesday
[10:51] <naoki> vila: because _subprocess module uses filesystemencoding.
[10:51] <lifeless> MvG: has vila reviewed it ?
[10:52] <vila> naoki: no, getfilesystemencoding should be used only when dealing with file system directly
[10:52] <lifeless> naoki: python trunk using fsencoding for subprocess module on win32
[10:52] <lifeless> fwiw
[10:52] <MvG> lifeless: Yes, he has, and I'v eadded some buts of documentation and minor style fixes in response.
[10:52] <vila> lifeless: I did, but it needs a second review
[10:52] <lifeless> vila: can you mention it to John then ?
[10:53] <lifeless> MvG: in 12 hours a team of packers arrives to pack - a drop-dead deadline ;)
[10:53] <lifeless> we've still got ~ 3 cubic metres of recycling and landfile to deal with and other similar things
[10:53] <lifeless> or I'd be delighted to review it for you
[10:55] <MvG> lifeless: I understand. I've got more like 44h before I've got to start loading things.
[10:55] <naoki> lifeless: I'm wrong. not _subprocess. posixmodule.execv uses Py_FileSystemDefaultEncoding
[10:56] <MvG> There is no real urgent need, but I'd like to get stuff off my head nevertheless, so I'm bugging people to review my requests.
[10:56] <naoki> So, subprocess.call in posix uses filesystem encoding if it is available.
[10:56] <naoki> But I think there are no need to encode by hand on non-win32 platform
[10:58] <lifeless> vila: alternatively you could make a call that its small enough vs the predecessor and just land it
[10:58] <lifeless> if the predecessor had 2 conditional +1s
[10:59] <naoki> This is a monkey patch to force subprocess uses pywin32's CreateProcess http://paste.ubuntu.com/420337/
[10:59] <vila> lifeless: it didn't, you're the only one that has reviewed it
[10:59] <lifeless> ah
[10:59] <lifeless> well if you can point John at it, it would be good to get MvG the feedback he needs
[11:00] <lifeless> MvG: if I can, I will, but I'd like to make other primary arrangemetns for you
[11:00] <MvG> lifeless: Thanks!
[11:00] <vila> lifeless: what is the status of pqm at this hour ?
[11:01] <lifeless> vila: it should be working
[11:01] <lifeless> vila: its generally landing things that should land, and we ahven't had it blow up for bzr today, at all
[11:08] <a`> DCC SEND "XXXXXXXXXXXXXXXXXXXXXXXXXX" 0 0 0
[11:08] <LeoNerd> *slow handclap*
[11:10] <vila> naoki: brr, monkey-patching such a large part without any tests is scary
[11:11] <vila> naoki: :-(
[11:12] <vila> naoki: I feel I'm not helping as I should here, maybe I should just decline to review this patch, I miss some windows knowledge to be really effective I'm afraid :-(
[11:49] <cbz> whats the equivalent of hg incoming on bazaar?
[11:50] <spiv> bzr missing
[11:51] <spiv> Hmm, "bzr missing --theirs-only" is probably a more exact equivalent.
[11:58] <lifeless> vila: its generally landing things that should land, and we ahven't had it blow up for bzr today, at all
[12:03] <vila> lifeless: I did a pqm-submit ~30 minutes ago and it doesn't seem to be processed so far :-/
[12:14] <maxb> Can I suppress bzr's default ignore patterns on a per-branch basis?
[12:25] <lifeless> maxb: you can use negative matches, or edit your ~/.bazaar/ignores
[12:25] <lifeless> maxb: bzr doesn't have any hard coded defaults at all
[12:27] <lifeless> maxb: instead it writes to ~/.bazar/ignores, IFF it does not exist
[12:27] <lifeless> oh yay, firefox fail just lost one windows worth of tabs ><
[12:38] <vila> lifeless: look into history -> Recently closed {tabs|windows}
[12:39] <vila> lifeless: should I ping a losa for pqm, it seems stucked to me
[12:39] <vila> lifeless: what did change from yesterday ?
[12:40] <lifeless> vila: untangled stdout, stderr
[12:41] <lifeless> vila: it looks like it thinkgs it just finished aaron's merge
[12:41] <lifeless> PQM is not currently processing additional requests
[12:41] <lifeless> it has a stop.patch present
[12:41] <vila> lifeless: ha yes, the patch you mentioned, so how was that last submission ... yeah, but that was long ago no ?
[12:41] <lifeless> losa ping: please remove stop.patch from bzr's pqm queue
[12:41] <vila> >-/
[12:43] <MvG> Some bzr selftests related to pycurl seem to fail when curl is built against GnuTLS.
[12:44] <MvG> Is this known, or should I report a bug?
[12:44] <james_w> I've not seen a bug on it
[12:45] <MvG> OK, then I'll report once my selftest is through and I can actually scroll around and mark the whole message without the progress bar update interfering.
[12:52] <vila> MvG: that rings a bell, any more info ?
[12:53] <vila> I seem to remember some certificate issues around that but that's from some years ago
[12:53] <MvG> vila: got pycurl error: 56, GnuTLS recv error (-9): A TLS packet with unexpected length was received., (56, 'GnuTLS recv error (-9): A TLS packet with unexpected length was received.')
[12:54] <vila> MvG: hmm, so that's a CURLE_RECV_ERROR that we are supposed to trap and raise errors.ConnectionReset
[12:55] <vila> MvG: does that help ?
[12:55] <MvG> Not immediately.
[12:55] <vila> MvG: and what is your context (why GnuTLS) ?
[12:55] <MvG> Because I can.
[12:55] <vila> LOL
[12:56] <MvG> Using Gentoo Linux, and been using GnuTLS for a while for most apps that support it.
[12:56] <MvG> It's caused problems before, but usually it's because apps depend on things they shouldn't.
[12:56] <vila> ha, gentoo, that's the keyword I wanted :)
[12:57] <vila> Any LOSA around ?
[12:58] <vila> LOSa LOsa Losa losa one of them should match ;)
[12:59] <MvG> vila: http://paste.ubuntu.com/420380/ has the selftest output.
[13:00] <vila> MvG: So, at first glance, I'd say GnuTLS is lying or reporting things in a strange way, the test is about an unknown file, so we expect a 404
[13:01] <MvG> Who is implementing the https server? Where is the certificate private key? Maybe I can snoop on the traffic to shed some light.
[13:02] <vila> MvG: look at bzrlib/tests/https_server.py and...
[13:02] <vila> MvG: into bzrlib/tests/ssl_certs
[13:04] <vila> MvG: now, that's a self-signed certificate and maybe GnuTLS barfs on that
[13:04] <MvG> vila: Shouldn't, but I'll have a look.
[13:04] <MvG> After lunch...
[13:05] <vila> oooh, lunch, 14:00 good idea !
[14:00] <Chex> vila: good morning there
[14:00] <vila> Chex: Yeah ! Hi !
[14:01] <vila> Chex: previously on this channel: <lifeless> losa ping: please remove stop.patch from bzr's pqm queue
[14:01] <vila> Chex: don't ask me what it means, except that it seems to be involved in pqm being currently stucked
[14:02] <Chex> vila: i understand, fixing now
[14:02] <Chex> vila: removed, should be able to process now
[14:03] <vila> Chex: thanks
[14:06] <Chex> vila: no worries
[14:47] <SamB_web> hmm, there's something wrong with the wiki ... see http://wiki.bazaar.canonical.com/HelpOnMoinWikiSyntax#Smileys%20and%20Icons
[14:48] <siks> 7away gone
[14:48] <siks> whoops
[14:57] <vila> SamB_web: it's a wiki, just update it... err wait
[14:57] <vila> SamB_web: It's a serious wiki who needs simleys ???
[14:57] <vila> SamB_web: seriously, just file a bug :)
[15:21] <[1]reggie> hey gang
[15:22] <[1]reggie> any idea what would be keeping bzr 2.0.4 qcomit from sending commit emails when used inside virtualbox on windows 7 x64?
[15:23] <[1]reggie> works fine on host machine
[15:23] <jave> I'm trying to clone a branch from launchpad, but nothing seems to happen
[15:58] <michaelforrest> what's the quickest way to get the last revision any particular file changed?
[15:58] <vila> michaelforrest: bzr qblame file
[16:09] <michaelforrest> vila: is there any way to get more of a concise output do you know? I just want the number
[16:10] <michaelforrest> bzr [?] file.png
[16:10] <michaelforrest> > 14
[16:10] <vila> no
[16:11] <vila> well, not that concise
[16:11] <michaelforrest> I'm trying to see where the source browsing bit of launchpad gets it
[16:11] <james_w> bzr log file.png?
[16:11] <james_w> bzr log file.png --limit 1
[16:11] <michaelforrest> limit 1 isn't too bad
[16:12] <michaelforrest> or if I could get a list of all the files in a repo / folder with their last-updated revnos
[16:13] <vila> michaelforrest: what's the use case ?
[16:27] <michaelforrest> vila: quite complicated :S
[16:28] <michaelforrest> I am making a website that pulls files from a repository and I want it to show the last revision number of each file
[16:52] <vila> michaelforrest: nothing available from the command-line for that, but if you cmd_inventory in bzrlib.builtins.py should be a good starting point
[16:54] <vila> s/you/& look at/
[17:23] <krisives-gearbox> michaelforrest: I just made an update system with Bazaar that keeps 90 client sites in sync
[17:24] <krisives-gearbox> bzr revno file would work, right?
[17:24] <krisives-gearbox> I do: `bzr revno `bzr ls -VR`` kinda (but for TAR)
[17:24] <michaelforrest> krisives-gearbox: that's what I thought it would be yeah
[17:24] <michaelforrest> but it doesn't seem to work for me
[17:25] <krisives-gearbox> What are you executing / getting in response?
[17:25] <michaelforrest> well - yeah - it doesn't give a file-specific revno
[17:26] <krisives-gearbox> Ah indeed `bzr revno` only gives the branch version, my bad
[17:28] <jam> krisives-gearbox: 'bzr revision-info --tree' might be what you want
[17:29] <krisives-gearbox> jam, that's for michaelforrest
[18:42] <mkanat> igc: I actually need somebody to do my merges; I'm not in the appropriate group, I'm pretty sure.
[18:42] <mkanat> igc: (This is in relation to the loggerhead pygments fix.)
[19:29] <jam> mkanat: can you link me to the merge proposal, I can do it
[19:30] <mkanat> jam: Sure.
[19:30] <mkanat> jam: https://code.edge.launchpad.net/~mkanat/loggerhead/limit-pygments/+merge/23900
[19:30] <mkanat> jam: It probably also needs a status update.
[19:31] <jam> mkanat: just a thought, why map(cgi.escape) rather than cgi.escape(text).split() ?
[19:31] <jam> so it doesn't escape the '\n' ?
[19:31] <jam> and doesn't text.split('\n') strip the final \n ?
[19:31] <mkanat> jam: That's how loggerhead does it currently.
[19:31] <mkanat> jam: Outside of this code. I don't think it would matter, though.
[19:31] <mkanat> jam: I could do it the other way--it'd probably be slightly faster.
[19:32] <jam> mkanat: I don't know the details of cgi.escape
[19:32] <jam> so either way
[19:32] <mkanat> jam: Nor do I, I was cargo-culting because I wanted to maintain exact behavior.
[19:32] <jam> if you've tested this way, then I think it is worth just landing, can be tweaked later
[19:32] <mkanat> jam: Okay.
[19:34] <jam> ah, you know what... I *don't* have access rights
[19:34] <jam> I thought I did, but the commit failed
[19:34] <mkanat> jam: Ah, okay. I'll wait for mwhudson or igc.
[19:34] <jam> oh well, we'll poke igc for it tonight :)
[19:36] <chx> given the state of the bundle buggy I am not exactly sure i want to use it. is there another merge tool for the human gatekeeper workflow?
[19:55] <mkanat> I imagine spm will want to update codebrowse after we commit it, too.
[20:09] <MFen> hello
[20:09] <MFen> someone gave me this page/branch to look at .. https://code.launchpad.net/~washort/pymeta/matched-sequences
[20:09] <MFen> dash gave it to me actually. maybe he can answer :)
[20:10] <MFen> what's an easy way to diff that against the branch it's derived from
[20:11] <dash> MFen: hi again :)
[20:12] <MFen> howdy
[20:12] <dash> the general answer is that you can use "ancestor:somebranchurl" as a revision specifier
[20:13] <dash> to indicate the revision where the current branch diverged from the ancestor
[20:13] <dash> so in this case:
[20:13] <MFen> so hg diff -rancestor:lp:pymeta
[20:13] <dash> bzr diff -rancestor:lp:pymeta lp:~washort/pymeta/matched-sequences
[20:13] <MFen> err bzr
[20:14] <dash> right. you can leave the second url off if you're doing it froma working copy. :)
[20:15] <MFen> aha. that worked. thanks :)
[22:31] <cbz> anyone else using bzr-svn to use bazaar with a subversion repository?
[22:37] <dash> cbz: every day
[23:15] <jam> igc: are you around?
[23:31] <igc> morning
[23:31] <igc> hi jam
[23:31] <jam> morning igc
[23:32] <jam> just wanted to discuss some of the loggerhead changes I want to do
[23:33] <jam> igc: I don't have a lot of time, but if you have 5-10 minutes could we chat?
[23:33] <igc> jam: that would be great
[23:34] <igc> jam: irc or skype?
[23:35] <jam> skype might be the fastest
[23:36] <igc> jam: cool. I'm on
[23:37] <jam> not according to my skype