| === 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 | ||
| fullermd | 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 |
|---|---|---|
| fullermd | (so if one did get in there, it wouldn't work) | 01:19 |
| thumper | fullermd: ah, ok | 01:35 |
| === 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 | ||
| wolter | does bzr use argparse? | 02:33 |
| mwhudson | no | 02:35 |
| mwhudson | it has its own thing that predates argparse (and uses optparse as a backend iirc) | 02:35 |
| mwhudson | see bzrlib.option? | 02:36 |
| wolter | hm dont know whats that | 02:39 |
| Peng | What it is is bzr's option parser. | 02:46 |
| mwhudson | wolter: it's a module within the bzrlib package | 02:49 |
| chx | how the years have passed :) | 02:52 |
| chx | six years almost, no wonder the option parse predates argparse :) | 02:54 |
| vila | wolter, chx : And IIRC argparse is not available for python2.4 (we still maintain compatibility with it so far) right ? | 07:00 |
| wolter | wouldn't know :s | 07:04 |
| vila | wolter: np, just saying | 07:05 |
| vila | wolter: it would be nice to switch anyway but that can't be done *now* | 07:06 |
| === mbarnett` is now known as mbarnett | ||
| bialix | bonjour vila | 09:17 |
| vila | bialix: hey ! | 09:17 |
| bialix | :-) | 09:18 |
| bialix | to continue our last conversation | 09:18 |
| bialix | I think qbzr really needs atomicity re group of options | 09:18 |
| bialix | and group of options per se | 09:18 |
| bialix | groups | 09:19 |
| vila | can you elaborate on that ? | 09:19 |
| vila | why is it needed, what are the failure scenarios ? | 09:19 |
| bialix | we have several pixels options: size, is_maximized flag, sometimes even the relative sizes of widgets | 09:19 |
| bialix | the scenario is simple: for qbzr those options should be read and written as one operations | 09:20 |
| bialix | to always have consistent state | 09:20 |
| bialix | that's my idea | 09:20 |
| bialix | currently config interface is one-option-at-time oriented | 09:20 |
| bialix | although some internal options are grouped as well | 09:21 |
| bialix | say, bound_location + is_bound flag | 09:21 |
| bialix | not sure about stacked on option | 09:21 |
| vila | yes, it's one option at a time and I'd like to change that, but when will that fail ? | 09:21 |
| vila | I mean, with the current implementation | 09:21 |
| bialix | smart server | 09:22 |
| vila | what will fail there ? | 09:22 |
| bialix | we're using commit_data group and older smart servers has no support for dicts in config | 09:22 |
| bialix | s/has/had/ | 09:22 |
| bialix | now spiv fixed this | 09:22 |
| vila | that's a different problem, not related to atomicity | 09:23 |
| bialix | qbzr don't hold the lock all the time | 09:23 |
| bialix | and bzr-explorer for more broad example | 09:23 |
| vila | bialix: we're talking past to each other, | 09:24 |
| bialix | config's API is: if you need 1 option then read a config file | 09:24 |
| vila | if there is no atomicity, what could go wrong ? | 09:24 |
| bialix | I can't say | 09:24 |
| bialix | my point not about imaginary race condition | 09:25 |
| vila | mine is :) | 09:25 |
| bialix | but about the situation that sometime some code works with tightly coupled group of options | 09:25 |
| vila | if you don't encounter a race, then setting the options one by one gives the same end result | 09:26 |
| bialix | those options should be read simultaneously, and should be written simultaneously | 09:26 |
| vila | why ? | 09:26 |
| bialix | except that you have to re-read the same config many times | 09:26 |
| bialix | let's talk again about smart server | 09:26 |
| bialix | to change 5 opyions you need 10 operations | 09:26 |
| bialix | options | 09:27 |
| vila | yes, the concern is about performance but this can be address more easily than the race conditions | 09:27 |
| vila | and you can also get atomicity by bencoding your set | 09:27 |
| vila | of course bencode is user hostile, but that's another issue | 09:28 |
| bialix | bencoding the set is ad-hoc solution | 09:28 |
| bialix | I don't really like the idea of bencoding | 09:28 |
| bialix | I understand it and can use it if nothing else helps | 09:28 |
| bialix | but I'm not very keen to it | 09:28 |
| bialix | the very fact that I should bencode my group of options sounds wrong to me, and you? | 09:29 |
| vila | sure, I'm talking about a temporary solution there and what is the best trade-off | 09:29 |
| bialix | maybe that's why we have our own wheel in the qbzr | 09:30 |
| bialix | I can't say | 09:30 |
| vila | 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:30 |
| bialix | vila: I'm going to implement "group" idea for qbzr's pixel settings | 09:31 |
| vila | bialix: don't do that with subsections please, you'll make my life harder :-} | 09:31 |
| vila | bialix: anything else is fine :D | 09:31 |
| bialix | oh no | 09:31 |
| bialix | you read my mind | 09:31 |
| bialix | where is my tin cap? | 09:32 |
| vila | hehe, may be I'm over concerned with compatibility... | 09:32 |
| vila | 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 |
| bialix | yep | 09:33 |
| vila | then one new feature would be to bootstrap the new file from the old one, converting on the fly | 09:33 |
| bialix | as I said yesterday I want to extract pixels options into separate zoo | 09:33 |
| vila | but it still feels wrong to tell you:"yes, use that, I will remove it soon" | 09:34 |
| * bialix nods | 09:34 | |
| vila | bialix: climb on my rug, I will pull it from under you :D | 09:35 |
| bialix | hehe | 09:36 |
| vila | except for the multi-line value problem, *sorting* the file on dotted names could address your finding issues... | 09:38 |
| vila | and by the way, X resources are also specified with dotted names, so we aren't inventing anything new there | 09:39 |
| vila | we're talking about a technic used for years | 09:39 |
| vila | decades | 09:39 |
| bialix | centuries... | 09:39 |
| vila | at least :D | 09:39 |
| bialix | I can't resist sorry | 09:39 |
| vila | and 'sort -c. -k<n>' is also a good friend to get various sort orders... | 09:40 |
| vila | yeah, I know, may not work on windows, but still | 09:41 |
| vila | '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 |
| vila | bzr config *size* | 09:42 |
| vila | err | 09:42 |
| vila | bzr config .*size.* ? | 09:42 |
| vila | --scope qbzr | 09:43 |
| vila | (NIY) | 09:43 |
| bialix | niy? | 09:43 |
| vila | Not Implemented Yet | 09:43 |
| vila | --scope qbzr that is | 09:43 |
| bialix | that all sound good | 09:44 |
| bialix | but I think the groups and subsections are really cool | 09:44 |
| bialix | I understand your intents | 09:44 |
| vila | and *my* concern is that adding support for subsections will make the UI confusing | 09:45 |
| bialix | but I see how groups will simplify the things | 09:45 |
| bialix | I don't need those subsections to be editable by user | 09:45 |
| bialix | so no UI concerns here | 09:45 |
| vila | every difference between the data stored in the config files and the way it is accessed is a source of issues | 09:46 |
| vila | a basic line in a config file is: 'name =value' | 09:47 |
| vila | 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:47 |
| vila | 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 |
| vila | the sections are then used to decide which context is appropriate (extending the idea from locations.conf where the path defines the context) | 09:48 |
| vila | if you use subsections as part of the name, things become blurry | 09:49 |
| vila | I want to refer to this option, so wait, what's it's name ? | 09:49 |
| vila | s/it's/its/ | 09:49 |
| vila | commit data is already violating this principle, hence my concerns about it | 09:50 |
| vila | overall, I'm trying to *reduce* the number of concepts the user has to deal with, without losing features | 09:51 |
| vila | 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:52 |
| vila | *and* we regain control on section names to carry another kind of information | 09:53 |
| bialix | I don't understand why commit_data violates this principe | 09:53 |
| vila | because it uses section names to implement option names | 09:53 |
| bialix | no, it's not | 09:53 |
| vila | so we can't use section names for other purposes | 09:54 |
| vila | yes it is | 09:54 |
| bialix | it uses section name to get atomicity | 09:54 |
| vila | go to beginning-of-discussion | 09:54 |
| vila | atomicity can be achieved with other means | 09:54 |
| vila | and the user shouldn't have to care about it | 09:54 |
| bialix | here we call that "hand-made sunset" | 09:55 |
| bialix | ok, I understand, you want commit_data to die | 09:55 |
| bialix | that's possib;e | 09:55 |
| vila | no, I don't want it to die, I want it to be represented differently without losing any other feature | 09:57 |
| bialix | bencode everything everywhere everytime | 09:57 |
| vila | bialix: have you read configuration.txt in lp:~bzr-core/bzr/devnotes ? | 09:58 |
| vila | bialix: no, bencode is user hostile | 09:58 |
| vila | bialix: using bencode loses the user-friendly property of being able to read the config files | 09:58 |
| bialix | vila: I don't use locations.conf | 09:58 |
| bialix | so I don't really care about it | 09:58 |
| bialix | honestly | 09:58 |
| vila | bialix: that's not the point | 09:58 |
| bialix | there are too much config files | 09:59 |
| bialix | that bothers me | 09:59 |
| vila | bialix: really ? | 09:59 |
| bialix | sometimes | 09:59 |
| vila | bialix: then what about grouping them into the same config file then ? | 10:00 |
| bialix | maxb will complain | 10:00 |
| vila | bialix: and use section names to decide which section apply in which case | 10:00 |
| vila | bialix: rhaaaa, come on, maxb made it clear that he was referring to option specific to a given user on a given host | 10:00 |
| vila | bialix: and options that nobody want to see but still want to be persistent for that matter | 10:01 |
| vila | 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 |
| vila | bialix: the bookmarks plugin is a good example here | 10:02 |
| vila | it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf | 10:03 |
| vila | that's not user friendly ! | 10:03 |
| vila | 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:04 |
| === bialix_ is now known as bialix | ||
| vila | bialix: what was the last msg you got ? | 10:04 |
| vila | jelmer: hi :) | 10:05 |
| bialix | vila: [12:01]<vila>bialix: and options that nobody want to see but still want to be persistent for that matter | 10:05 |
| vila | <vila> 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 |
| vila | <vila> bialix: the bookmarks plugin is a good example here | 10:06 |
| vila | * jelmer (~jelmer@a83-163-205-244.adsl.xs4all.nl) has joined #bzr | 10:06 |
| vila | * jelmer has quit (Changing host) | 10:06 |
| vila | * jelmer (~jelmer@samba/team/jelmer) has joined #bzr | 10:06 |
| vila | <vila> it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf | 10:06 |
| vila | <vila> that's not user friendly ! | 10:06 |
| vila | * tchan1 (~tchan@c-69-243-144-187.hsd1.il.comcast.net) has joined #bzr | 10:06 |
| vila | <vila> 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:06 |
| bialix | I see | 10:08 |
| bialix | whar's the cure? | 10:08 |
| bialix | bookmarks might use sections everywhere? no wait, we going away of sections | 10:08 |
| jelmer | 'morning vila, bialix | 10:09 |
| jelmer | sorry, my VPS is giving me trouble this morning.. now connected directly to IRC :) | 10:09 |
| bialix | hey jelmer | 10:09 |
| vila | 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 |
| bialix | vila: I think I don't like them to be in [DEFAULT] section of bazaar.conf | 10:10 |
| vila | 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 |
| bialix | just because they're not defaults | 10:11 |
| vila | what ? | 10:11 |
| bialix | I dunno | 10:11 |
| bialix | 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:11 |
| bialix | I dunno re dicts | 10:12 |
| * bialix has to press enter not so many times | 10:12 | |
| vila | 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:12 |
| vila | bialix: then they defined the default value for the bookmark if it's not defined anywhere else | 10:13 |
| vila | so it *is* a default | 10:13 |
| vila | if it's defined in branch.conf, it takes precedence | 10:13 |
| bialix | yes, I know this hack | 10:14 |
| vila | I want this hack to become a generalized feature | 10:14 |
| bialix | you know, in fact I really like how git works with configs | 10:15 |
| vila | 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 |
| bialix | in git qbzr.foo means [qbzr] section and option foo | 10:15 |
| vila | I dunno how it works in git, tell me | 10:15 |
| vila | that's exactly my proposal, see configuration.txt in devnotes | 10:16 |
| bialix | that's how I understand it from their man pages | 10:16 |
| bialix | no, you say there should not be sections | 10:16 |
| vila | no | 10:16 |
| vila | read configuration.txt in devnotes | 10:16 |
| vila | I want to use sections, but not for dict values | 10:16 |
| vila | and if they are used for dict values I can't use them | 10:17 |
| bialix | vila: I'm reading now | 10:17 |
| vila | k | 10:17 |
| bialix | it said: This means that in the most common cases, the user doesn't need to define any section. | 10:21 |
| bialix | also: A section is named by the path it should apply to (more examples below). | 10:22 |
| bialix | vila: qbzr has several options that are not very suitable for bazaar.conf | 10:22 |
| vila | bialix: I thought we agreed yesterday that these options should stay in their own config file | 10:22 |
| vila | Not all config files needs to define sections (in the most common cases, the user doesn't need to define any section) | 10:23 |
| vila | 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:24 |
| vila | 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:25 |
| bialix | ok, enough food for the mind, it's time to get some food for the body | 10:27 |
| bialix | vila: I'm sure we can continue our mindstorm later | 10:27 |
| vila | bialix: cool, one last thing: | 10:28 |
| bialix | I'm too qbzr-centric | 10:28 |
| bialix | vila: you want to get a broader picture | 10:28 |
| vila | bialix: when I wrote the devnotes doc, I was only considering paths for section names (and mostly absolute paths for that matter) | 10:28 |
| bialix | maybe that's why we can't find the common way | 10:28 |
| vila | 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:29 |
| vila | 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 |
| bialix | k | 10:30 |
| vila | 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 |
| bialix | there is no rul for all, right? | 10:30 |
| vila | bialix: roughly yes, as long as a defined common set of rules is respected by all :D | 10:31 |
| bialix | I need to chew your words some time | 10:32 |
| vila | 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 |
| bialix | no unicode -- that's right | 10:32 |
| bialix | but anyway, can I have groups API please? | 10:33 |
| jelmer | groups? | 10:34 |
| vila | you can build them yourself from get_option_matching('^qbzr.windows.') | 10:34 |
| bialix | what's about set? | 10:34 |
| bialix | jelmer: we're talking about groups of options | 10:35 |
| vila | 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 |
| vila | bialix: set ? You mean list values ? | 10:35 |
| bialix | no I mean about set options back | 10:35 |
| vila | EPARSE | 10:35 |
| bialix | write | 10:35 |
| bialix | get-set | 10:35 |
| bialix | you wrote get_option_matching | 10:35 |
| bialix | can I set dict :-D | 10:36 |
| bialix | ? | 10:36 |
| vila | 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:37 |
| bialix | (abort write commit group) | 10:38 |
| vila | bialix: [conf.set_user_option('qbzr.windows.%' % k, v) for k,v in d.iteritems()] | 10:38 |
| bialix | conf.set_user_option_group(mydict-here) :-P | 10:39 |
| vila | yes, that's the helper | 10:40 |
| vila | but you need to give it a name too | 10:40 |
| vila | probably set_user_option_from_dict(name, dict) | 10:41 |
| bialix | and it will bencode? | 10:41 |
| vila | and only scalars accepted as values in the dict | 10:41 |
| vila | nooo | 10:42 |
| bialix | I think we stuck around ConfigObj | 10:42 |
| vila | good enough for now, no need to change IMHO | 10:42 |
| vila | how we *use* it should be better enforced though | 10:43 |
| bialix | that's what I mean | 10:43 |
| bialix | it has many features | 10:43 |
| bialix | but some of them are not good enough or de-jure prohibited | 10:43 |
| vila | yup | 10:43 |
| bialix | but not de-facto | 10:43 |
| vila | but that's part of the evolutionary process, you start using/testing and change your mind along the way | 10:44 |
| bialix | ok | 10:44 |
| vila | many plugins poke under the cover because the proposed features were too limited | 10:44 |
| vila | I'm trying to summarize all the current needs so we can propose a better evolution | 10:45 |
| bialix | that's good | 10:45 |
| bialix | I hope shaggy qbzr needs gave you many food | 10:45 |
| alf | 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 |
| vila | bialix: yup, very good feedback ! | 10:50 |
| vila | alf: no, but further commits will respect the new nick | 10:51 |
| vila | alf: revisions are immutable, if you want to change them, you need to create new ones | 10:51 |
| vila | 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 |
| vila | alf: so you can't change that thing without losing this property | 10:52 |
| alf | vila: sure, but the branch I am working on is still local/private... | 10:54 |
| alf | vila: could the rebase plugin help here? | 10:54 |
| vila | alf: sure, rebase will create *new* revisions | 10:54 |
| vila | 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 | 10:55 |
| alf | 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:04 |
| alf | vila: which makes sense, of course, but doesn't fit my needs in this case | 11:05 |
| vila | alf: right, that's... yeah, exactly | 11:05 |
| vila | alf: file a bug | 11:05 |
| vila | alf: out of curiosity, why does the nick matters in your case ? | 11:05 |
| alf | vila: just being pedantic, really :) | 11:06 |
| vila | alf: ok, np, I am pedantic myself on occasions ;) | 11:06 |
| jelmer | vila: are there still plans to switch to Tarmac at some point? | 11:08 |
| vila | jelmer: yes | 11:09 |
| vila | jelmer: we were supposed to do that back in Dallas and then... it didn't happen ;) | 11:09 |
| jelmer | vila: ah, ok | 11:15 |
| jelmer | vila: whoa, 33893 unit tests... | 11:32 |
| vila | ...and counting ;D | 11:32 |
| vila | jelmer: http://babune.ladeuil.net:24842/job/selftest-lang-C/25/testReport/ says 125,095 tests :D | 11:34 |
| vila | and some slaves are missing in this run ;) | 11:34 |
| vila | ...and that's without any plugins of course | 11:35 |
| vila | jelmer: but back to your remark, was there a recent increase because you managed to better plug the foreign tests ? | 11:36 |
| vila | jelmer: or are they already well plugged and you just noticed the number ? | 11:37 |
| jelmer | vila: yeah, this is partially because of the per_{workingtree,branch,repository} tests now running against the foreign plugins | 11:45 |
| jelmer | I think that accounts for a couple of thousand tests | 11:46 |
| jelmer | now to get them all passing.. | 11:46 |
| jelmer | oh, and we do stuff like this: | 11:47 |
| jelmer | bzrlib.plugins.upload.tests.test_upload.TestBranchUploadLocations.test_set_push_location(HgWorkingTreeFormat) | 11:47 |
| vila | jelmer: O_O | 12:05 |
| vila | jelmer: fun ahead :D | 12:05 |
| vila | 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 |
| vila | where did that 'g' go ? | 12:07 |
| jelmer | vila: Yeah, that'd be nice.. not sure yet how shallow these test failures are | 12:07 |
| vila | 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:08 |
| vila | jelmer: and that's all I care about, whatever the way it's achieved | 12:09 |
| jelmer | vila: yeah, this is really neat | 12:09 |
| jelmer | I've already discovered some things that would be genuine bugs | 12:10 |
| vila | bingo ! | 12:10 |
| maxb | So, anyone want to look at something weird? | 12:13 |
| maxb | There's a bzr-builddeb test that fails in the daily PPA, but not for me locally | 12:13 |
| maxb | Also, I have replaced my bzr-cvsps-import MP with two new ones that supersede it | 12:14 |
| * jelmer tries to run the bzr-builddeb tests | 12:15 | |
| jelmer | maxb: Runs fine here too - what's the error in the daily PPA? | 12:19 |
| maxb | TestMergeUpstream.test_smoke_renamed_file fails in a way I do not really understand | 12:20 |
| maxb | File "/build/buildd/bzr-builddeb-2.6+bzr526~natty1/merge_upstream.py", line 96, in changelog_add_new_version | 12:21 |
| maxb | OSError: [Errno 2] No such file or directory | 12:21 |
| jelmer | maxb: Hmm, no idea at a first glance.. | 12:45 |
| jelmer | maxb: r=me for your bzr-cvsps-import MPs | 12:46 |
| wgrant | What's the conventional way to initialise plugins in a script? | 13:12 |
| wgrant | Just call bzrlib.plugin.load_plugins() after the imports? | 13:12 |
| jelmer | wgrant: yep | 13:13 |
| wgrant | jelmer: Thanks. | 13:14 |
| vila | wgrant: still up ??? | 13:29 |
| wgrant | vila: Yes. | 13:30 |
| vila | 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:30 |
| vila | wgrant: err, I mean, any potential fallouts on the lp side | 13:31 |
| wgrant | vila: What are you changing? | 13:31 |
| vila | wgrant: the mass_import.py script which should not change anything regarding launchpad, so you're not supposed to see anything unsual | 13:31 |
| vila | 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 |
| wgrant | Haha. | 13:32 |
| wgrant | Thanks. | 13:32 |
| vila | jelmer: yes, I know, deprecating symbols is a pita | 13:37 |
| jelmer | vila: hmm? | 13:41 |
| vila | jelmer: oh, you haven't seen my last review yet :) | 13:42 |
| vila | jelmer: and thanks for yours by the way ! | 13:42 |
| jelmer | ah :) | 13:42 |
| jelmer | thanks for the review(s), much appreciated :) | 13:49 |
| jelmer | only one branch left before being able to move the weave formats into a plugin.. | 13:51 |
| vila | \O/ | 13:52 |
| vila | one last test before pulling the new driver for the package importer | 13:53 |
| jelmer | niice | 13:55 |
| vila | ok, imports failed, test succeeded :D | 13:56 |
| vila | yes, the test was to collect the failures ;) | 13:56 |
| wam | How do I save credentials when using bzr+https so that the next bzr up or bzr commit won't ask me again? | 14:18 |
| * jdobrien is back from kneeling in the dirt | 15:00 | |
| jdobrien | oops | 15:00 |
| maxb | wam: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html should tell you what you need to know | 15:04 |
| wam | ah - authentication.conf. I just read about it as a feature-request. | 15:05 |
| wam | thanks. I'll try | 15:05 |
| wam | or is this 2.4 only? | 15:05 |
| maxb | no, it is fairly old | 15:06 |
| wam | nice, thanks | 15:07 |
| === Ursinha is now known as Ursinha-lunch | ||
| cr3 | 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:16 |
| wam | 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 |
| maxb | wam: hmm. Does it support https: ? | 15:18 |
| wam | maxb: positive | 15:21 |
| maxb | wam: Hmm. It's definitely supposed to support bzr+https: | 15:24 |
| catphish | i was just about to ask about bzr+https | 15:26 |
| catphish | it doesn't seem to work well | 15:26 |
| catphish | i think there's a problem with python 2.6 + pycurl + bzr+https | 15:30 |
| catphish | which seems to be killing my attempts to use it | 15:30 |
| wam | dunno about pycurl, but it runs smoothly for me | 15:36 |
| catphish | https://bugs.launchpad.net/bzr/+bug/241698 | 15:37 |
| catphish | https://bugs.launchpad.net/bzr/+bug/365874 | 15:37 |
| catphish | that's the problem i'm having | 15:37 |
| catphish | it seems to affect only the combination of smart http + SSL + basic auth | 15:37 |
| catphish | but that's the configuration i need to use :( | 15:38 |
| maxb | catphish: have you tried uninstalling pycurl so that it uses urllib? | 15:40 |
| catphish | maxb: i'm told it can be made to work using https+urllib:// | 15:41 |
| catphish | but that doesn't seem to try to use the smart protocol | 15:41 |
| catphish | yes, it seems to work when pycurl is uninstalled | 15:43 |
| catphish | that's annoying | 15:43 |
| vila | wam, maxb: https is the scheme to be used in authentication.conf when using either https or bzr+https | 15:43 |
| catphish | (not annoying that it works, but it would be nice if there were some other way to stop it using pycurl) | 15:43 |
| === zyga is now known as zyga-afk | ||
| vila | bug #241698, ubot, tell me more | 15:44 |
| ubot5 | 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 |
| ubot5 | Launchpad bug 365874 in Bazaar "curl error: necessary data rewind wasn't possible" [Medium,Confirmed] https://launchpad.net/bugs/365874 | 15:44 |
| catphish | ubot5 is on the ball | 15:44 |
| vila | catphish: did you read the bug reports ? | 15:44 |
| vila | catphish: can you provide a .bzr.log while running a failing command with -Dhttp as an additional parameter ? | 15:45 |
| vila | vila: did you check your inbox ? | 15:45 |
| catphish | what does -Dhttp do? | 15:45 |
| vila | err, wait | 15:45 |
| vila | catphish: it will output a transcript of the http dialog in .bzr.log | 15:46 |
| catphish | ah | 15:46 |
| vila | catphish: for debug purposes | 15:46 |
| vila | catphish: so you didn't read the bugs comments then ? | 15:46 |
| catphish | i read much of it | 15:46 |
| catphish | but got distracted by someone else talking about it here | 15:47 |
| * wam winks | 15:48 | |
| catphish | vila: http://paste.codebasehq.com/pastes/cx5364v4fo26 | 15:49 |
| vila | catphish: but first, what bzr version are you using ? | 15:49 |
| catphish | 2.1.1, python 2.6.5 | 15:49 |
| vila | nginx/0.7.65 | 15:50 |
| vila | ouch, 2.1.1.. OS ? | 15:50 |
| catphish | ubuntu 10.04 | 15:50 |
| catphish | 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 |
| catphish | seems to be what ubuntu installs by default, and therefore annoyingly what users are likely to have | 15:51 |
| vila | 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:51 |
| wam | oh damn - i always used virtualenv + easy_install ;) | 15:52 |
| vila | why, do simple things when you can do complicated ones instead ;-D | 15:53 |
| === joey-tosh is now known as joey | ||
| vila | wam, catphish: But my suspicion will be against nginx | 15:54 |
| vila | wait, you're in touch with the admins there right ? | 15:55 |
| catphish | i am the admin there, thats why i'm trying to make this work :) | 15:55 |
| vila | cool, one less hop in the loop | 15:55 |
| catphish | and ideally trying to make it work against the old version of bzr that ships with ubuntu | 15:55 |
| wam | catphish: i just did setup this: http://thomaslow.com/2011/01/24/configure-redmine-advanced-bazaar-integration/ | 15:56 |
| wam | catphish: works perfectly, but you need 2.2 | 15:56 |
| wam | or you'll get a error that bzr can't understand what 401 means. | 15:56 |
| catphish | yeah, though you can work around that by specitying the username in the url | 15:56 |
| wam | ah | 15:56 |
| catphish | bzr+http://username@server | 15:56 |
| wam | interesting | 15:56 |
| catphish | it prompts you for the password before making the first request | 15:57 |
| catphish | so no 401 | 15:57 |
| wam | catphish: are you going with redmine or is that just so that bzr+http works? | 15:57 |
| catphish | redmine sounds like a competitor | 15:58 |
| catphish | :) | 15:58 |
| wam | i see | 15:58 |
| vila | catphish: first things first: bzr+ssh is not an option ? Easier to setup (well, for some values of easier), guaranteed to work | 15:58 |
| catphish | bzr+ssh will work | 15:58 |
| catphish | i just want http(s) to work too | 15:58 |
| vila | k | 15:58 |
| catphish | and http works fine | 15:58 |
| vila | ook | 15:58 |
| catphish | it's just when ssl is enabled it throws this odd error | 15:58 |
| catphish | and only when pycurl is installed | 15:59 |
| catphish | but annoyingly that seems to be how ubuntu is set up | 15:59 |
| catphish | so id like to be able to work around it | 15:59 |
| catphish | either with a different URL or by adding headers at the server sidew | 15:59 |
| catphish | *side | 15:59 |
| vila | catphish: so, from my dusted memory, the issue was that somewhere in the stack (curl or ssl) someone was trying to seek the a file handle backwards which broke upper levels | 16:01 |
| catphish | ah | 16:01 |
| catphish | is there a way simply to disable pycurl? | 16:02 |
| vila | catphish: the immediate workaround would be bzr+https+urllib:// but this would mean that the certificate is not checked anymore | 16:02 |
| catphish | i tried that first, but it doesn't seem to recognise the protocol name | 16:02 |
| catphish | bzr: ERROR: Unsupported protocol for url "bzr+https+urllib://charlie@test.codebase4.com/test-repositories/bzr1.bzr" | 16:02 |
| vila | shudder | 16:03 |
| wam | right, i get that rewind bug too with ubuntu's 2.1 | 16:04 |
| vila | wam: so you confirm it's fixed in 2.2 then ? | 16:04 |
| catphish | i realise its my own fault for using 2.1 | 16:04 |
| catphish | but lots of my customers will :( | 16:04 |
| wam | at least it's fixed with my easy_installed 2.2 | 16:04 |
| vila | catphish: sure, not your fault | 16:04 |
| wam | ah no | 16:04 |
| wam | 2.3 | 16:04 |
| wam | is what i have now | 16:04 |
| wam | it's definitively fixed with 2.3 | 16:05 |
| vila | catphish: but it's hard to fix bugs in old releases *and* get them deployed | 16:05 |
| wam | AND it works with Bazaar (bzr) 2.2b2 - which comes from ubuntu maverick | 16:05 |
| vila | catphish: we're working on it though, there is a SRU in the pipes for 2.2, once we get that done... we *may* try one for 2.1 | 16:05 |
| wam | maybe you can backport this package from 10.10 | 16:06 |
| vila | that's what the ppa offers | 16:06 |
| catphish | any idea if i can do anything server side here? | 16:06 |
| catphish | or in the url | 16:06 |
| vila | catphish: stop using authentication may address the problem but I doubt you'll like that ;) | 16:07 |
| wam | catphish: are all clients yours and are they all ubuntu? | 16:07 |
| vila | catphish: seriously, it's a client-side issue | 16:07 |
| catphish | the clients are not under my control, they could be running anything | 16:07 |
| wam | k | 16:07 |
| catphish | i'm just trying to maximize compatibility | 16:07 |
| vila | catphish: will they *require* certificate validation ? | 16:07 |
| catphish | vila: no | 16:07 |
| vila | then urllib should work around the issue, | 16:08 |
| catphish | they just feel better if it says https | 16:08 |
| vila | shudder | 16:08 |
| catphish | indeed | 16:08 |
| catphish | is there a pay to persuade it to use bzr+https+urllib? | 16:09 |
| vila | damn, where did my defaultToUrllib plugin go ? | 16:09 |
| catphish | failing that i will have to tell people to upgrade and/or remove pycurl | 16:10 |
| catphish | and/or drop SSL support for a few months | 16:10 |
| === deryck is now known as deryck[lunch] | ||
| maxb | It would be nice if we had a more structured approach to the url scheme decorators, such that arbitrary combinations were valid | 16:12 |
| catphish | is it just a hardcoded list at the moment? | 16:12 |
| vila | catphish: http://paste.ubuntu.com/571783/ | 16:13 |
| vila | put that in ~/.bazaar/plugins/defaultToUrllib.py | 16:13 |
| vila | maxb: sure, with automatic tests :) | 16:14 |
| vila | maxb: unfortunately it's a bit more complex than it appears :-/ | 16:14 |
| vila | maxb: but I agree it would be nice | 16:14 |
| catphish | vila: that works like magic :) | 16:15 |
| vila | cool | 16:16 |
| catphish | i can probably distribute that | 16:16 |
| vila | catphish: but keep in mind that it won't verify certificates | 16:16 |
| catphish | that's annoying but IMO less so than telling people they can't use SSL | 16:17 |
| vila | catphish: it's GPLed | 16:17 |
| catphish | i saw | 16:17 |
| catphish | i'll distribute it independently anyway | 16:18 |
| vila | I never bothered to publish it (and I don't use it anymor eeither 8-) | 16:18 |
| vila | wam:, ha he's gone :-/ | 16:18 |
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| vila | jelmer: what's up with get_module() ? It can returns a *name* or a *module* ? Sounds confusing from the diff, should I review in context or can you answer ? | 16:55 |
| jelmer | vila: it returns the name of the module | 16:55 |
| jelmer | vila: Though I can understand how that's a bit vague in the current docstring | 16:56 |
| vila | Haaaa, always the name, ok | 16:56 |
| vila | I don't use __module__ every day :) | 16:56 |
| vila | oooh, I'm not even sure I *knew* about module... how cute... | 16:57 |
| vila | errr, how come I'm reviewing a mp already marked as superseded >-/ | 17:02 |
| jelmer | https://code.launchpad.net/~jelmer/bzr/per-interrepo-extra/+merge/51166 is the active one | 17:03 |
| vila | yup, figured that now ;) | 17:03 |
| vila | I should have think about instead of blaming the 4th dimension... | 17:03 |
| fullermd | Lousy 4th dimension. Somehow I never have time to give it the whippin' it deserves. | 17:06 |
| vila | fullermd: ha ! here you are ! Hello :) | 17:08 |
| fullermd | I am! Oh! There I are. | 17:09 |
| epoxy | hello. if I 'bzr add' in a directory. then I remove the files with 'rm' (not bzr rm).. when I commit, will the files I 'rm' still be commited or will I get any errors? | 17:09 |
| epoxy | ah I think bzr status and diff answer that. | 17:12 |
| === deryck[lunch] is now known as deryck | ||
| danielsh | I init'd a tree yesterday. I'd like to rewrite history such that the root of the tree is now a subdir (eg, /README now becomes foo/README, with 'foo' a child of the tree root.) | 17:19 |
| danielsh | currently it seems to me that fast-export is the way to go, | 17:19 |
| danielsh | are there other/better options? | 17:19 |
| === beuno-lunch is now known as beuno | ||
| * danielsh (FTR, fast-export did it with some manual massaging of the stream.) | 17:49 | |
| * danielsh afk | 17:49 | |
| * danielsh (back later) | 17:49 | |
| maxb | danielsh: Hi. Wouldn't it have been simpler to just move all the content into a subdir? | 18:08 |
| fullermd | Well you really need a pivot_root command. | 18:10 |
| vila | jelmer: do you have the bzr kanban URL handy ? The ones in my history seem to be 404'ing O_0 | 18:47 |
| maxb | vila: This one? http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html | 18:51 |
| vila | maxb: Indeed ! Thanks ! I was totally on the bad track (devpad...) | 18:52 |
| wolter | is there documentation on the bzrlib.option module? I cound't find any yesterday | 19:16 |
| vila | wolter: pydoc bzlib.option | 19:49 |
| vila | ... again.... why don't I just use completion as ping-check... | 19:50 |
| vila | and mgz did that just to point out the flow in my logic... I'm sure ! | 19:51 |
| fullermd | At least he didn't point out the flaw in your logic :p | 19:53 |
| vila | fullermd: that's the most devastating thing you could have said at this precise moment :-( | 19:55 |
| * vila kicks off Marvin: "Don't ever touch this keyboard again !" | 19:58 | |
| vila | :D | 19:58 |
| vila | still 4444 imports to go at http://package-import.ubuntu.com/status/ | 19:58 |
| vila | now that's a number | 19:58 |
| vila | composed with the most delicates power of 2 represent as often as itself | 19:58 |
| vila | ted, represented | 19:58 |
| fullermd | Not only that, but the sum of them is a power of 2 too. And it's the power of 2 represented by the digits themselves. | 19:58 |
| * vila sudo importer kill -9 | 19:59 | |
| vila | an oasis of beauty in an ocean of bits | 20:00 |
| fullermd | Their product maxes out a byte, too. Which would be the bits numbered by the sum of the number of digits and the digit itself. | 20:00 |
| fullermd | And if you round off its square root, you get a quad-repeat of digits too; 66.66. | 20:01 |
| vila | OMG, the hidden perfection ! Nobody knew it and it just appeared from the middle of nowhere 8-) | 20:01 |
| vila | and now it's gone... impermanence.. | 20:02 |
| fullermd | Halfway between the two would obviously be 555.5. If we take that as a product and a subtraction, we get 5*5*5-5 = 120. | 20:03 |
| vila | only to be replaced by 4411 hehe | 20:03 |
| fullermd | Dividing that by the 66.66, we get another nice repeating series: 1.800180018001800... | 20:03 |
| fullermd | Take that 1800 away from our original 4444, and we get 2644; back with the 4's, and this time they're the average of the preceeding digits. | 20:03 |
| vila | hey, you seem to ob your way for the infamous five 5 games: with the usual operators and using the five 5, find all the integers starting from 0 and going as far as you can :) | 20:04 |
| vila | s/ob/on/ | 20:04 |
| vila | s/ob/be on/ tyops while re-reading, the next level | 20:06 |
| === Leonidas_ is now known as Leonidas | ||
| vila | something weird is going on... with the net | 20:37 |
| fullermd | Probably needs to be rebooted. | 20:37 |
| vila | or shutdown to stay on the safe side | 20:37 |
| vila | I still suspect Morris to plan a come-back one of these days... | 20:38 |
| lamalex | Hi, I got a merge conflict and was wondering if there was anyway way to tell bzr to just throw out the incoming changes and use the in tree version whole hog | 21:09 |
| james_w` | lamalex, "bzr revert file" | 21:10 |
| lifeless | 'bzr revert .' | 21:10 |
| james_w` | lamalex, "bzr revert ." for all files | 21:10 |
| * lifeless hi fives james_w` | 21:10 | |
| danielsh | maxb: morning. it would have worked, but I wanted to rewrite the 5 revisions' worth of history, too. | 21:10 |
| lamalex | thanks james_w` | 21:10 |
| lifeless | james_w`: also, your ` is showing. | 21:10 |
| james_w` | ooo-err missus | 21:11 |
| caravel | hi everybody | 22:07 |
| caravel | PREAMBLE I'm not trying to troll, okay ? I need to underand a few things :) | 22:08 |
| spiv | Hi caravel | 22:09 |
| fullermd | Well, that takes all the fun out of it... | 22:09 |
| caravel | it's about a web site for a self-employed food company. It was mounted by a friend who has very good marketing and web-art skills, but not that techy | 22:10 |
| caravel | (food retail) so he chose Magento then Joomla, tried to glue it all together as he could | 22:11 |
| caravel | today we end up with a MASSIVE amount of files, and to be honest, some kind of a mess | 22:11 |
| caravel | we're getting close to th0s channel topic, please be patient :) | 22:11 |
| caravel | So... 29,000 files on the hosting, including lots of stuff that should be removed. I'm family related to the retail shop, and try to enforce a few things, such as ... a VCS of course. So far, he's been hacking the hosted prod server directly ! Just learned this, he had "let us understand" that he was using sme dev copy on his laptop. Well, this was not the case | 22:13 |
| === tchan1 is now known as tchan | ||
| caravel | Anyway. More than 1 year ago, I had suggedted he'd look at bzr | 22:14 |
| caravel | he just did and said he had some head aches during HOURS, that bzr doesn't take so many files (apparently, he tried to feed the entire site in bzr !?!) | 22:14 |
| caravel | And in the same email, announced that he had setup hg. Well, I was a Ubuntu user for long, now I'm on Fedora KDE by choice, but I'm still scared of hg | 22:15 |
| caravel | https://developer.mozilla.org/en/Mercurial_basics | 22:16 |
| caravel | So I tried to explain that. He agrees to let me try, my turn. I'm a rather very strange programmer (niche market for 15 years, xml stuff), don't have web-dev experience | 22:17 |
| caravel | So I have a few questions. Thanks for having read so far, I'll start now :) </PREAMBLE> | 22:18 |
| lifeless | bzr should hangle 29K files | 22:18 |
| lifeless | we've testing up to 100K if I remember correctly | 22:18 |
| caravel | lifeless: I suppose so, and even many more | 22:18 |
| caravel | right | 22:18 |
| caravel | he didn't even tried the command line !!! he wrote something like "it just closed with no message", so he was using the GUI | 22:18 |
| caravel | but I'm glad to get some confrmation already, found it so strange | 22:19 |
| caravel | next... anyone here is using bzr for such a webapps repo ? | 22:19 |
| lifeless | We do the development for the launchpad.net website using bzr | 22:20 |
| lifeless | 8K files | 22:20 |
| caravel | does it make ANY sense at all, to store 29,000 files from Mage, Joomla, whatever plugins such as JFusion, FlexiContents, PhocaGallery and so on, in a VCS ? | 22:20 |
| * caravel assumes it does NOT | 22:21 | |
| caravel | I've worked a lot as a tech lead with CVS and SVN, and I sometimes HAD to include a few libs "external to the project" in my own tree, but that was exceptional and due to specific integration processes | 22:22 |
| lifeless | so, you can do it | 22:23 |
| lifeless | but a little more structure would probably be better | 22:23 |
| lifeless | one project per thing - mage, joomla, etc | 22:23 |
| caravel | lifeless: yes, sure -- there are "source ours" in each app, so of course we need that | 22:24 |
| caravel | I just can't pronounce myself globally since I never used a VCS in such context | 22:25 |
| caravel | can you tell me how you do this briefly ? is there any useful tip that will permit to "bzr update" and push only specific files, even being able to push directly the changes eg. to the prod server... but avoiding "manual installation steps" hence working with bzr of our real, respective (local) LAMP stacks on a day to day basis ? | 22:28 |
| caravel | I can only assume that's why he tried it this way (and I know already I'm the one who will have to identify each default/custom resource, since it's obvious he doesn't know precisely. That explains it all, and oh well, that's okay. ^^ ) | 22:30 |
| spiv | bzr is fine with that many files, but it can consume a lot of memory if you have individual large files. | 22:36 |
| caravel | spiv: yes, I'm guessing it had issues on the image tree -- by luck, vids are externalized ;-) | 22:36 |
| spiv | If you want to push only specific files, I'd try what lifeless says: break it down into multiple branches, one per project or whatever the natural boundary is for you. | 22:37 |
| caravel | my question is : is this practicle to set the repo at the LAMP root, add use it to manage only "our" custom files across the tree ? (never done this in my VCS projects, always "whole" tree, never had to ask me that question) | 22:38 |
| caravel | *add -> and | 22:38 |
| caravel | so we could gently tag, update/branch and push our files only, just like a "mask" on the whole thing ? | 22:40 |
| lifeless | caravel: certainly. you can use 'bzr ignore' to ignore files you got from elsewhere. | 22:40 |
| lifeless | or 'bzr ignore \*' to ignore everything, and then 'bzr add' specific things. | 22:40 |
| caravel | lifeless: thanks. so we can even recursively add stuff while ignoring other. Sounds as simple as expected. I'll take it from there. Thanks a LOT for your time, people. | 22:41 |
| * caravel 's thankful to spiv and lifeless (everyone deserves having his/her life back). Did fullermd have some fun anyway ? ;-) | 22:44 | |
| BlazingSun | hi, anyone there familiar with bzr+ssh and working with multiple users? | 22:48 |
| BlazingSun | on the same branch | 22:48 |
| caravel | BlazingSun: tested this last year, seemed to work great, but I had to simulate all users so my tests were rather rudimentary and not so simultaneous | 22:49 |
| BlazingSun | i am trying for a few hours now, but setting the sticky-bit doesnt seem to affect newly created branches | 22:49 |
| BlazingSun | so only the "branch-owner" has write acess, all others only get read-access | 22:50 |
| * caravel should better leave before harming anyone with wrong answers | 22:50 | |
| BlazingSun | ah i am using debian6 btw | 22:50 |
| caravel | BlazingSun: oh | 22:50 |
| caravel | BlazingSun: that should NOT be related to bzr, right ? | 22:51 |
| caravel | BlazingSun: but to ssh users and permissions | 22:51 |
| BlazingSun | caravel: i am not sure, could be | 22:52 |
| * caravel uses Debian also, but Lenny only (=stable, 5) | 22:52 | |
| caravel | BlazingSun: you are using distinct logins for each user, right ? | 22:53 |
| BlazingSun | sure | 22:53 |
| BlazingSun | but they share the same group, called bazaar | 22:53 |
| BlazingSun | permissions are drwxrws--- | 22:53 |
| caravel | rwx--- at the end, you mean ? ^^ | 22:54 |
| BlazingSun | nha rws, so newly created branches still have the same group | 22:54 |
| BlazingSun | when i set permissions manually everything works right | 22:55 |
| BlazingSun | but i need the possibilty that everyone can create new branches and everyone can access them | 22:55 |
| BlazingSun | without me setting the permissions everytime | 22:58 |
| BlazingSun | hmm i think its the global umask, so nothing bzr related | 23:01 |
| BlazingSun | debian has 0022 as the default but most distros use 0002, so i found my error :) | 23:02 |
| caravel | BlazingSun: just read again man:chmod, thanks :) | 23:03 |
| caravel | BlazingSun: if you use +s, you give the the id of your "bazaar" group, right ? | 23:04 |
| BlazingSun | caravel: sure, thats what i was using, but debians umask is 022 not 002 as i ecpected | 23:06 |
| caravel | ok, I got it | 23:07 |
| BlazingSun | thx anyway for the help | 23:07 |
| caravel | BlazingSun: I don't quite get the point of using s over x (and making the tree belong to the bazaar group) ? More than interested in this anwer, our bzr will be shared over SSH/SFTP (on Lenny) | 23:07 |
| BlazingSun | caravel: if someone creates a new branch on the server he will be the owner of the branch, but i need the group to have still permission | 23:08 |
| BlazingSun | with the stickybit the group will stay the same | 23:09 |
| caravel | BlazingSun: all clear, thanks for your answer ;-) | 23:26 |
| * caravel better go and stop take the space for so little | 23:27 | |
| caravel | night all | 23:27 |
| BlazingSun | caravel: cant fight where i can set the global umask thou ^^^n8 then | 23:29 |
| caravel | BlazingSun: sorry, was on something else | 23:50 |
| caravel | BlazingSun: in your sshd_config ? | 23:51 |
| caravel | BlazingSun: man sshd_config doesn't help much, right | 23:51 |
| caravel | BlazingSun: Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server' ? | 23:52 |
| BlazingSun | caravel: im using ssh not sftp | 23:52 |
| caravel | BlazingSun: isn't sftp implicitely used ? | 23:57 |
| caravel | this could help you I guess http://serverfault.com/questions/231717/how-to-get-full-control-of-umask-pam-permissions | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!