Noldorin | jelmer, just saw your fix committed for an old bug of mine : | 01:34 |
---|---|---|
Noldorin | :-) | 01:34 |
=== lifeless_ is now known as lifeless | ||
=== Guest46496 is now known as jrgiffor1 | ||
vila | hi all ! | 07:36 |
jelmer | hi vila | 08:19 |
vila | jelmer: hey ! | 08:19 |
jelmer | hi spiv | 09:07 |
mgz | monring all | 09:07 |
vila | mgz: hey ! | 09:07 |
mgz | hey vila | 09:10 |
jelmer | hi mgz | 09:11 |
mgz | jelmer: did you see poolie's channel invite? | 09:17 |
=== zyga is now known as zyga-afk | ||
jelmer | vila: is there anything left that's blocking us from porting more option users over to the new config system? | 10:39 |
mgz | that would be good to do, in a big bang | 10:40 |
mgz | most plugins have a trunk-tracking release | 10:40 |
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:41 |
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:42 |
jelmer | we're already using the config system for some of our options though, right? | 10:45 |
mgz | I'm not comletely clear where the line is. | 10:50 |
vila | jelmer, mgz: so, there are two bugs on the plate: bug #832042 and bug #832046 | 11:07 |
ubot5 | Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042 | 11:07 |
ubot5 | Launchpad bug 832046 in Bazaar "needs a way to specify default values for config options by path" [High,Confirmed] https://launchpad.net/bugs/832046 | 11:07 |
vila | the later is blocking the system-wide config file stuff imho | 11:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
vila | probably garbage in the patch file that defeat parsing, can you paste it ? | 11:13 |
vila | pastebin | 11:13 |
vila | !pastebin | 11:13 |
ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 11:13 |
Merwin | http://friendpaste.com/299Lm5ens57L60noBAjrpG | 11:14 |
Merwin | it looks like a valid patch to me -_- | 11:14 |
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:17 |
mgz | eg. `patch -p0 < OpenAssur_TM_V2.patch` | 11:18 |
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:19 |
mgz | yup. | 11:20 |
vila | Merwin: or even better: publishing a branch | 11:27 |
Merwin | Yep in this case we can't :-( | 11:27 |
mgz | you can probably manually edit the patch to make it work | 11:29 |
mgz | if you add after the === lines '+++ openerp/tools/convert.py' and '--- openerp/tools/convert.py' and the same for the other file -p0 should work | 11:30 |
jelmer | vila: I'm going to have a look at migrating the gpg options | 11:33 |
vila | jelmer: cool, don't hesitate to ping me if you encounter any issue or misunderstanding | 11:34 |
vila | jelmer: on the other hand, I don't want to divert you from other important bits ;) | 11:35 |
jelmer | vila: moving commit builder over to config stack saves 9 HPSS calls :) | 12:20 |
* vila profits :) | 12:20 | |
vila | jelmer: yeah ! | 12:20 |
vila | jelmer: because it avoids a call to ensure_real or because it uses a cached config ? | 12:21 |
vila | or both :) | 12:21 |
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:22 |
vila | testing list_package in udd queries launchpad, | 12:23 |
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:24 |
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:25 |
vila | just one more example that test after is bad ;) | 12:26 |
jelmer | vila: hmm, the from_unicode function isn't actually called with unicode strings? | 13:10 |
vila | wow, that is unexpected | 13:10 |
vila | grr 'Alarm clock' | 13:11 |
vila | selftest.timeout = 60000 \o/ | 13:13 |
=== zyga-afk is now known as zyga | ||
jelmer | vila: nevermind, was my own option | 13:29 |
vila | jelmer: where was it coming from ? | 13:29 |
vila | default value ? | 13:30 |
jelmer | vila: yep | 13:31 |
jelmer | vila: default_email() | 13:31 |
vila | jelmer: something worth fixing or ? | 13:37 |
vila | .. or was the error clear enough to debug ? | 13:37 |
jelmer | vila: it was an issue I introduced | 13:49 |
jelmer | vila: found it | 13:54 |
jelmer | vila: environment variables aren't converted to unicode | 13:54 |
vila | jelmer: rings a bell ;) | 13:54 |
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:56 |
mgz | it's in my current bunch though, so will propose sometime | 13:57 |
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:58 |
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 | 13:59 |
mgz | hm. email should really be ascii, but I guess auto %-escaping would be okay? | 14:00 |
mgz | ...I think this even assembles into a one-liner | 14:01 |
jelmer | mgz: it also contains the users realname | 14:01 |
jelmer | mgz: also, the logic in config assumes that there are no differences in encoding for environment variables | 14:02 |
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:03 |
mgz | because automated things that don't set a proper locale shouldn't then be supplying bogus values and expecting stuff to work | 14:04 |
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:05 |
mgz | hm, wait, still wrong. | 14:06 |
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:07 |
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:20 |
smoser | commit-message-from-changelog = False | 14:21 |
smoser | bzr commit still wants to just use the changelog entry | 14:21 |
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:26 |
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:27 |
smoser | jelmer, hm.. | 14:29 |
smoser | http://paste.ubuntu.com/764943/ | 14:29 |
smoser | seems to not work | 14:29 |
smoser | yeah, strace shows its not even reading that file. | 14:30 |
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:31 |
smoser | yeah... i can't seem to change that behavior any way. not even in the local repository .bzr-builddeb/default.conf | 14:35 |
jelmer | smoser: is your .bzr-builddeb/default.conf versioned? | 14:36 |
jelmer | (it will only be read if versioned) | 14:37 |
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:39 |
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:40 |
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 | bzr2.5.0~beta3-2ubuntu1 | 14:41 |
smoser | bzr-builddeb2.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:41 |
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:42 |
soren | Sorry, 2.7.9 was 620. | 14:43 |
soren | But still < 625. | 14:43 |
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:44 |
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:45 |
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:46 |
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:47 |
soren | smoser: Grab a fresh checkout, and you're good. bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb | 14:48 |
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:52 |
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:55 |
vila | pfew | 14:58 |
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 | 14:59 |
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:00 |
ubot5 | Launchpad bug 902182 in bzr (Ubuntu) "spurious failure of test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) on armhf" [High,Triaged] https://launchpad.net/bugs/902182 | 15:00 |
smoser | ok... | 15:01 |
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:02 |
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:03 |
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:04 |
jelmer | I'm going to upload 2.8.0 to sid/precise once I finish multi tarball support | 15:07 |
soren | smoser: Yes. Yes, I will. | 15:08 |
=== zyga is now known as zyga-afk | ||
=== yofel_ is now known as yofel | ||
=== zyga-afk is now known as zygaq | ||
=== zygaq is now known as zyga | ||
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:26 |
darthdweller_ | but how do i download a specific version | 16:27 |
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' | 16:29 |
GRiD | hi jelmer, around? | 17:02 |
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:26 |
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:27 |
vila | jelmer: seeing def from_string(cls, format_string) implemented as <check format_string is for me> return cls() | 17:28 |
vila | jelmer: makes me wonder if this whole format machinery is really worth it | 17:29 |
vila | jelmer: can't we just get the same effect with probers + a simple registry ? | 17:30 |
mgz | vila: new fun thing for the pilot to review | 17:42 |
mgz | where 'fun' might also be read as 'scary' | 17:42 |
vila | hehe, I'd better end my week before it's too late instead ;) | 17:43 |
jelmer | vila: sorry, wasn't paying attention to IRC | 17:44 |
jelmer | vila: No, there aren't any features that are being dropped | 17:44 |
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:45 |
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:46 |
jelmer | mgz: which methods? | 17:47 |
vila | yeah, same feeling | 17:47 |
vila | _find_format | 17:47 |
jelmer | that's a utility function in BzrFormat, that code is used by the find_format methods in {BranchFormatMetaDir, RepositoryFormatMetaDir, WorkingTreeFormatMetadir, BzrDirFormat} | 17:49 |
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:50 |
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:51 |
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:52 |
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:54 |
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:55 |
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:57 |
vila | ha, the nightmare of splitting work across multiple MPs and trying to keep track of who understand what ;) | 17:58 |
vila | jelmer: review: tweak | 18:04 |
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:05 |
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:06 |
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:07 |
ubot5 | Launchpad bug 873412 in Bazaar Subversion Plugin "sqlite3.OperationalError: unable to open database file" [Undecided,Incomplete] https://launchpad.net/bugs/873412 | 18:07 |
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:08 |
jelmer | heh | 18:09 |
kirkland | struggling here importing something from cvs into bzr | 20:23 |
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 |
ubot5 | Ubuntu bug 788914 in CVS to Bazaar importer "unexpected keyword argument 'pb'" [Critical,Fix committed] | 20:24 |
kirkland | jelmer: LP import failed, so I'm trying by hand now | 20:24 |
kirkland | jelmer: I filed Bug 902315 | 20:25 |
ubot5 | Error: Launchpad bug 902315 could not be found | 20:25 |
kirkland | hmm, not sure why that's private | 20:25 |
* 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:26 |
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:27 |
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:28 |
kirkland | missing - | 20:29 |
jelmer | I'm not sure if that'll work with a local checkout though, it might need a copy of the repository | 20:30 |
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:32 |
jelmer | kirkland: it might not create a checkout | 20:33 |
jelmer | kirkland: does "bzr log" work? | 20:33 |
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:34 |
kirkland | jelmer: then I did a bzr cvsps-import path/to/cvs/root talpa /tmp/talpa.bzr | 20:35 |
kirkland | jelmer: then I have stuff in /tmp/talpa.bzr | 20:36 |
kirkland | jelmer: but it's not a bzr branch | 20:36 |
jelmer | kirkland: is there anything in /tmp/talpa.bzr/.bzr ? | 20:37 |
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:38 |
kirkland | jelmer: $ bzr co | 20:39 |
kirkland | bzr: ERROR: Not a branch: "/tmp/talpa.bzr/bzr/talpa/.bzr/branch/": location is a repository. | 20:39 |
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:40 |
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:42 |
kirkland | jelmer: erg | 20:44 |
kirkland | jelmer: dang, this is frustrating; okay, thanks for your help :-/ | 20:44 |
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:47 |
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:48 |
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:49 |
* jelmer tries | 20:50 | |
kirkland | jelmer: sorry, man, this is over my head, I don't really know what I'd be putting in there | 20:51 |
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:52 |
kirkland | jelmer: ooooooh, sorry :-) | 20:53 |
kirkland | jelmer: yeah, I did that | 20:53 |
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?) | 20:58 |
kirkland | jelmer: yeah, sorry, i imported it a private project | 21:03 |
kirkland | jelmer: should i just register talpa as a project? | 21:04 |
kirkland | jelmer: restarted the import here: https://code.launchpad.net/~kirkland/talpa/trunk | 21:13 |
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:17 |
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:18 |
kirkland | jelmer: it was in a review stage or something when i killed it | 21:19 |
=== nyuszika7h is now known as nyan-cat | ||
=== nyan-cat is now known as nyuszika7h | ||
glyph | is the maintainer of the mac installer here? | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!