[01:34] <Noldorin> jelmer, just saw your fix committed for an old bug of mine :
[01:34] <Noldorin> :-)
[07:36] <vila> hi all !
[08:19] <jelmer> hi vila
[08:19] <vila> jelmer: hey !
[09:07] <jelmer> hi spiv
[09:07] <mgz> monring all
[09:07] <vila> mgz: hey !
[09:10] <mgz> hey vila
[09:11] <jelmer> hi mgz
[09:17] <mgz> jelmer: did you see poolie's channel invite?
[10:39] <jelmer> vila: is there anything left that's blocking us from porting more option users over to the new config system?
[10:40] <mgz> that would be good to do, in a big bang
[10:40] <mgz> most plugins have a trunk-tracking release
[10:41] <jelmer> mgz: so there's nothing in particular blocking it?
[10:41] <mgz> we'll see when vila returns, but not that I'm aware of.
[10:42] <mgz> the one issue is if it makesmore overhead without also tackling the multiple-open issue.
[10:42] <mgz> I think from the instrumentation of the test suite he did vila determined it was okay.
[10:45] <jelmer> we're already using the config system for some of our options though, right?
[10:50] <mgz> I'm not comletely clear where the line is.
[11:07] <vila> jelmer, mgz: so, there are two bugs on the plate: bug #832042 and bug #832046
[11:07] <vila> the later is blocking the system-wide config file stuff imho
[11:08] <vila> the former... well, if we start caching the config stack in the branch for example, we already address some the un-needed IOs
[11:08] <vila> but to properly fix it, my feeling is that we need some help from library_state
[11:09] <vila> other than that, there are various minor bugs that could be fixed while migrating the related options
[11:09] <vila> and finally, most of the remaining options can be migrated right now
[11:10] <vila> I should just fdi
[11:10] <Merwin> patch: **** Only garbage was found in the patch input.
[11:10] <Merwin> What does it means ?
[11:11] <vila> I've just proposed a patch against udd which does such a complete migration with only same minimal additions (expanding options by default)
[11:11] <vila> Merwin: 'patch' or 'bzr patch' ?
[11:12] <Merwin> bzr patch
[11:12] <Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/OpenAssur/server$ bzr patch OpenAssur_TM_V2.patch
[11:12] <Merwin> patch: **** Only garbage was found in the patch input.
[11:12] <Merwin> bzr: ERROR: Patch application failed
[11:12] <vila> Ok, that's from bzrtools ?
[11:12] <mgz> generally it means you gave patch something that doesn't look like a patch
[11:12] <Merwin> yep
[11:12] <mgz> eg, `echo junk | patch`
[11:13] <vila> probably garbage in the patch file that defeat parsing, can you paste it ?
[11:13] <vila> pastebin
[11:13] <vila> !pastebin
[11:14] <Merwin> http://friendpaste.com/299Lm5ens57L60noBAjrpG
[11:14] <Merwin> it looks like a valid patch to me -_-
[11:17] <mgz> two things jump out, doesn't have +++ --- file lines after modified, and has non-ascii
[11:17] <mgz> `bzr patch` is pretty thin though, just try patch itself?
[11:18] <mgz> eg. `patch -p0 < OpenAssur_TM_V2.patch`
[11:19] <Merwin> same error
[11:19] <Merwin> I'll ask the guy who sent it how he did it :p
[11:19] <Merwin> The good way is bzr diff right ?
[11:20] <mgz> yup.
[11:27] <vila> Merwin: or even better: publishing a branch
[11:27] <Merwin> Yep in this case we can't :-(
[11:29] <mgz> you can probably manually edit the patch to make it work
[11:30] <mgz> if you add after the [11:33] <jelmer> vila: I'm going to have a look at migrating the gpg options
[11:34] <vila> jelmer: cool, don't hesitate to ping me if you encounter any issue or misunderstanding
[11:35] <vila> jelmer: on the other hand, I don't want to divert you from other important bits ;)
[12:20] <jelmer> vila: moving commit builder over to config stack saves 9 HPSS calls :)
[12:20]  * vila profits :)
[12:20] <vila> jelmer: yeah !
[12:21] <vila> jelmer: because it avoids a call to ensure_real or because it uses a cached config ?
[12:21] <vila> or both :)
[12:22] <jelmer> vila: because it uses a cached config
[12:22] <jelmer> commits over HPSS still use a lot of VFS calls
[12:22] <vila> double \o/
[12:23] <vila> testing list_package in udd queries launchpad,
[12:24] <vila> OMG, that takes far too long,
[12:24] <vila> let's kill ./selftest.py
[12:24] <vila> huh ?? backtrace in import_package.py ? Wtf ?
[12:24] <vila> oooooh
[12:25] <vila> remember that signals are caught by the main thread ? remember that import_package.py defines a signal handler ? Here you go :)
[12:25] <jelmer> urgh
[12:25] <vila> pfew, at least I wasn't triggering real imports during a test run :)
[12:25] <vila> jelmer: indeed, but I won't tackle that one now, just filing a bug
[12:26] <vila> just one more example that test after is bad ;)
[13:10] <jelmer> vila: hmm, the from_unicode function isn't actually called with unicode strings?
[13:10] <vila> wow, that is unexpected
[13:11] <vila> grr 'Alarm clock'
[13:13] <vila> selftest.timeout = 60000 \o/
[13:29] <jelmer> vila: nevermind, was my own option
[13:29] <vila> jelmer: where was it coming from ?
[13:30] <vila> default value ?
[13:31] <jelmer> vila: yep
[13:31] <jelmer> vila: default_email()
[13:37] <vila> jelmer: something worth fixing or ?
[13:37] <vila> .. or was the error clear enough to debug ?
[13:49] <jelmer> vila: it was an issue I introduced
[13:54] <jelmer> vila: found it
[13:54] <jelmer> vila: environment variables aren't converted to unicode
[13:54] <vila> jelmer: rings a bell ;)
[13:56] <vila> jelmer: mgz will summarize the issues better than me
[13:56] <mgz> I've got a branch for that.
[13:56] <mgz> problem is it breaks things
[13:57] <mgz> it's in my current bunch though, so will propose sometime
[13:58] <mgz> okay, this works, and doesn't seem toooo violently bad
[13:58] <jelmer> mgz: that would be nice, my branch depends on it :)
[13:59] <mgz> which envvar is causing the grief for email though?
[13:59] <mgz> for paths, we at least have something to go on, and simple values it doesn't matter
[13:59] <jelmer> mgz: BZR_EMAIL and EMAIL
[13:59] <mgz> other strings are more problematic
[14:00] <mgz> hm. email should really be ascii, but I guess auto %-escaping would be okay?
[14:01] <mgz> ...I think this even assembles into a one-liner
[14:01] <jelmer> mgz: it also contains the users realname
[14:02] <jelmer> mgz: also, the logic in config assumes that there are no differences in encoding for environment variables
[14:03] <mgz> ah yes
[14:03] <mgz> ctypes.c_void_p.in_dll(ctypes.pythonapi, "Py_FileSystemDefaultEncoding").value = ctypes.cast(ctypes.c_char_p("utf-8"), ctypes.c_void_p).value
[14:03] <mgz> so, just the locale and falling back to utf-8 seems reasonable then - and throwing an error if that doesn't work would be okay
[14:04] <mgz> because automated things that don't set a proper locale shouldn't then be supplying bogus values and expecting stuff to work
[14:05] <mgz> ^note, using a string literal in the source is very important for that statement
[14:05] <mgz> intern(s) otherwise, string must be immortal.
[14:06] <mgz> hm, wait, still wrong.
[14:07] <vila> don't forget to leave a way for the user to override
[14:07] <vila> in ASCII :)
[14:07] <vila> I mean, the way to override should require only ascii
[14:20] <smoser> jelmer, you mentione dto me that i could 'set "commit-message-from-changelog = False" in bzr-builddeb's config, e.g. ~/.bazaar/builddeb.conf'
[14:20] <smoser> i put this in ~/.bazaar/builddeb.conf, but to no avail:
[14:21] <smoser>  commit-message-from-changelog = False
[14:21] <smoser> bzr commit still wants to just use the changelog entry
[14:26] <jelmer> smoser: hi
[14:26] <smoser> hi :)
[14:26] <jelmer> smoser: you'll need a [BUILDDEB] section for it as well I think
[14:26] <smoser> ah. yeah, that makes sense.
[14:27] <jelmer> smoser: I can understand why it's necessary, but I'm not sure if I agree it makes sense :)
[14:27] <jelmer> AFAIK there aren't any other possible sections in that file
[14:27] <smoser> well, i remember that i've had such a section other places.
[14:29] <smoser> jelmer, hm..
[14:29] <smoser> http://paste.ubuntu.com/764943/
[14:29] <smoser> seems to not work
[14:30] <smoser> yeah, strace shows its not even reading that file.
[14:31] <smoser> bazaar.conf and locations.conf are all that seem to be being read.
[14:31] <smoser> adding that section ot bazaar.conf made no difference
[14:35] <smoser> yeah... i can't seem to change that behavior any way. not even in the local repository .bzr-builddeb/default.conf
[14:36] <jelmer> smoser: is your .bzr-builddeb/default.conf versioned?
[14:37] <jelmer> (it will only be read if versioned)
[14:39] <soren> smoser: Which version of builddeb do you use?
[14:39] <smoser> well, it was not, but making it versioned had no affect
[14:39] <smoser> i'm using precise
[14:39] <soren> smoser: And you don't have a leftover plugin in ~.bazaar/plugins?
[14:40] <soren> ~/.bazaar/plugins, I mean.
[14:40] <smoser> $ ls ~/.bazaar/plugins
[14:40] <smoser> ls: cannot access /home/smoser/.bazaar/plugins: No such file or directory
[14:40] <smoser> soren, so you do not see this behavior?
[14:41] <vila> smoser, soren : what bzr versions are you using ?
[14:41] <soren> smoser: To be honest, I've not tried.
[14:41] <smoser> $ dpkg-query --show bzr bzr-builddeb
[14:41] <smoser> bzr	2.5.0~beta3-2ubuntu1
[14:41] <smoser> bzr-builddeb	2.7.9ubuntu1
[14:41] <soren> smoser: I was just looking at the code.
[14:41] <smoser> soren, its pretty easy to reproduce
[14:41] <soren> Oh.
[14:41] <smoser> bzr branch lp:ubuntu/some-thing
[14:41] <smoser> cd some-thing
[14:41] <soren> This change is newer than that.
[14:41] <soren> 2.7.9 is r600.
[14:42] <smoser> dch -i... add bogus entry... modify some file...
[14:42] <soren> The change you need landed at 625-ish.
[14:42] <smoser> bzr commit
[14:42] <soren> http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/625
[14:42] <jelmer> soren: in older versions you can disable it with a config option, we've just flipped the default value of the option
[14:43] <soren> Sorry, 2.7.9 was 620.
[14:43] <soren> But still < 625.
[14:44] <soren> 625: Jonathan Riddell 2011-10-07 [merge] add commit-message-from-changelog config option for those who prefer to set their own commit message
[14:44] <soren> 620: Jelmer Vernooij 2011-10-01 {2.7.9} releasing version 2.7.9
[14:44] <jelmer> smoser: echo "[BUILDDEB]\ncommit-message-from-changelog = False\n" > ~/.bazaar/builddeb.conf should be sufficient, surprising that doesn't work :-/
[14:45] <jelmer> I can confirm that actually setting it to True changes the behaviour in lp:bzr-builddeb, and there are tests that the option behaves correctly in the version you're running
[14:46] <soren> bzr grep -r tag:2.7.9 bzr grep -r tag:2.7.9 commit-message-from-changelogcommit-message-from-changelog
[14:46] <soren> whoops
[14:46] <soren> bzr grep -r tag:2.7.9 commit-message-from-changelog
[14:46] <soren> Gives me nothing.
[14:47] <jelmer> soren: sorry, I misunderstood
[14:47] <jelmer> soren: You're right, riddell didn't at the option at the same time as the feature
[14:47] <jelmer> for some reason I was assuming they were
[14:48] <soren> smoser: Grab a fresh checkout, and you're good. bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb
[14:52] <smoser> soren, but then i'll just be complaining again sometime down the road and you'll ask if i have any stuff in ~/.bazaar/plugins :)
[14:55] <jelmer> vila: https://launchpadlibrarian.net/86987008/buildlog_ubuntu-precise-armhf.bzr_2.5.0~beta4-1ubuntu1_FAILEDTOBUILD.txt.gz
[14:55] <jelmer> vila: do you remember seeing *that* test fail earlier?
[14:55] <jelmer> bzrlib.tests.per_transport.TransportTests.test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib)
[14:58] <vila> pfew
[14:59] <vila> jelmer: no
[14:59]  * jelmer files a bug
[14:59] <vila> jelmer: but looking at the traceback, it's most probably a close socket
[14:59] <vila> closed
[15:00] <mgz> new one to me.
[15:00] <vila> which is weird because I'm pretty sure bugs have been fixed so that ssl sockets behave correctly (raise EBADF) instead of AttributeError
[15:00] <jelmer> bug 902182
[15:01] <smoser> ok...
[15:02] <smoser> i can verify that bzr at 2.5.0~beta4-1ubuntu1 and bzr-builddeb at 2.7.9ubuntu1 (current precise) have this issue..
[15:02] <smoser> but if i use bzr-buildeb from the bzr branch for plugin, i do not. and it seems to read that file and respect the value both ways.
[15:02] <smoser> so basically this seems "fix-committed" to me.
[15:03] <smoser> bu if there was some test that was supposed to have caught this, it is broken.
[15:03] <smoser> as i ran this all on a fresh ec2 instance.
[15:04] <jelmer> smoser: the option was actually added after 2.7.9 and initially defaulted to True. It has since been changed to False
[15:04] <jelmer> but in 2.7.9 there is no way of turning it off - I assumed the option and the behaviour were added at the same time but they weren't - sorry for the confusion
[15:07] <jelmer> I'm going to upload 2.8.0 to sid/precise once I finish multi tarball support
[15:08] <soren> smoser: Yes. Yes, I will.
[16:26] <darthdweller_> hey all
[16:26] <jelmer> hi darthdweller_
[16:26] <darthdweller_> how do i download a specific version of a branch using bzr from launchpad
[16:26] <darthdweller_> in bzr the terminal code is this bzr branch lp:project-name
[16:27] <darthdweller_> but how do i download a specific version
[16:29] <jelmer> darthdweller_: bzr branch -r<revno> lp:project-name
[16:29] <darthdweller_> thanks
[16:29] <vila> bzr branch -r<version> lp:project-name, see 'bzr help branch' and 'bzr help revisionspec'
[17:02] <GRiD> hi jelmer, around?
[17:26] <vila> jelmer: I'm reviewing common-bzrdir-component and...
[17:26] <vila> jelmer: it's a tough one :)
[17:26] <vila> jelmer: I don't think I will be able to finish today so if you have more explanations to add that will be welcome,
[17:27] <vila> jelmer: I'm not sure I fully understand your intents here nor the fallouts... for example, are you dropping some features for formats older than metadir or things like that ?
[17:28] <vila> jelmer: seeing  def from_string(cls, format_string) implemented as <check format_string is for me> return cls()
[17:29] <vila> jelmer: makes me wonder if this whole format machinery is really worth it
[17:30] <vila> jelmer: can't we just get the same effect with probers + a simple registry ?
[17:42] <mgz> vila: new fun thing for the pilot to review
[17:42] <mgz> where 'fun' might also be read as 'scary'
[17:43] <vila> hehe, I'd better end my week before it's too late instead ;)
[17:44] <jelmer> vila: sorry, wasn't paying attention to IRC
[17:44] <jelmer> vila: No, there aren't any features that are being dropped
[17:45] <jelmer> vila: from_string() is there because feature-flags will allow more than one line in the format file
[17:45] <mgz> the @classmethod change seems good
[17:46] <mgz> the rest is a bit harder to see just from the diff, looks like in some cases there are more identical copies of methods rather than better sharing
[17:46] <mgz> GRiD: that's a yes, but missed your ping by the look of it, hence the 'just ask' suggestion with irc
[17:47] <jelmer> mgz: which methods?
[17:47] <vila> yeah, same feeling
[17:47] <vila> _find_format
[17:49] <jelmer> that's a utility function in BzrFormat, that code is used by the find_format methods in {BranchFormatMetaDir, RepositoryFormatMetaDir, WorkingTreeFormatMetadir, BzrDirFormat}
[17:50] <vila> I don't want to sound negative (especially so late), I know this code is... dense, but I have a hard time relating your cover letter with the diff
[17:50] <vila> right, but what duplication are you avoided ?
[17:50] <vila> avoiding
[17:50] <mgz> speaking of cover letters... the config changes look ace jelmer but I could do with a sketch for reviewing it
[17:50] <jelmer> vila: that logic was present in those 4 classes
[17:51] <jelmer> mgz: argh, I actually meant to cancel that, but it seems like lp-propose created an MP even though I said I didn't want it. :(
[17:51] <jelmer> vila: now find_format() is smaller and using the _find_format helper method
[17:52] <jelmer> network_name's default implementation is no longer duplicated in all four classes, just present in BzrFormat
[17:52] <vila> _find_format != find_format !
[17:52] <jelmer> vila: _find_format is a helper for find_format()
[17:52] <vila> geee, this diff *is* confusing :)
[17:54] <vila> jelmer: I think I start to understand :)
[17:54] <vila> jelmer: is it correct to say you introduced a common base class that wasn't conceivable *before* metadirs were introduced (since repository/branch/tree were three distinct hierarchies) ?
[17:55] <jelmer> vila: Yes
[17:55] <vila> bah, that's what you say in your cover :-/
[17:55] <jelmer> crap, I'm sorry - that was clear in my mind but I didn't describe it very well in the MP description
[17:57] <jelmer> vila: and the feature flags MP goes one step further and adds that class even as a base class for BzrDirFormat, and adds some more methods to it
[17:58] <vila> ha, the nightmare of splitting work across multiple MPs and trying to keep track of who understand what ;)
[18:04] <vila> jelmer: review: tweak
[18:05] <vila> jelmer: mostly, please, please, write or update some doc about this stuff, each time I have to dig into this area... I blame me for not writing some explanations about it
[18:05] <vila> and on that, have a nice week-end guys, family is hungry :)
[18:06] <jelmer> vila: fair enough
[18:06] <mgz> what are you going to cook for them?  :)
[18:06] <jelmer> vila: you too, have a good weekend :)
[18:06] <vila> mgz: I don't know yet :)
[18:07] <mgz> jelmer: I think bug 873412 needs confirming and a prio, as it's a known symptom and people seem to be able to hit it
[18:08] <fullermd> Maybe they're eating him.  That's why he has to stop typing.
[18:08] <jelmer> mgz: it's not new though :-/
[18:08] <mgz> you don't have to mark it as 'New' :)
[18:09] <jelmer> heh
[20:23] <kirkland> struggling here importing something from cvs into bzr
[20:24] <kirkland> cvs repo info at http://sourceforge.net/scm/?type=cvs&group_id=162326
[20:24] <jelmer> hi Dustin :)
[20:24] <kirkland> jelmer: howdy :-)
[20:24] <jelmer> kirkland: are you trying to import it through a Launchpad import, or some other way?
[20:24] <kirkland> jelmer: i just filed a new bug, but it looks like maybe I'm hitting https://bugs.launchpad.net/bzr-cvsps-import/+bug/788914
[20:24] <kirkland> jelmer: LP import failed, so I'm trying by hand now
[20:25] <kirkland> jelmer: I filed Bug 902315
[20:25] <kirkland> hmm, not sure why that's private
[20:26]  * kirkland undoes that
[20:26] <kirkland> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/902315
[20:26] <jelmer> that very much looks like a dupe of 788914, indeed
[20:27] <kirkland> jelmer: okay, I see "fix-committed" ... where/how do I get an update for that?
[20:27] <kirkland> jelmer: should i just branch the plugin directly?
[20:27] <kirkland> jelmer: i was running from 11.10 packages
[20:28] <jelmer> kirkland: yeah, it's fixed in lp:bzr-cvspsimport but not yet in the package
[20:28] <kirkland> jelmer: okay, so mkdir -p ~/.bazaar/plugins ?
[20:28] <kirkland> jelmer: and then bzr branch lp:bzr-cvspsimport there?
[20:28] <jelmer> kirkland: yep
[20:28] <kirkland> jelmer: k, let me try
[20:28] <kirkland> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr-cvspsimport/".
[20:29] <kirkland> missing -
[20:30] <jelmer> I'm not sure if that'll work with a local checkout though, it might need a copy of the repository
[20:32] <kirkland> jelmer: okay, so now i have a bzr directory
[20:32] <kirkland> jelmer: it appears the import succeeded
[20:32] <kirkland> jelmer: but it doesn't look like a branch of the source code yet
[20:32] <kirkland> jelmer: what does that take?
[20:33] <jelmer> kirkland: it might not create a checkout
[20:33] <jelmer> kirkland: does "bzr log" work?
[20:34] <kirkland> jelmer: nope
[20:34] <kirkland> jelmer: here's what I did ...
[20:34] <kirkland> cd $(mktemp -d)
[20:34] <kirkland> cvs -z3 -d:pserver:anonymous@talpa.cvs.sourceforge.net:/cvsroot/talpa co -P .
[20:34] <kirkland> jelmer: I think that gets me the CVSROOT
[20:35] <kirkland> jelmer: then I did a bzr cvsps-import path/to/cvs/root talpa /tmp/talpa.bzr
[20:36] <kirkland> jelmer: then I have stuff in /tmp/talpa.bzr
[20:36] <kirkland> jelmer: but it's not a bzr branch
[20:37] <jelmer> kirkland: is there anything in /tmp/talpa.bzr/.bzr ?
[20:38] <kirkland> jelmer: $ find /tmp/talpa.bzr/ -name ".bzr"
[20:38] <kirkland> /tmp/talpa.bzr/bzr/talpa/.bzr
[20:38] <jelmer> kirkland: can you try running "bzr co" in /tmp/talpa.bzr/bzr/talpa ?
[20:38] <kirkland> jelmer: kirkland@x220:/tmp/talpa.bzr/bzr/talpa$ bzr stat
[20:38] <kirkland> bzr: ERROR: No WorkingTree exists for "file:///tmp/talpa.bzr/bzr/talpa/.bzr/checkout/".
[20:39] <kirkland> jelmer: $ bzr co
[20:39] <kirkland> bzr: ERROR: Not a branch: "/tmp/talpa.bzr/bzr/talpa/.bzr/branch/": location is a repository.
[20:40] <jelmer> hmm, odd
[20:40] <jelmer> it's been a while since I've used bzr-cvsps-import, let me see if I can import it here
[20:42] <jelmer> I immediately get an error from "bzr cvsps-import"
[20:42] <jelmer> bzr: ERROR: Could not find the cvs versioned file for CVSROOT/checkoutlist. Looking for it at /tmp/tmp.2MUY7W8mmz/CVSROOT/talpa/CVSROOT/checkoutlist,v and /tmp/tmp.2MUY7W8mmz/CVSROOT/talpa/CVSROOT/Attic/checkoutlist,v.
[20:44] <kirkland> jelmer: erg
[20:44] <kirkland> jelmer: dang, this is frustrating;  okay, thanks for your help  :-/
[20:47] <jelmer> kirkland: where's the import on launchpad? I'm curious about the error
[20:47] <kirkland> jelmer: http://launchpadlibrarian.net/87103042/kirkland-ezncrypt-trunk.log
[20:48] <kirkland> jelmer: possibly the error is just waiting on accepting the ssh host key?
[20:48] <jelmer> kirkland: that seems to be lacking a :pserver: prefix
[20:48] <kirkland> jelmer: oh?  should I try re-running?
[20:49] <jelmer> kirkland: yeah, but fix the CVS root first :)
[20:49] <kirkland> jelmer: ?
[20:49] <kirkland> jelmer: this isn't my code or project
[20:49] <jelmer> kirkland: the CVS root specified in the code import I mean
[20:50]  * jelmer tries
[20:51] <kirkland> jelmer: sorry, man, this is over my head, I don't really know what I'd be putting in there
[20:52] <jelmer> kirkland: :pserver:anonymous@talpa.cvs.sourceforge.net:/cvsroot/talpa
[20:52] <jelmer> for the CVS root and talpa for the module
[20:52] <kirkland> jelmer: locally, or in LP?
[20:52] <jelmer> kirkland: in LP
[20:53] <kirkland> jelmer: ooooooh, sorry :-)
[20:53] <kirkland> jelmer: yeah, I did that
[20:58] <jelmer> kirkland: let me know if it works
[20:58] <jelmer> for some reason I can see the log file for the import but not the import itself (is it private?)
[21:03] <kirkland> jelmer: yeah, sorry, i imported it a private project
[21:04] <kirkland> jelmer: should i just register talpa as a project?
[21:13] <kirkland> jelmer: restarted the import here: https://code.launchpad.net/~kirkland/talpa/trunk
[21:17] <jelmer> kirkland: seems to've disappeared
[21:17] <kirkland> jelmer: heh, i moved it :-)  sorry
[21:17] <kirkland> jelmer: https://code.launchpad.net/~ecryptfs/talpa/ecryptfs
[21:17] <kirkland> jelmer: this is actually fixes to talpa to get it to work with ecryptfs
[21:17] <kirkland> jelmer: so i've set the owner to the ecryptfs team, project talpa, branch name ecryptfs
[21:17] <kirkland> jelmer: does that seem reasonable to you?
[21:17] <jelmer> kirkland: yep
[21:18] <kirkland> jelmer: cool, and registering the project in LP...was that the right thing to do?
[21:18] <jelmer> kirkland: yep
[21:18] <kirkland> jelmer: great, thanks for your help
[21:18] <kirkland> jelmer: i think this is working now
[21:18] <jelmer> it seems to be doing something :)
[21:18] <kirkland> jelmer: the private import seemed to have completed
[21:19] <kirkland> jelmer: it was in a review stage or something when i killed it
[23:47] <glyph> is the maintainer of the mac installer here?