| lifeless | ronny: put it in .bzrmeta/yourapp - make that a file that records what you need for each fileid | 00:01 |
|---|---|---|
| lifeless | ronny: we don't have a scalable lookaside engine for arbitrary metadata | 00:01 |
| lifeless | ronny: or put the metadata in the files - what metadata is needed for moin ? | 00:02 |
| ronny | its arbitrary key value storage per revision of an item | 00:02 |
| ronny | a revlog based backend is on my todo, they already have a normal hg one (metadata in the file tree), a anyvc one based on that is also on my todo | 00:03 |
| lifeless | ronny: what keys and values? | 00:04 |
| ronny | keys are strings, values are strings/lists of strings | 00:04 |
| lifeless | so you could do metadata in the file tree easily with bzr too | 00:04 |
| lifeless | what query patterns are used on the metadata | 00:05 |
| ronny | moinmoin will index the metadata | 00:05 |
| ronny | lifeless: file level metadata i can keep track of would be rather nice, practically versioned xattrs | 00:06 |
| lifeless | so - a full scan - how often ? | 00:06 |
| lifeless | does it do partial scans? when? do they read the current file content at the same time? | 00:06 |
| ronny | it will keep a separate index, it doesnt have to read file data for metadata indexing | 00:07 |
| lifeless | thats a disk index ? | 00:07 |
| ronny | yes | 00:08 |
| lifeless | heh | 00:08 |
| lifeless | sounds like there is duplication there, then. | 00:08 |
| ronny | well, the cache is there to make querying fast, its discardable | 00:08 |
| ronny | so the storage doesnt have to deal with metadata indexing/querying, just storage/retrival | 00:10 |
| ronny | lifeless: so its not really duplication, its just speed-up for disk space | 00:14 |
| pickscrape | If I upgrade a shared repository from pack-0.92 to rich-root-pack, do I need to do anything with the branches in that repository? | 00:19 |
| bob2 | can you go all the way to the 2a format? | 00:19 |
| pickscrape | Not in this case | 00:19 |
| pickscrape | We are actually moving to 2a, but need to keep an older format mirror around to allow for out debian-bound sysadmins who are seemingly opposed to upgrading anything :) | 00:20 |
| pickscrape | But in order to be able to mirror from 2a, we need rich root | 00:21 |
| pickscrape | Hmm, a test conversion seems to suggest that I don't need to do anything with the branches... | 00:24 |
| pickscrape | In fact, bzr complains if I try to. Well, that makes the instructions easier. :) | 00:24 |
| sven_oostenbrink | Does bzr recognize symlinks? | 00:28 |
| sven_oostenbrink | what if I use symlinks pointing to directories inside and / or outside bzr WTs? | 00:28 |
| pickscrape | It will still version control the symlink AIUI. | 00:29 |
| sven_oostenbrink | AIUI? | 00:29 |
| pickscrape | As I Understand It | 00:29 |
| sven_oostenbrink | pickscrape: And what if I have a symlink to a directory within the WT? Will that directory be VCSed twice? | 00:30 |
| pickscrape | The symlink will be version controlled as a symlink, and nothing else. So effectively its content will be a string | 00:31 |
| sven_oostenbrink | pickscrape: that should be perfect.. thanks! | 00:31 |
| sven_oostenbrink | pickscrape: bzr st . also shows it ending with an @, so it recognizes it.. | 00:32 |
| pickscrape | sven_oostenbrink: yes, that makes it nicely clear :) | 00:32 |
| sven_oostenbrink | bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50' | 00:34 |
| sven_oostenbrink | reason: The file id was deleted but its children were not deleted. | 00:34 |
| sven_oostenbrink | Possible bzr bug? bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50' reason: The file id was deleted but its children were not deleted. | 00:34 |
| shodan45 | I'm trying to "easy_install bzr" on a centos5/rhel5 box, but get compile errors. Is this a known problem? | 00:34 |
| pickscrape | sven_oostenbrink: That doesn't look good :) | 00:34 |
| sven_oostenbrink | pickscrape: nah, found it already, my bad :) | 00:35 |
| sven_oostenbrink | fixed | 00:35 |
| pickscrape | sven_oostenbrink: was a directory replaced by a symlink under bzr's nose there? | 00:35 |
| sven_oostenbrink | pickscrape: not really... added tree, removed (with rm) a sub dir, then bzr remove --keep tree | 00:36 |
| sven_oostenbrink | pickscrape: ow, better even, the sub dir was replaced with that symlink yeah... man, Im messing up here! | 00:37 |
| neoTheCat | how can i restore an accidently deleted file if i am using the centralized repository? | 01:14 |
| neoTheCat | in svn, i was able to do an "svn update", and it would pull any missing files from the directory? | 01:15 |
| neoTheCat | thanks... | 01:15 |
| gutworth | bzr revert | 01:15 |
| bob2 | bzr revert filename | 01:15 |
| neoTheCat | thanks. | 01:24 |
| === kirkland` is now known as kirkland | ||
| mac9416 | How can I clear a branch of everything without deleting it? | 02:43 |
| gutworth | clear of changes you mean? | 02:43 |
| mac9416 | Yep. | 02:44 |
| gutworth | bzr revert | 02:44 |
| mac9416 | I'm new to bzr BTW, so don't beat me up. | 02:44 |
| mac9416 | OK, thanks. :-) | 02:44 |
| mac9416 | Hmmm, that didn't remove all the commits. | 02:44 |
| _Andrew | Hi guys, I'm checkout out a copy of our bzr repo and it's so slow. They have 400 commits and over 1.6 gig in the repo. Is there anyway to make the checkout process faster? | 02:45 |
| _Andrew | We have** | 02:45 |
| gutworth | mac9416: bzr uncommit then, but be careful | 02:46 |
| gutworth | _Andrew: what protocol? | 02:46 |
| _Andrew | from file.. it is checking out on the same machine | 02:46 |
| mac9416 | gutworth, how do I uncommit a _lot_ of revisions? | 02:47 |
| gutworth | do you have a shared repo? | 02:47 |
| gutworth | mac9416: why do you want to do that? | 02:47 |
| mac9416 | gutworth, the short story is that I pushed 88 revisions to an empty branch that I should have branched, merged the code into and pushed. | 02:48 |
| mac9416 | So now I have 88 revisions I want to get rid of so I can do it right. | 02:48 |
| mac9416 | gutworth, the project I work on has very loose bzr rules. Small development team. | 02:49 |
| gutworth | try pulling from your own branch and giving -r | 02:49 |
| mac9416 | -r? | 02:49 |
| _Andrew | shared between different users? Yes | 02:49 |
| gutworth | mac9416: specify a revision | 02:49 |
| gutworth | _Andrew: no, like bzr init-repo | 02:49 |
| mac9416 | OK, I'll try. | 02:49 |
| _Andrew | I'm not sure | 02:51 |
| gutworth | if you branch within a shared repo, revisions don't have to be copied | 02:51 |
| mwhudson | mac9416: you can do bzr pull --overwrite -r -88 . | 02:53 |
| _Andrew | I'm using the bzr checkout command ? | 02:55 |
| mac9416 | mwhudson, that got it. Thanks. | 02:57 |
| spiv | _Andrew: checkouts can use shared repositories too. | 02:57 |
| mwhudson | mac9416: np | 02:57 |
| spiv | _Andrew: although perhaps you simply want "bzr checkout --lightweight"? | 02:58 |
| _Andrew | maybe, i'm not sure on what they all mean | 02:58 |
| spiv | _Andrew: basically, if it's on the same machine, you probably don't want to actually make second copy of the 1.6 gig of history. | 02:58 |
| _Andrew | ah yes | 02:59 |
| spiv | _Andrew: a lightweight checkout will simply point to an existing branch and repository (the repo is the bit that holds all that history), rather than copy it. | 03:00 |
| _Andrew | ah... | 03:00 |
| _Andrew | So it doesn't copy the .bzr data just the files | 03:01 |
| spiv | _Andrew: the other option mentioned is to make a shared repository with "bzr init-repo"... all branches (and heavyweight checkouts) created inside that repository will use the shared repository rather than keeping a standalone copy. | 03:01 |
| spiv | _Andrew: well, there will still be a .bzr directory, just less stuff in it :) | 03:01 |
| _Andrew | I think the first option is what I need | 03:01 |
| spiv | Yeah, sounds like it, if you want to use checkouts anyway. | 03:02 |
| spiv | If you want to keep multiple branches you may want a shared repository as well at some point, but worry about that when it happens :) | 03:02 |
| _Andrew | We have multiple branches too | 03:07 |
| _Andrew | for example we have different tags etc | 03:08 |
| spiv | Well, there's the 'bzr tag' command so you don't need branches for that. | 03:08 |
| spiv | A common way to work is to have a shared repository made with "bzr init-repo --no-trees", so that the branches in it don't have working trees automatically. | 03:10 |
| spiv | So you have a directory that has all your branches, and all those branches share a single repository so disk isn't wasted and making new branches is really fast, etc. | 03:11 |
| spiv | And then you might have a single lightweight checkout somewhere else, and you use 'bzr switch' to switch it to different branches depending on which one you're working on. | 03:11 |
| * spiv -> lunch | 03:12 | |
| poolie | hello all | 03:16 |
| mac9416 | bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~keryx-admins/keryx/devel/.bzr/) | 03:16 |
| mac9416 | is not compatible with | 03:16 |
| mac9416 | CHKInventoryRepository('file:///home/mac9416/aaaaaa/.bzr/repository/') | 03:16 |
| mac9416 | different rich-root support | 03:16 |
| mac9416 | Pardon the paste. Any ideas? | 03:16 |
| gutworth | mac9416: you need to upgrade the remote repo apparently | 03:18 |
| poolie | mac9416: or, perhaps easier, rename it and push a new one | 03:18 |
| mac9416 | Hmm, how do I upgrade the remote one? | 03:19 |
| mac9416 | Because I'm kinda attached to the name. | 03:19 |
| mkanat_ | mac9416: Maybe you could just rename the existing one and then push a new one with the same name. | 03:20 |
| gutworth | bzr push --overwrite | 03:20 |
| gutworth | (I believe) | 03:20 |
| mac9416 | Overwrite didn't work. Same error. | 03:21 |
| mac9416 | mkanat_, I'm sorry, I don't quite understand... | 03:21 |
| mac9416 | Perhaps bzr upgrade <branch> ? | 03:21 |
| RAOF | bzr upgrade $BRANCH will work, yeah. | 03:25 |
| RAOF | It'll possibly take a while, though; it (still!) needs to download & re-upload everything :( | 03:25 |
| mac9416 | lol, I was about to ask you if it was normal to take a while. :-) | 03:25 |
| mac9416 | It's a fairly small branch. | 03:25 |
| poolie | jml: just what is bzr-tools-grep | 03:45 |
| mwhudson | poolie: it's an emacs thingy | 03:49 |
| mwhudson | it basically does the bzr ls | xargs grep thing into a grep-mode buffer | 03:49 |
| jml | poolie, what mwhudson said. the exact shell command it uses is in the email | 04:31 |
| poolie | mm | 04:32 |
| poolie | i thought it was a bzr alias or plugin | 04:32 |
| dOxxx | good evening | 05:10 |
| === Bambi_BOFH is now known as Kamping_Kaiser | ||
| lifeless | jml: I disagree on cleanups | 06:12 |
| lifeless | jml: I hope I've made a convincing case in mail; please let me know if otherwise. | 06:12 |
| vila | hi all | 07:17 |
| vila | lifeless: I'm not sure I understand where you stand about cleanups, in one mail you said: "we should be able to reinstate that behaviour - it was removed by oversight, not intention.", as in cleanups before tearDown and in an other you said: "If you put cleanups after teardown...I argue that this is safer" | 07:19 |
| vila | lifeless: ISTM you prefer the later but can you confirm ? | 07:20 |
| lifeless | vila: the behaviour I refer to is not running teardown if setup raises an exception | 07:25 |
| lifeless | that was an oversight | 07:25 |
| lifeless | the order of teardowns vs cleanups is deliberate | 07:25 |
| vila | ok. So in the end, that means banning tearDown for bzrlib (I think there are still a couple of classes that use it, in a safe way) | 07:27 |
| lifeless | vila: well we can make teardown always run again | 07:28 |
| lifeless | thats what I was saying | 07:28 |
| vila | ok on that (and that's important), I mixed the two. | 07:29 |
| lifeless | we could even do it in bzrlib | 07:43 |
| lifeless | addCleanup(self.maybeTearDown) | 07:43 |
| lifeless | def maybeTearDown(self): if not self._teardon_run: self.tearDown() | 07:43 |
| lifeless | def tearDown(self): | 07:43 |
| lifeless | self._teardown_run = True | 07:43 |
| lifeless | [/sketch] | 07:44 |
| bialix | hello all | 09:23 |
| jszakmeister | Hi bialix | 09:56 |
| bialix | hi jszakmeister | 10:13 |
| jszakmeister | Bummer. The shelve-editor hasn't made it into bzr.dev yet. | 10:36 |
| jszakmeister | s/shelve-editor/shelve-editor branch/ | 10:36 |
| jszakmeister | Geez... updating bzr.dev pulled involved 9.5MB of transfer. :-( | 10:39 |
| jszakmeister | I take that back... shelve-editor did make it in! | 10:42 |
| === Adys_ is now known as Adys | ||
| saedelaere | is there a changelog for the latest version of the bzr-explorer? | 11:19 |
| jszakmeister | The most up-to-date one is here: http://bazaar.launchpad.net/%7Ebzr-explorer-dev/bzr-explorer/trunk/annotate/head%3A/NEWS | 11:21 |
| jszakmeister | Or here (for 0.10.0): https://launchpad.net/bzr-explorer/trunk/0.10.0 | 11:22 |
| saedelaere | ah yes thank you very much | 11:22 |
| jszakmeister | You're welcome. | 11:23 |
| _Andrew | is there anything similar to propset in bzr so that I can insert the revision number into my files? | 11:33 |
| * saedelaere waves | 11:38 | |
| === mrevell is now known as mrevell-lunch | ||
| ahasenack | when I do a "bzr info" and get back "format: unnamed", what does it mean? | 12:52 |
| ahasenack | what format is it? | 12:52 |
| ahasenack | if I do it at the shared repository level, I get 2a | 12:52 |
| ahasenack | but if I cd into a checkout (bound branch) and repeat it, I get "unnamed" | 12:52 |
| jelmer | ahasenack: a named format is a combination of a repository format, branch format and working tree format | 12:57 |
| jelmer | in your case the branch format/repository format combination used is not available as a named "bzr init --format=" option | 12:58 |
| jelmer | ahasenack: if you run "bzr upgrade --2a" in the branch it should make a trivial change to the branch and "bzr info" should display 2a as the format name | 12:58 |
| jelmer | ahasenack: "bzr info -v" should show you the names of the branch, repository and working tree formats | 12:58 |
| ahasenack | jelmer: is it possible for the root of the shared repository to have one format and the checkouts inside it have a different one? | 12:59 |
| jelmer | this situation be introduced when you upgrade a repository but not the branches inside of it | 12:59 |
| ahasenack | it's quite possible this is what happened | 12:59 |
| ahasenack | I have no idea now what was upgraded and what wasn't | 12:59 |
| jelmer | ahasenack: I'd recommend just running "bzr upgrade" in the repository root and the branches | 13:00 |
| jelmer | that should be a no-op if the control dir is already up to date | 13:00 |
| ahasenack | bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format. | 13:00 |
| ahasenack | I guess it is | 13:00 |
| ahasenack | or at least the root of the shared repository is | 13:00 |
| ahasenack | so I can run "bzr upgrade" at the root of the shared repo | 13:01 |
| ahasenack | and I can also run it inside each repo from this shared repo? | 13:01 |
| ahasenack | it's a bit confusing | 13:01 |
| ahasenack | the shared bits can be upgraded separately from the rest? | 13:01 |
| jelmer | yes | 13:02 |
| jelmer | I agree it's a bit confusing | 13:02 |
| ahasenack | if I run the upgrade at the root level of the shared repository, I still have to run it inside each repository? | 13:03 |
| jelmer | ahasenack: inside of each branch, yes. | 13:03 |
| ahasenack | ok | 13:03 |
| ahasenack | weird: shared repository: bzr+ssh://bazaar.launchpad.net/~landscape/landscape/trunk/ | 13:11 |
| ahasenack | trunk itself is a shared repo? | 13:11 |
| ahasenack | ops, wrong channel | 13:11 |
| vila | ahasenack: a branch uses a repository, it is not a repo itself. As such, a repo can be shared between branches. Standalone branches use their own (private, not shared) repo | 13:13 |
| maxb | ahasenack: bzr info -v will tell you the repository branch and tree formats separately - handy when they rollup is 'unnamed' | 13:22 |
| ahasenack | maxb: even remotely? | 13:23 |
| maxb | You might need to prefix the URL with nosmart+ for that | 13:23 |
| ahasenack | aha, magic tricks | 13:23 |
| ahasenack | because just bzr info -v lp:~landscape/landscape/trunk doesn't tell me that | 13:23 |
| === mrevell-lunch is now known as mrevell | ||
| jam | morning all | 13:47 |
| __monty__ | Good afternoon. | 13:47 |
| * bialix waves at jam | 13:48 | |
| * vila waves | 14:15 | |
| === CardinalXiminez_ is now known as CardinalFang | ||
| vila | jam: inventory paths use /\'/ as \\ | 15:20 |
| vila | grrr | 15:20 |
| vila | jam: inventory paths use /\'/ as \\ | 15:20 |
| jam | hey vila | 15:20 |
| vila | argh | 15:20 |
| jam | waiting for one more "growl" :) | 15:21 |
| vila | jam: inventory paths use '/' as separator on *all* platforms right ? | 15:21 |
| * vila curses Apple keyboard and its \ / delete and return keys all in the same place :) | 15:21 | |
| jam | vila: id2path will always return '/' in the path | 15:23 |
| jam | we try (too) hard to make sure we always use '/' internally | 15:23 |
| jam | if you look at the os functions | 15:23 |
| jam | sorry | 15:23 |
| jam | osutils | 15:23 |
| jam | on windows, lots of them end with ".replace('\', '/')" | 15:24 |
| jam | vila: so yes, internally '/' is our path separator | 15:24 |
| vila | ok so changes_from() most likely obeys that rule | 15:24 |
| jam | I would assume so | 15:26 |
| vila | I just discovered/realize that I can't filter changes_from output with is_ignored() (in bzr-upload context) because smart_add is the only place where *parents* are pruned when they are ignored :-/ | 15:26 |
| jam | the main issue with supporting '\' in filenames, is just that right now, we do all we can to squash '\' to '/' | 15:26 |
| jam | vila: so you mean if I "ignore foo/" then "foo/bar" isn't getting added? | 15:27 |
| vila | jam: yes | 15:27 |
| jam | if I ignore "foo/" but add "foo/bar/" then "foo/bar/baz" (i believe) will show up as unknown | 15:27 |
| jam | testing | 15:27 |
| vila | 'ignore foo' is enough | 15:27 |
| jam | vila: confirmed | 15:28 |
| jam | I was using '/' to denote that they were dirs | 15:29 |
| vila | ok | 15:29 |
| jam | vila: so ignoring 'foo/' just means we won't recurse by default | 15:29 |
| jam | but if 'foo/bar' is versioned, then we will search everything underneath | 15:29 |
| vila | hmm, the context is .bzrignore-upload | 15:29 |
| jam | vila: I expected as such | 15:29 |
| jam | I just wanted to mention *why* it seems to work for add | 15:30 |
| vila | So there is no way to "force" as we do with bzr add | 15:30 |
| jam | and that is because we don't recurse into ignored dirs | 15:30 |
| vila | sure, makes sense | 15:30 |
| jam | vila: you may want "foo/**/*" | 15:30 |
| jam | which is "ignore everything under foo" | 15:30 |
| jam | note that it *doesn't* ignore foo | 15:31 |
| vila | yup, but that doesn't ignore foo itself :-/ | 15:31 |
| vila | hehe | 15:31 |
| jam | vila: so I don't know what you want to do with bzr-ignore-upload | 15:31 |
| jam | I just wanted to note that there *is* a syntax for "ignore everything under foo" | 15:31 |
| vila | don't upload items described in .bzrignore-upload | 15:32 |
| vila | the main difference is that we are talking about inventory paths here, not filesystem paths, so I have to check if a filename is ignored or any of its parents (this isn't needed in bzrlib except in smart_add) | 15:33 |
| vila | that also means I can't use osutils.dirname :-/ | 15:33 |
| jam | vila: dirname works fine | 15:34 |
| jam | as would "osutils.split" | 15:34 |
| jam | splitting doesn't involve adding a '/' | 15:34 |
| vila | err, on windows dirname() will recognize '/' ? | 15:34 |
| jam | vila: windows already recognizes '/' as a path chare | 15:34 |
| jam | char | 15:34 |
| jam | it just *also* recognizes '\' | 15:34 |
| vila | s/char/pathsep/ ? | 15:34 |
| jam | vila: well in python pathsep == : or ; | 15:35 |
| jam | directory separator | 15:35 |
| jam | Windows recognizes both '\' and '/' as directory separators | 15:35 |
| vila | grr, not pathsep, the other one :) | 15:35 |
| vila | oooh, good news | 15:35 |
| vila | Do we accept '\' in .bzrignore as meaning '/' ? | 15:36 |
| vila | Or do we just don't handle them ? | 15:37 |
| jam | vila: I think we switch them to '/', checking | 15:38 |
| vila | globbing.normalize_pattern seems to handle the formet | 15:38 |
| jam | vila: yep | 15:39 |
| vila | pfew | 15:39 |
| vila | I'm glad I asked :) | 15:39 |
| jam | _slashes = re.compile('[\\/]') | 15:39 |
| jam | so, '\/\/\/' will be treated as 1 '/' | 15:39 |
| === sdboyer_ is now known as sdboyer | ||
| === beuno is now known as beuno-lunch | ||
| vila | beuno-lunch: lunch is for... well, may be not :) .bzrignore-upload was far more complex than I thought, see the new merge proposal | 16:26 |
| barry | hi everyone. recently, i've been getting tons of 'No handlers could be found for logger "bzr"' messages for things like 'bzr push'. google seemed unhelpful. anybody know what's going on, or how to fix or debug the issue? i'm sure it's a python logging thing, but i'm not clear on how bzr sets that up. ftr: Bazaar (bzr) 2.0.3 on karmic | 16:31 |
| james_w | it's usually permissions, but I think you ruled that out? | 16:32 |
| barry | james_w: i did verify that ~/.bzr.log is owned by me | 16:34 |
| barry | james_w: as are everything in ~/.bazaar | 16:34 |
| barry | james_w: that is the one issue google spewed up for me, but i can't find anything e.g. owned by root | 16:35 |
| james_w | are the permission bits sensible on ~/.bzr.log? | 16:37 |
| barry | james_w: yep. 664 | 16:38 |
| james_w | if you strace it is it trying to open another log file? | 16:38 |
| barry | james_w: hmm, good idea. let me try | 16:38 |
| james_w | strace -e open /usr/bin/bzr info 2>&1 | grep log | 16:39 |
| james_w | and this is usual bzr operations with a plain unpatched bzr? | 16:40 |
| james_w | does it still happen with --no-plugins? | 16:40 |
| jam | barry: also, if you could do a run where you see it, and stop with ^\ to get into the debugger | 16:41 |
| james_w | c = self | 16:41 |
| james_w | while c: | 16:41 |
| jam | then we can poke around with what is going on | 16:41 |
| james_w | that's rather odd code in a method isn't it? | 16:41 |
| jam | james_w: that does look a little odd | 16:41 |
| barry | james_w: i only see it trying to open ~/.bzr.log; this is stock /usr/bin/bzr; still happens with --no-plugins | 16:41 |
| james_w | barry: and it succeeds in opening ~/.bzr.log? | 16:42 |
| barry | james_w: it does | 16:42 |
| barry | james_w: and writing to it | 16:42 |
| barry | jam: let me see if i can catch it | 16:43 |
| jam | barry: if i understand the problem correctly, it should happen any time you try to connect to an sftp location, or ssh location using paramiko | 16:43 |
| jam | barry: this is using bzr 2.0.3 ? | 16:43 |
| barry | jam it is and this is a bzr+ssh url | 16:44 |
| jam | do you have BZR_SSH set? | 16:44 |
| jam | (env var) | 16:45 |
| barry | jam: no | 16:45 |
| james_w | del bzr_logger.handlers[:] | 16:45 |
| james_w | doesn't that delete a copy of the list, and so is basically a no-op? | 16:45 |
| jam | k, well if it is 2.0.3, I'm pretty sure poolie's "stop using the logging" module isn't present | 16:45 |
| idnar | james_w: no, it empties the list | 16:45 |
| jam | james_w: no, that is python syntax for clear the list | 16:45 |
| james_w | ok | 16:45 |
| idnar | del "operates" on names, not references | 16:46 |
| jam | bad syntax IMO, but that is the syntax | 16:46 |
| idnar | there's effectively a whole bunch of special forms of del | 16:46 |
| jam | same as 'del d[key]' | 16:46 |
| barry | lists should really have a .clear() method like dicts, but that's a digression :) | 16:47 |
| idnar | "del foo" deletes a local name, "del foo.bar" invokes __delattr__, "del foo[bar]" invokes __delitem__ | 16:47 |
| jam | idnar: so is it the parser that turns it into the special construct? | 16:47 |
| barry | jam: so it sounds like this is a known issue in 2.0.3. if so, i will happily ignore it :) | 16:48 |
| jam | barry: I don't think it is | 16:48 |
| jam | It sounds like something strange happening | 16:48 |
| jam | you could also just try | 16:48 |
| jam | from bzrlib import logging | 16:48 |
| jam | sorry | 16:48 |
| barry | jam: ok! i'd file a bug, but it seems like i don't have enough information yet :/ | 16:48 |
| jam | from bzrlib import trace; trace.enable_default_logging() | 16:48 |
| idnar | jam: I'm not sure of the exact mechanics, but it ultimately compiles to different bytecode ops | 16:48 |
| jam | and see if that has a problem | 16:48 |
| jam | idnar: *glee* | 16:48 |
| jam | barry: and what were you using before you ran into this problem? 2.0.2 ? | 16:49 |
| idnar | there's DELETE_GLOBAL and DELETE_FAST for names, DELETE_SUSCR for del foo[bar], and DELETE_ATTR for del foo.bar | 16:49 |
| jam | (I'm trying to understand how it "just started" ) | 16:49 |
| barry | jam: python -c "from bzrlib import trace; trace.enable_default_logging()" produces no such message | 16:50 |
| jam | barry: Now I would expect: "from bzrlib import trace; trace.mutter('foo')" to generate that | 16:50 |
| jam | and | 16:50 |
| jam | "from bzrlib import trace; trace.enable_default_logging(); trace.mutter('bar')" not to | 16:50 |
| barry | jam: well, that's the thing, i'm not entirely sure when it started. "recently" is the best i can say. the only thing that comes to mind is that i started using etckeeper, but i would have thought --no-plugins would eliminate that (and i'm not doing pushes in /etc) | 16:51 |
| jam | sorry 'trace.note()' but I can't reproduce that here | 16:51 |
| jam | barry: and once again I'm proven wrong | 16:51 |
| jam | it takes "trace.warning" to provoke the handlers issue | 16:52 |
| barry | jam: | 16:52 |
| barry | % python -c "from bzrlib import trace; trace.enable_default_logging(); trace.warning('bar')" | 16:52 |
| barry | bar | 16:52 |
| barry | no logger warning | 16:52 |
| jam | barry: and without the "enable_default_logging" | 16:52 |
| barry | jam: bingo! | 16:53 |
| jam | barry: right | 16:53 |
| barry | warning and no "bar" | 16:53 |
| jam | so you have to try to log something that looks severe enough, but not have a handler enabled | 16:53 |
| === beuno-lunch is now known as beuno | ||
| barry | jam: why, or maybe who, is not installing the handler? | 16:53 |
| jam | barry: we install the handler as part of main, IIRC | 16:54 |
| jam | checking | 16:54 |
| james_w | the difference between note and warning is that warning will go through the added stderr handler | 16:54 |
| jam | barry: it looks like it is in the "bzr" main script | 16:54 |
| jam | before calling main | 16:54 |
| jam | barry: care to put an "import pdb; pdb.set_trace()" in 'bzr' and step through it to see when the warning hits? | 16:55 |
| GaryvdM | jszakmeister: ping | 16:55 |
| beuno | vila, ah, that's quite a change | 16:55 |
| barry | jam: yep, that does seem like the next step. | 16:55 |
| jam | barry: looking at the 'bzr' code, it looks like we would have to be emitting a warning during import | 16:55 |
| vila | beuno: yeah, not that simple :) | 16:56 |
| jam | as plugins aren't even loaded yet | 16:56 |
| jam | barry: the common case is when "enable_default_logging()" itself fails | 16:56 |
| jam | specifically: except IOError, e: | 16:56 |
| jam | warning("failed to open trace file: %s" % (e)) | 16:56 |
| jam | which because it cannot open the trace file has not yet set up logging, and ends up getting suppressed | 16:56 |
| jam | we should probably just change that to "sys.stderr.write()" | 16:57 |
| james_w | jelmer: isn't that log bug caused by ghosts? | 16:57 |
| jam | barry: however, you claimed that ~/.bzr.log isn't a problem | 16:57 |
| james_w | jelmer: oh no, ignore me, sorry | 16:57 |
| barry | jam: right. does not seem to be! | 16:57 |
| jam | barry: you know what, check ~/.bzr.log.old | 16:57 |
| jam | I wonder if your log is full, and it is failing to get rid of the old one | 16:58 |
| barry | jam: i have no ~/.bzr.log.old | 16:58 |
| jam | barry: anyway, stepping through with pdb is the best way to isolate it | 16:58 |
| jam | barry: what size is ~/.bzr.log ? | 16:58 |
| barry | jam: 782715 | 16:58 |
| jam | hmm.. we roll at 4MB, so no issue there | 16:58 |
| jam | back to pdb :) | 16:59 |
| barry | :) trying... | 16:59 |
| barry | jam: so far, i've narrowed it down to push.py:83 in bzr.dev | 17:06 |
| barry | dir_to = bzrdir.BzrDir.open_from_transport(to_transport) | 17:06 |
| jam | barry: so this seems to be happening a long time after bzrlib.trace.enable_default_logging() has been called | 17:08 |
| barry | yep | 17:08 |
| jam | barry: does that fit what you are seeing | 17:08 |
| jam | very strange | 17:08 |
| barry | remote.py:124 | 17:08 |
| jam | barry: you could try putting something into 'trace.warning' but I have the feeling something is going directly to the logging module | 17:08 |
| barry | jam: happens before we hit the first call to warning() | 17:10 |
| jam | barry: I think error would also trigger it | 17:10 |
| jam | but 'note' and 'mutter' seem to be defaulted to silence | 17:10 |
| jam | maybe there is an 'info' call? | 17:10 |
| barry | happens before the first call to error too | 17:10 |
| barry | and before the first call to info() | 17:11 |
| barry | in fact, before the first call to anything in trace.py | 17:11 |
| jam | barry: btw, does *python* guarantee that "open().name" works? | 17:11 |
| jam | I'm trying to define an api, and I want to know whether I have to pass a path as well as a file object, or if I can assume the file object has a .name attribute | 17:12 |
| barry | jam: well, the stdlib says "may not be present on all file-like objects" but i belive for actual file objects, yes it does guarantee that | 17:13 |
| jam | barry: sure, StringIO may not have it, but that doesn't have an fs path either :) | 17:14 |
| barry | right :) | 17:14 |
| barry | jam: narrowed down to client.py:87 | 17:15 |
| barry | jam: where method='BzrDir.open_2.1' | 17:16 |
| jam | barry: sure, I'm guessing that send_request is causing an actual connection to be spawned | 17:16 |
| jam | oh, and if you are sitting there | 17:17 |
| jam | we can try something else | 17:17 |
| jam | namely, check the transport | 17:17 |
| jam | and its connection | 17:17 |
| jam | and see whether it is using paramiko itself | 17:17 |
| jam | etc | 17:17 |
| barry | would that be self? | 17:17 |
| barry | or rather, i'm not sure where transport and connection are | 17:18 |
| barry | protocol.py:1303 | 17:19 |
| barry | or maybe 1302 | 17:19 |
| barry | jam: well, here's an interesting thing. in ssh.py:367 it calls subprocess.Popen() where argv[0] == 'ssh'. it is in this call that the No handlers warning gets emitted | 17:23 |
| barry | jam: is it possible this is happening on the server? | 17:23 |
| jam | barry: hmm... that at least looks like the server is generating an error | 17:23 |
| jam | barry: it is definitely possible | 17:23 |
| * barry checks the server | 17:23 | |
| jam | and the error would get propogated over ssh's stderr output | 17:23 |
| jam | without bzr doing anything | 17:23 |
| jam | so if on the *server* you have a problem with ~/.bzr.log | 17:23 |
| jam | this would be much less suprising | 17:23 |
| barry | jam: bing | 17:24 |
| barry | er, bingo :) | 17:24 |
| jam | old mac's dog? | 17:25 |
| barry | jam: :) ~/.bzr.log on the server was owned by root. fixing that made the problem go away. this explains everything, since this is a new-ish server and it explains why all the clients suddenly saw the same thing | 17:26 |
| jam | barry: of course it is unfortunate that this was so hard to diagnose | 17:26 |
| jam | #1 we need to fix _open_bzr_log | 17:26 |
| barry | jam: thanks! so problem solved, but i wonder if the debugging output couldn't have helped indicate that the message was coming from the server? | 17:26 |
| jam | to just write to stderr, since we know logging isn't set up yet | 17:26 |
| barry | jam: are there bugs here i can file or would you like the honors? :) | 17:27 |
| jam | barry: You can file a bug if you want, I was just going to fix it | 17:29 |
| jam | It *is* nice to close bugs :) | 17:29 |
| barry | jam: you kw :) | 17:29 |
| vila | kw == kilowatt ? | 17:30 |
| barry | vila: first word: karma | 17:30 |
| vila | LOL | 17:31 |
| vila | well, I think the intent here is more to *document*, karma is unfair for jam anyway :-D | 17:31 |
| barry | :) but yes +1, especially because my previous google search was unhelpful. filing bug now | 17:32 |
| jam | barry: I was thinking keyword myself :) | 17:32 |
| vila | mostly because lp doesn't take the number of clones jam is using when calculating karma :D | 17:32 |
| jam | vila: well for a long time lp didn't count code changes as karma | 17:33 |
| jam | so mine was actually quite low | 17:33 |
| jam | too many people triaging bugs | 17:33 |
| jam | so the amount I did, did not amount to much | 17:33 |
| jam | if you wanted real karma *blueprints* were where it was at | 17:33 |
| barry | jam: don't i know it! when i was doing the lp mlist stuff i blueprinted out the wazoo. lots of yummy karma | 17:34 |
| vila | which is a bit silly since we don't use blueprints :D | 17:35 |
| jam | vila: \o/ I somehow managed to have the highest karma of people I can find right now | 17:35 |
| jam | I don't know how that happened | 17:36 |
| jam | ah, lots of commits | 17:36 |
| jam | https://edge.launchpad.net/~jameinel/+karma | 17:36 |
| jam | 30k karma from "bazaar branches" | 17:36 |
| barry | jam: bug 503886 | 17:36 |
| ubottu | Launchpad bug 503886 in bzr "Server errors are hard to debug" [Undecided,New] https://launchpad.net/bugs/503886 | 17:36 |
| jam | I'm certainly a branch whore | 17:36 |
| barry | and with that, i give you my thanks and take leave for lunch! | 17:36 |
| jam | barry: eat hearty my friend | 17:37 |
| barry | :) bye all | 17:37 |
| jam | vila: it would appear that merge-proposals are the new karma hotness :) | 18:03 |
| vila | good move :) | 18:04 |
| jam | well, if you look at https://edge.launchpad.net/~jameinel/+karma, I have about 10x more karma from branches | 18:17 |
| jam | though I guess "new branch registered" also appears on the list | 18:17 |
| jam | and I don't think I'm *shabby* on the bug tracker | 18:17 |
| vila | jam: you suck at translations though... | 18:17 |
| vila | ;-P | 18:17 |
| jam | yeah | 18:17 |
| jam | which is true enough anyway :) | 18:18 |
| === deryck is now known as deryck[lunch] | ||
| EdWyse_Mobile | I have to use bzr on Fedora 6 connecting to a newer repository. The latest fc6 rpm is 0.91.1 but when I attempt to init to the server, I get "Unknown branch format...". If I try to bdist_rpm version 2.0.3 it fails because of: "bzrlib/_annotator_pyx.c:30:27: error: python-compat.h: No such file or directory". | 19:06 |
| maxb | EdWyse_Mobile: bzr 0.91.1 !? That's unspeakably ancient! | 19:06 |
| EdWyse_Mobile | Yeah, so is FC6, but I'm stuck with it on this machine. They took a feature I need out of the kernel. | 19:07 |
| maxb | I'm afraid I know nothing about bdist_rpm, so I would suggest installing bzr 2.0.3 from source to /usr/local | 19:08 |
| EdWyse_Mobile | Just to be clear, I do mean "python setup.py bdist_rpm" | 19:11 |
| ronny | EdWyse_Mobile: you lakc the python development packages | 19:12 |
| EdWyse_Mobile | Oh! That makes sense. | 19:12 |
| EdWyse_Mobile | Well, made sense but that wasn't it. | 19:14 |
| === deryck[lunch] is now known as deryck | ||
| jam | EdWyse_Mobile: where are you getting the code from? | 19:35 |
| jam | I don't see how it would have _annotator_pyx.c but not python-compat.h | 19:35 |
| jam | EdWyse_Mobile: another option would be to just run from source, which is what I do on an *FC3* machine :) | 19:36 |
| EdWyse_Mobile | That's what I'm doing for now. | 19:36 |
| lifeless | moin | 19:36 |
| jam | hi lifeless | 19:37 |
| jam | EdWyse_Mobile: looks like I get the same failure, investigating | 19:37 |
| jam | it seems that bdist_rpm is building in build/temp... but isn't including bzrlib itself | 19:38 |
| jam | so it probably thinks we should be including "bzrlib/python-compat.h" | 19:38 |
| jam | EdWyse_Mobile: hmm... bdist_rpm seems to start by hardlinking everything into a new directory | 19:40 |
| jam | but doesn't seem to include python-compat.h | 19:40 |
| EdWyse_Mobile | Hmm, sounds like a simple bug. | 19:41 |
| jam | I don't quite understand how it figures out what files to copy | 19:41 |
| lifeless | jam: check that sdist includes python-compat.h | 19:43 |
| jam | lifeless: the tarball it creates does *not* have python-compat.h, or any of the pyrex generated .c files | 19:44 |
| lifeless | I'm fiarly sure that they select in common | 19:46 |
| lifeless | excuse me, more coughing. | 19:46 |
| jam | lifeless: looks like that is true | 19:46 |
| jam | looking here for possible answers: http://www.python.org/doc/2.3.5/dist/source-dist.html | 19:48 |
| jam | It does mention: all C source files mentioned in the ext_modules or libraries options | 19:48 |
| jam | however: http://paste.ubuntu.com/352492/ doesn't seem to catch it | 19:49 |
| jam | this seems to work: http://paste.ubuntu.com/352494/ | 19:53 |
| jam | EdWyse_Mobile: ^^ | 19:53 |
| jam | That will also include the pyrex generated files in the tarball | 19:53 |
| jam | which is something we would want anyway | 19:53 |
| jam | oh, and you probably need more for stuff like bzrlib/help-topics, etc | 19:56 |
| jam | so we probably need a *.txt in there as well | 19:56 |
| jam | lifeless, jelmer: Any idea why subvertpy debs are in the bzr 2.0/2.0.3 download location? | 19:57 |
| jam | https://edge.launchpad.net/bzr/2.0/2.0.3/ | 19:57 |
| EdWyse_Mobile | cool, thanks | 19:57 |
| jam | and bzr_2.0.3-1~bazaar1~hardy_powerpc.changes seems a bit strange to have | 19:58 |
| jam | it at least looks like someone uploaded to +download instead of to a ppa | 19:58 |
| lifeless | jam: no idea | 20:01 |
| lifeless | seems odd | 20:01 |
| jam | Any way to tell who uploaded them? | 20:01 |
| lifeless | who uploaded them ? | 20:01 |
| lifeless | jinx | 20:01 |
| lifeless | thats a question for #launchpad(-dev)? I think | 20:02 |
| dutchie | is there a way to make a shelved change dump out the diff saved? | 20:32 |
| snorkelbuckle | Hi! | 20:38 |
| GaryvdM | dutchie: maybe bzr unshelve --dry-run | 20:38 |
| GaryvdM | Hi snorkelbuckle! | 20:39 |
| dutchie | it just prints out a little summary message, even with -v | 20:39 |
| snorkelbuckle | New user here, anybody here who can spend 5 minutes to help me with setting up centralized shared repos? Its installed on linux and I'm having trouble accessing via windows tortoise bazaar. | 20:39 |
| snorkelbuckle | I did the following, bzr init-repo --no-trees /bzrepos, then from tortoise did and 'Init' no trees to following bzr+ssh://hostname/bzrepos/newproj | 20:43 |
| snorkelbuckle | now if i check out newproj, I get erro Not a branch | 20:43 |
| snorkelbuckle | what am I not understanding about setting up new repos? | 20:44 |
| GaryvdM | snorkelbuckle: are you maybe a user of another vcs? | 20:45 |
| GaryvdM | snorkelbuckle: If I understand you correctly, you have a branch stored on a linux box, and you want a copy of it on your win box? | 20:46 |
| snorkelbuckle | GaryvdM: yes, I've used svn, yes I suppose a branc on linux box, but it is empty I only just initizliued it. So I assume once it is init, then I can check it out to my win box and add files to it | 20:47 |
| GaryvdM | snorkelbuckle: what url did you use? | 20:47 |
| snorkelbuckle | GaryvdM: bzr+ssh://myinternalhost.com/bzrepos/myproject | 20:48 |
| lifeless | snorkelbuckle: in one line you say bzr+ssh://hostname/bzrepos/newproj in another bzr+ssh://myinternalhost.com/bzrepos/myproject | 20:51 |
| lifeless | snorkelbuckle: the urls will need to be the same :) | 20:51 |
| snorkelbuckle | lifeless: thanks, first line was generlized, second line is accurate. :) | 20:51 |
| snorkelbuckle | okay, now I tink I understand what is wrong...but I don't understand then how I should use bazaar...I think the terminology is different from what I'm used to. | 20:52 |
| snorkelbuckle | What I did was did bzr init-repo for /repos | 20:52 |
| snorkelbuckle | and then under /repos, I did also init-repo | 20:53 |
| snorkelbuckle | for a different dir | 20:53 |
| snorkelbuckle | so then this is a sub-repos under a repos? This is allowed? Thus I don't yet have a branch which I must do with bzr 'init' as opposed to 'init-repos'? | 20:53 |
| GaryvdM | snorkelbuckle: http://doc.bazaar.canonical.com/latest/en/user-guide/core_concepts.html will help | 20:55 |
| snorkelbuckle | GaryvdM: thanks | 20:57 |
| GaryvdM | btw: I've just changed from Qwerty to dvorak so my typing is painfull slow :-( | 20:59 |
| snorkelbuckle | GaryvdM: what is the reason you changed? | 21:02 |
| GaryvdM | hopefully I will become faster in the long run :-) | 21:03 |
| snorkelbuckle | GaryvdM: thanks for your time in helping me. I must have missed those reference pages, explains a lot. I've got things working now. | 21:04 |
| GaryvdM | Good! | 21:04 |
| snorkelbuckle | GaryvdM: I guess my main problem was that I had not actually any branches to checkout from the repos, thus the error. However, I find this a minor problem with tortoise bazaar (maybe there is a way to do it), but there doesn't seem to be a way to create a branch on an empty remote repository. | 21:07 |
| lifeless | snorkelbuckle: yes repos can be nested but its not what you want | 21:15 |
| lifeless | snorkelbuckle: you want to init under the first repo | 21:15 |
| jam | GaryvdM: good luck, I've been there | 21:54 |
| jam | It took me about 1 month before I was at reasonable speed vs qwerty | 21:54 |
| jam | I'll note that I don't think I'm faster today than I was w/ qwerty | 21:54 |
| jam | though the bottleneck is not really my fingers | 21:54 |
| jam | I *do* feel that there is less motion in my fingers | 21:54 |
| jam | and I believe poolie has had good results wrt strain | 21:54 |
| GaryvdM | Hi jam | 21:54 |
| jam | GaryvdM: I'll also mention that I was decent at switching for a long time, before I started working exclusively on my laptopt | 21:55 |
| jam | now I can switch somewhat, but ViM is still a real pain in the wrong keyboard | 21:55 |
| GaryvdM | In the typing tutor, I can do 10 wpm, but when I'm much slower when I've got other things on my mind. | 21:57 |
| idnar | yeah, I observed about the same; once I was up to speed, I wasn't any faster on dvorak, but I wasn't any slower either, and the strain on my wrists was much less | 21:58 |
| GaryvdM | I find 'L' to be a bit of a strain. | 21:59 |
| marsilainen | I would seriously consider switching to dvorak if there were a decent selection of keyboards to buy.. | 22:05 |
| lifeless | marsilainen: any keyboard with homogenous keys | 22:08 |
| jam | marsilainen: well, it helps you become a better touch typist | 22:19 |
| jam | lifeless: except the F & J keys have bits on them to guide your fingers | 22:19 |
| jam | but I did rearrange a keyboard | 22:19 |
| jam | and just swapped those two keys appropriately so that I still had the dots, and just had 4 keys in the wrong place | 22:20 |
| jam | well, except for the fact that I made mistakes and never bothered to fix them (V & W, IIRC) | 22:20 |
| poolie | hello jam, gary | 22:51 |
| poolie | i never switched the keycaps | 22:51 |
| poolie | i just learned to do things from the dots on the home row | 22:52 |
| poolie | that possibly improved my results independently of switching to dvorak | 22:52 |
| poolie | iow relearning any layout this way may have helped | 22:52 |
| poolie | i'd like to do a small hack some time that measures errors (backspaces) as a feedback technique | 22:52 |
| jam | hey poolie | 22:56 |
| jam | abentley: are you around? | 22:56 |
| GaryvdM | Hi poolie | 23:03 |
| poolie | hi, happy new year | 23:03 |
| poolie | jam, if it's not too late, we could talk | 23:03 |
| poolie | otherwise i'll set an alarm for earlier tomorrow :) | 23:04 |
| jam | poolie: I'm heading out the door now | 23:05 |
| jam | I suppose you could call my cell if you wanted | 23:05 |
| poolie | nm, if i call you at 2200utc tomorrow would that work? | 23:05 |
| jam | sure | 23:05 |
| jam | I've been trying to investigate bug #494269, and our tree root handling just seems ... broken | 23:05 |
| jam | everywhere | 23:05 |
| ubottu | Launchpad bug 494269 in bzr "tree transform cannot change root id" [Medium,Confirmed] https://launchpad.net/bugs/494269 | 23:05 |
| jam | calling "wt.set_root_id(new)" | 23:06 |
| poolie | hm :/ | 23:06 |
| jam | causes "wt.id2path(new)" to fail | 23:06 |
| jam | well, wt.id2path(wt.path2id('')) breaks | 23:06 |
| poolie | with problems in dirstate, or tt,or maybe both? | 23:06 |
| jam | both | 23:06 |
| jam | wt.id2path(wt.path2id('')) is a dirstate bug | 23:06 |
| jam | 'bzr revert' fails | 23:06 |
| jam | but seems to be a TreeTransform bug | 23:06 |
| jam | etc, | 23:06 |
| jam | update/pull use different code paths to achieve 90% the same thing | 23:07 |
| jam | and update will call set_root_id() if it is None | 23:07 |
| jam | pull doesn't | 23:07 |
| jam | etc. | 23:07 |
| jam | anyway, I'm off for now | 23:07 |
| === sven_oostenbrink is now known as phoenixz | ||
| igc | morning | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!