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