=== Guest72054 is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Guest70297 === Guest70297 is now known as Ursinha-afk === Ursinha-afk is now known as Guest94180 === Guest94180 is now known as Ursinha_ === arjenAU2 is now known as arjenAU [01:19] thumper: I'm pretty sure it only ever expands lp: through the UI. The saved locs in branch.conf are pre-expanded, it won't indirect through the directory service for them. [01:19] (so if one did get in there, it wouldn't work) [01:35] fullermd: ah, ok === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === 84XAAAATU is now known as beuno === chx_sleep is now known as chx [02:33] does bzr use argparse? [02:35] no [02:35] it has its own thing that predates argparse (and uses optparse as a backend iirc) [02:36] see bzrlib.option? [02:39] hm dont know whats that [02:46] What it is is bzr's option parser. [02:49] wolter: it's a module within the bzrlib package [02:52] how the years have passed :) [02:54] six years almost, no wonder the option parse predates argparse :) [07:00] wolter, chx : And IIRC argparse is not available for python2.4 (we still maintain compatibility with it so far) right ? [07:04] wouldn't know :s [07:05] wolter: np, just saying [07:06] wolter: it would be nice to switch anyway but that can't be done *now* === mbarnett` is now known as mbarnett [09:17] bonjour vila [09:17] bialix: hey ! [09:18] :-) [09:18] to continue our last conversation [09:18] I think qbzr really needs atomicity re group of options [09:18] and group of options per se [09:19] groups [09:19] can you elaborate on that ? [09:19] why is it needed, what are the failure scenarios ? [09:19] we have several pixels options: size, is_maximized flag, sometimes even the relative sizes of widgets [09:20] the scenario is simple: for qbzr those options should be read and written as one operations [09:20] to always have consistent state [09:20] that's my idea [09:20] currently config interface is one-option-at-time oriented [09:21] although some internal options are grouped as well [09:21] say, bound_location + is_bound flag [09:21] not sure about stacked on option [09:21] yes, it's one option at a time and I'd like to change that, but when will that fail ? [09:21] I mean, with the current implementation [09:22] smart server [09:22] what will fail there ? [09:22] we're using commit_data group and older smart servers has no support for dicts in config [09:22] s/has/had/ [09:22] now spiv fixed this [09:23] that's a different problem, not related to atomicity [09:23] qbzr don't hold the lock all the time [09:23] and bzr-explorer for more broad example [09:24] bialix: we're talking past to each other, [09:24] config's API is: if you need 1 option then read a config file [09:24] if there is no atomicity, what could go wrong ? [09:24] I can't say [09:25] my point not about imaginary race condition [09:25] mine is :) [09:25] but about the situation that sometime some code works with tightly coupled group of options [09:26] if you don't encounter a race, then setting the options one by one gives the same end result [09:26] those options should be read simultaneously, and should be written simultaneously [09:26] why ? [09:26] except that you have to re-read the same config many times [09:26] let's talk again about smart server [09:26] to change 5 opyions you need 10 operations [09:27] options [09:27] yes, the concern is about performance but this can be address more easily than the race conditions [09:27] and you can also get atomicity by bencoding your set [09:28] of course bencode is user hostile, but that's another issue [09:28] bencoding the set is ad-hoc solution [09:28] I don't really like the idea of bencoding [09:28] I understand it and can use it if nothing else helps [09:28] but I'm not very keen to it [09:29] the very fact that I should bencode my group of options sounds wrong to me, and you? [09:29] sure, I'm talking about a temporary solution there and what is the best trade-off [09:30] maybe that's why we have our own wheel in the qbzr [09:30] I can't say [09:30] if/when we reach the point where a config *file* is read once and written once for a given transaction, we get the atomicity back without performance costs [09:31] vila: I'm going to implement "group" idea for qbzr's pixel settings [09:31] bialix: don't do that with subsections please, you'll make my life harder :-} [09:31] bialix: anything else is fine :D [09:31] oh no [09:31] you read my mind [09:32] where is my tin cap? [09:32] hehe, may be I'm over concerned with compatibility... [09:33] a radical way to address it will be to consider that the new features will be provided for new files only and leave the existing features for the existing files [09:33] yep [09:33] then one new feature would be to bootstrap the new file from the old one, converting on the fly [09:33] as I said yesterday I want to extract pixels options into separate zoo [09:34] but it still feels wrong to tell you:"yes, use that, I will remove it soon" [09:34] * bialix nods [09:35] bialix: climb on my rug, I will pull it from under you :D [09:36] hehe [09:38] except for the multi-line value problem, *sorting* the file on dotted names could address your finding issues... [09:39] and by the way, X resources are also specified with dotted names, so we aren't inventing anything new there [09:39] we're talking about a technic used for years [09:39] decades [09:39] centuries... [09:39] at least :D [09:39] I can't resist sorry [09:40] and 'sort -c. -k' is also a good friend to get various sort orders... [09:41] yeah, I know, may not work on windows, but still [09:42] 'bzr config' also accept regexps for NAME... we can imagine adding a sort option there and you wouldn't have to ever look at the file content [09:42] bzr config *size* [09:42] err [09:42] bzr config .*size.* ? [09:43] --scope qbzr [09:43] (NIY) [09:43] niy? [09:43] Not Implemented Yet [09:43] --scope qbzr that is [09:44] that all sound good [09:44] but I think the groups and subsections are really cool [09:44] I understand your intents [09:45] and *my* concern is that adding support for subsections will make the UI confusing [09:45] but I see how groups will simplify the things [09:45] I don't need those subsections to be editable by user [09:45] so no UI concerns here [09:46] every difference between the data stored in the config files and the way it is accessed is a source of issues [09:47] a basic line in a config file is: 'name =value' [09:47] so far it translates at the UI level by: to refer to an option I use the 'name' I see in the config file [09:48] if you add sections there, it's still valid as long as the sections are used to allow using the same name multiple times but still for the same option [09:48] the sections are then used to decide which context is appropriate (extending the idea from locations.conf where the path defines the context) [09:49] if you use subsections as part of the name, things become blurry [09:49] I want to refer to this option, so wait, what's it's name ? [09:49] s/it's/its/ [09:50] commit data is already violating this principle, hence my concerns about it [09:51] overall, I'm trying to *reduce* the number of concepts the user has to deal with, without losing features [09:52] so if dict values can be represented with a set of dotted names sharing the same prefix (the dict name), it's better than forcing the user to specify an option differently whether its value is a scalar or a dict [09:53] *and* we regain control on section names to carry another kind of information [09:53] I don't understand why commit_data violates this principe [09:53] because it uses section names to implement option names [09:53] no, it's not [09:54] so we can't use section names for other purposes [09:54] yes it is [09:54] it uses section name to get atomicity [09:54] go to beginning-of-discussion [09:54] atomicity can be achieved with other means [09:54] and the user shouldn't have to care about it [09:55] here we call that "hand-made sunset" [09:55] ok, I understand, you want commit_data to die [09:55] that's possib;e [09:57] no, I don't want it to die, I want it to be represented differently without losing any other feature [09:57] bencode everything everywhere everytime [09:58] bialix: have you read configuration.txt in lp:~bzr-core/bzr/devnotes ? [09:58] bialix: no, bencode is user hostile [09:58] bialix: using bencode loses the user-friendly property of being able to read the config files [09:58] vila: I don't use locations.conf [09:58] so I don't really care about it [09:58] honestly [09:58] bialix: that's not the point [09:59] there are too much config files [09:59] that bothers me [09:59] bialix: really ? [09:59] sometimes [10:00] bialix: then what about grouping them into the same config file then ? [10:00] maxb will complain [10:00] bialix: and use section names to decide which section apply in which case [10:00] bialix: rhaaaa, come on, maxb made it clear that he was referring to option specific to a given user on a given host [10:01] bialix: and options that nobody want to see but still want to be persistent for that matter [10:02] bialix: different type of options requires different config files, yet, the same kind of options should be in the same config file even if they are used by different parts of the code (including plugins) [10:02] bialix: the bookmarks plugin is a good example here [10:03] it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf [10:03] that's not user friendly ! [10:04] if I define mypush=lp:~vila in bazaar.conf and want to specialize it in a given branch it will be called bookmark_mypush in branch.conf but when I want to use it I must use 'mypush' ghaaa === bialix_ is now known as bialix [10:04] bialix: what was the last msg you got ? [10:05] jelmer: hi :) [10:05] vila: [12:01] bialix: and options that nobody want to see but still want to be persistent for that matter [10:06] bialix: different type of options requires different config files, yet, the same kind of options should be in the same config file even if they are used by different parts of the code (including plugins) [10:06] bialix: the bookmarks plugin is a good example here [10:06] * jelmer (~jelmer@a83-163-205-244.adsl.xs4all.nl) has joined #bzr [10:06] * jelmer has quit (Changing host) [10:06] * jelmer (~jelmer@samba/team/jelmer) has joined #bzr [10:06] it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf [10:06] that's not user friendly ! [10:06] * tchan1 (~tchan@c-69-243-144-187.hsd1.il.comcast.net) has joined #bzr [10:06] if I define mypush=lp:~vila in bazaar.conf and want to specialize it in a given branch it will be called bookmark_mypush in branch.conf but when I want to use it I must use 'mypush' ghaaa [10:08] I see [10:08] whar's the cure? [10:08] bookmarks might use sections everywhere? no wait, we going away of sections [10:09] 'morning vila, bialix [10:09] sorry, my VPS is giving me trouble this morning.. now connected directly to IRC :) [10:09] hey jelmer [10:10] bialix: the cure is to use: 'bzr.bookmarks.mypush' that you can use in every section in locations.conf, in bazaar.conf and in branch.conf [10:10] vila: I think I don't like them to be in [DEFAULT] section of bazaar.conf [10:11] another problem with dict values: say a user want to modify a single value in the dict, what would be the syntax for 'bzr config' ? [10:11] just because they're not defaults [10:11] what ? [10:11] I dunno [10:11] vila: I think I don't like'bzr.bookmarks.mypush' to be in [DEFAULT] section of bazaar.conf just because they're not defaults [10:12] I dunno re dicts [10:12] * bialix has to press enter not so many times [10:12] bialix: if they are defined in bazaar.conf *empty* section ([DEFAULT] is nothing more that an alias for an empty section in branch.conf that's why I want to get rid of it ([DEFAULT] in bazaar.conf that is)) [10:13] bialix: then they defined the default value for the bookmark if it's not defined anywhere else [10:13] so it *is* a default [10:13] if it's defined in branch.conf, it takes precedence [10:14] yes, I know this hack [10:14] I want this hack to become a generalized feature [10:15] you know, in fact I really like how git works with configs [10:15] and I want to reuse the locations.conf trick for naming sections as paths but allow it in bazaar.conf to define default values as opposed to overriding values in locations.conf [10:15] in git qbzr.foo means [qbzr] section and option foo [10:15] I dunno how it works in git, tell me [10:16] that's exactly my proposal, see configuration.txt in devnotes [10:16] that's how I understand it from their man pages [10:16] no, you say there should not be sections [10:16] no [10:16] read configuration.txt in devnotes [10:16] I want to use sections, but not for dict values [10:17] and if they are used for dict values I can't use them [10:17] vila: I'm reading now [10:17] k [10:21] it said: This means that in the most common cases, the user doesn't need to define any section. [10:22] also: A section is named by the path it should apply to (more examples below). [10:22] vila: qbzr has several options that are not very suitable for bazaar.conf [10:22] bialix: I thought we agreed yesterday that these options should stay in their own config file [10:23] Not all config files needs to define sections (in the most common cases, the user doesn't need to define any section) [10:24] I'm not aiming to collect all options in bazaar/branch/tree conf files if they don't fit, and I think the qbzr window options don't fit [10:25] the commit data fits in tree.conf, I don't yet see a case where it would need sections (but I may be wrong there and maybe the colocated branch *relative* path may be useful) [10:27] ok, enough food for the mind, it's time to get some food for the body [10:27] vila: I'm sure we can continue our mindstorm later [10:28] bialix: cool, one last thing: [10:28] I'm too qbzr-centric [10:28] vila: you want to get a broader picture [10:28] bialix: when I wrote the devnotes doc, I was only considering paths for section names (and mostly absolute paths for that matter) [10:28] maybe that's why we can't find the common way [10:29] bialix: now, I realize section names can be used for different cases, qbzr.windows.conf can use them for window names (since they are no overlap in this case), authentication.conf can use them for server urls or regexps, etc [10:30] bialix: now, I realize section names can be used for different cases, qbzr.windows.conf can use them for window names (since there is no overlap in this case), authentication.conf can use them for server urls or regexps, etc [10:30] k [10:30] bialix: but the basic idea is to not use section names if you can use the name space to achieve the same result [10:30] there is no rul for all, right? [10:31] bialix: roughly yes, as long as a defined common set of rules is respected by all :D [10:32] I need to chew your words some time [10:32] one is: option names are valid python identifiers (aka dotted names, no space, no funky stuff, may be even mo unicode if it makes things simpler) [10:32] no unicode -- that's right [10:33] but anyway, can I have groups API please? [10:34] groups? [10:34] you can build them yourself from get_option_matching('^qbzr.windows.') [10:34] what's about set? [10:35] jelmer: we're talking about groups of options [10:35] bialix: or rather, forget about atomicity by considering that we will reach a point where we read/write a conf file once by transaction [10:35] bialix: set ? You mean list values ? [10:35] no I mean about set options back [10:35] EPARSE [10:35] write [10:35] get-set [10:35] you wrote get_option_matching [10:36] can I set dict :-D [10:36] ? [10:37] if the conf file is written once, you don't care about setting each option separately, if you need helpers for that, we can think about it yes [10:38] (abort write commit group) [10:38] bialix: [conf.set_user_option('qbzr.windows.%' % k, v) for k,v in d.iteritems()] [10:39] conf.set_user_option_group(mydict-here) :-P [10:40] yes, that's the helper [10:40] but you need to give it a name too [10:41] probably set_user_option_from_dict(name, dict) [10:41] and it will bencode? [10:41] and only scalars accepted as values in the dict [10:42] nooo [10:42] I think we stuck around ConfigObj [10:42] good enough for now, no need to change IMHO [10:43] how we *use* it should be better enforced though [10:43] that's what I mean [10:43] it has many features [10:43] but some of them are not good enough or de-jure prohibited [10:43] yup [10:43] but not de-facto [10:44] but that's part of the evolutionary process, you start using/testing and change your mind along the way [10:44] ok [10:44] many plugins poke under the cover because the proposed features were too limited [10:45] I'm trying to summarize all the current needs so we can propose a better evolution [10:45] that's good [10:45] I hope shaggy qbzr needs gave you many food [10:50] Hi, is there an easy way to change the nicknames of the commits in a branch (eg because I decided to rename a branch)? [10:50] bialix: yup, very good feedback ! [10:51] alf: no, but further commits will respect the new nick [10:51] alf: revisions are immutable, if you want to change them, you need to create new ones [10:52] alf: they are immutable because it means they can be shared and everybody can refer to them by their ID and have the guarantee that they are talking about the same thing [10:52] alf: so you can't change that thing without losing this property [10:54] vila: sure, but the branch I am working on is still local/private... [10:54] vila: could the rebase plugin help here? [10:54] alf: sure, rebase will create *new* revisions [10:55] if don't know if you can change *just* the nickname from the available UI, but rebasing is the way to go for that kind of change [11:04] vila: thanks, although I cannot make rebase to work. When I try to rebase the existing revisions in a branch after having changed the nick it just says "Base branch is descendant of current branch. Pulling instead" [11:05] vila: which makes sense, of course, but doesn't fit my needs in this case [11:05] alf: right, that's... yeah, exactly [11:05] alf: file a bug [11:05] alf: out of curiosity, why does the nick matters in your case ? [11:06] vila: just being pedantic, really :) [11:06] alf: ok, np, I am pedantic myself on occasions ;) [11:08] vila: are there still plans to switch to Tarmac at some point? [11:09] jelmer: yes [11:09] jelmer: we were supposed to do that back in Dallas and then... it didn't happen ;) [11:15] vila: ah, ok [11:32] vila: whoa, 33893 unit tests... [11:32] ...and counting ;D [11:34] jelmer: http://babune.ladeuil.net:24842/job/selftest-lang-C/25/testReport/ says 125,095 tests :D [11:34] and some slaves are missing in this run ;) [11:35] ...and that's without any plugins of course [11:36] jelmer: but back to your remark, was there a recent increase because you managed to better plug the foreign tests ? [11:37] jelmer: or are they already well plugged and you just noticed the number ? [11:45] vila: yeah, this is partially because of the per_{workingtree,branch,repository} tests now running against the foreign plugins [11:46] I think that accounts for a couple of thousand tests [11:46] now to get them all passing.. [11:47] oh, and we do stuff like this: [11:47] bzrlib.plugins.upload.tests.test_upload.TestBranchUploadLocations.test_set_push_location(HgWorkingTreeFormat) [12:05] jelmer: O_O [12:05] jelmer: fun ahead :D [12:07] jelmer: if the end result is that suddenly upload works for svn, hg and it trees... that would be... an unexpected but interesting side-effect... [12:07] where did that 'g' go ? [12:07] vila: Yeah, that'd be nice.. not sure yet how shallow these test failures are [12:08] jelmer: the root cause should be quite clear in upload sources, I was aiming in the same direction as you... getting test parametrization for free from bzr [12:09] jelmer: and that's all I care about, whatever the way it's achieved [12:09] vila: yeah, this is really neat [12:10] I've already discovered some things that would be genuine bugs [12:10] bingo ! [12:13] So, anyone want to look at something weird? [12:13] There's a bzr-builddeb test that fails in the daily PPA, but not for me locally [12:14] Also, I have replaced my bzr-cvsps-import MP with two new ones that supersede it [12:15] * jelmer tries to run the bzr-builddeb tests [12:19] maxb: Runs fine here too - what's the error in the daily PPA? [12:20] TestMergeUpstream.test_smoke_renamed_file fails in a way I do not really understand [12:21] File "/build/buildd/bzr-builddeb-2.6+bzr526~natty1/merge_upstream.py", line 96, in changelog_add_new_version [12:21] OSError: [Errno 2] No such file or directory [12:45] maxb: Hmm, no idea at a first glance.. [12:46] maxb: r=me for your bzr-cvsps-import MPs [13:12] What's the conventional way to initialise plugins in a script? [13:12] Just call bzrlib.plugin.load_plugins() after the imports? [13:13] wgrant: yep [13:14] jelmer: Thanks. [13:29] wgrant: still up ??? [13:30] vila: Yes. [13:30] wgrant: oh my, I wanted to ask you to keep an eye on package imports fallouts once I deploy a new driver there, but you will never wake up tomorrow :D [13:31] wgrant: err, I mean, any potential fallouts on the lp side [13:31] vila: What are you changing? [13:31] wgrant: the mass_import.py script which should not change anything regarding launchpad, so you're not supposed to see anything unsual [13:32] wgrant: and since I didn't hear rumours about a debian release, you may in fact see nothing at all, but just in case I wanted you to be aware of the change [13:32] Haha. [13:32] Thanks. [13:37] jelmer: yes, I know, deprecating symbols is a pita [13:41] vila: hmm? [13:42] jelmer: oh, you haven't seen my last review yet :) [13:42] jelmer: and thanks for yours by the way ! [13:42] ah :) [13:49] thanks for the review(s), much appreciated :) [13:51] only one branch left before being able to move the weave formats into a plugin.. [13:52] \O/ [13:53] one last test before pulling the new driver for the package importer [13:55] niice [13:56] ok, imports failed, test succeeded :D [13:56] yes, the test was to collect the failures ;) [14:18] How do I save credentials when using bzr+https so that the next bzr up or bzr commit won't ask me again? [15:00] * jdobrien is back from kneeling in the dirt [15:00] oops [15:04] wam: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html should tell you what you need to know [15:05] ah - authentication.conf. I just read about it as a feature-request. [15:05] thanks. I'll try [15:05] or is this 2.4 only? [15:06] no, it is fairly old [15:07] nice, thanks === Ursinha is now known as Ursinha-lunch [15:16] what's the proper way to merge diffs between releases from one branch to an unrelated branch, like lp:foo to lp:ubuntu/foo for example. I keep doing something like (cd /path/to/foo; bzr diff -r1..2) | patch -p0, but that's aweful :( [15:18] maxb: yeah, works smoothly, although the scheme bzr+https is not recognized in my 2.2. But that's not requried. Any scheme will do. thanks again [15:18] wam: hmm. Does it support https: ? [15:21] maxb: positive [15:24] wam: Hmm. It's definitely supposed to support bzr+https: [15:26] i was just about to ask about bzr+https [15:26] it doesn't seem to work well [15:30] i think there's a problem with python 2.6 + pycurl + bzr+https [15:30] which seems to be killing my attempts to use it [15:36] dunno about pycurl, but it runs smoothly for me [15:37] https://bugs.launchpad.net/bzr/+bug/241698 [15:37] https://bugs.launchpad.net/bzr/+bug/365874 [15:37] that's the problem i'm having [15:37] it seems to affect only the combination of smart http + SSL + basic auth [15:38] but that's the configuration i need to use :( [15:40] catphish: have you tried uninstalling pycurl so that it uses urllib? [15:41] maxb: i'm told it can be made to work using https+urllib:// [15:41] but that doesn't seem to try to use the smart protocol [15:43] yes, it seems to work when pycurl is uninstalled [15:43] that's annoying [15:43] wam, maxb: https is the scheme to be used in authentication.conf when using either https or bzr+https [15:43] (not annoying that it works, but it would be nice if there were some other way to stop it using pycurl) === zyga is now known as zyga-afk [15:44] bug #241698, ubot, tell me more [15:44] Launchpad bug 241698 in Bazaar "POST to authenticating proxy causes "necessary data rewind wasn't possible" error (dup-of: 365874)" [Medium,Confirmed] https://launchpad.net/bugs/241698 [15:44] Launchpad bug 365874 in Bazaar "curl error: necessary data rewind wasn't possible" [Medium,Confirmed] https://launchpad.net/bugs/365874 [15:44] ubot5 is on the ball [15:44] catphish: did you read the bug reports ? [15:45] catphish: can you provide a .bzr.log while running a failing command with -Dhttp as an additional parameter ? [15:45] vila: did you check your inbox ? [15:45] what does -Dhttp do? [15:45] err, wait [15:46] catphish: it will output a transcript of the http dialog in .bzr.log [15:46] ah [15:46] catphish: for debug purposes [15:46] catphish: so you didn't read the bugs comments then ? [15:46] i read much of it [15:47] but got distracted by someone else talking about it here [15:48] * wam winks [15:49] vila: http://paste.codebasehq.com/pastes/cx5364v4fo26 [15:49] catphish: but first, what bzr version are you using ? [15:49] 2.1.1, python 2.6.5 [15:50] nginx/0.7.65 [15:50] ouch, 2.1.1.. OS ? [15:50] ubuntu 10.04 [15:51] User-Agent: bzr/2.1.1 (pycurl: libcurl/7.19.7 GnuTLS/2.8.5 zlib/1.2.3.3 libidn/1.15) [15:51] seems to be what ubuntu installs by default, and therefore annoyingly what users are likely to have [15:51] sudo add-apt-repository ppa:bzr/ppa will give you access to the latest and greatest stable versions of bzr itself and a bunch of plugins [15:52] oh damn - i always used virtualenv + easy_install ;) [15:53]