| poolie | i wonder why 717345 isn't showing up on john's kanban? | 00:05 |
|---|---|---|
| bignose | I'm trying to configure ‘bzr builddeb’. | 00:30 |
| maxb | go on... | 00:30 |
| bignose | it has an ‘--orig-dir’ option; what change can I make to a config file to set that option? | 00:31 |
| bignose | I've tried making a ‘[builddeb]’ section in ‘~/.bazaar/bazaar.conf’ with ‘orig_dir = foo’ | 00:31 |
| bignose | but the program ignores it | 00:31 |
| maxb | http://jameswestby.net/bzr/builddeb/user_manual/configuration.html | 00:33 |
| bignose | thanks. | 00:34 |
| bignose | why all-caps for the section name? | 00:34 |
| bignose | that doesn't match most other INI file styles. | 00:34 |
| bignose | (the ‘[DEFAULT]’ is an intentional exception so it stands out) | 00:35 |
| maxb | Someone thought it was a good idea at the time? | 00:35 |
| bignose | if Launchpad would accept my OpenID then I would submit a bug report about that. | 00:36 |
| bignose | but it doesn't, so I'll just fume quietly. | 00:36 |
| maxb | I'm not sure a quirky naming choice constitutes a bug | 00:36 |
| poolie | :) hello bignose | 00:37 |
| bignose | poolie: heh, I wondered whose attention that would get. hi! | 00:38 |
| bignose | maxb: low severity, but it still violates a convention. | 00:38 |
| poolie | istr there is a convention of '[DEFAULT] in configobject, but i may be wrong | 00:39 |
| bignose | poolie: I think so, yes | 00:39 |
| bignose | but the other sections shouldn't be all-caps | 00:40 |
| bignose | in the case of Bazaar, I would expect they'd simply be named after the module or command, with no changes to capitalisation | 00:40 |
| marvin2 | Hi, what's the correct way to change the default parent branch of a branch? | 02:02 |
| Peng | bzr pull --remember? | 02:03 |
| marvin2 | Peng: I just cloned a branch from machine A (to machine B). Now I want the branch in machine B to use machine-A's parent as its default parent (it currently refers to machine-A as its parent) | 02:04 |
| marvin2 | Peng: So I retrieve the parent of machine-A and do a bzr pull --remember <machine-A's-parent>? | 02:04 |
| Peng | Wait I have no idea what we're talking about. | 02:05 |
| Peng | If you want to change the "parent branch" listed by e.g. "bzr info", use "bzr pull --remember some-other-branch" | 02:05 |
| marvin2 | OK | 02:05 |
| marvin2 | Peng: OK, thanks. | 02:06 |
| bignose | I don't think ‘bzr pull’ is right | 02:20 |
| bignose | if it's not already a mirror ‘pull’ will make it a mirror. that's probably not what marvin2 wants. | 02:21 |
| bignose | marvin2: I would do it by editing ‘.bzr/branch/branch.conf’ but there may be a command to do it | 02:24 |
| spiv | You can also do "bzr config --scope=branch parent_location=URL" in bzr 2.3 | 02:24 |
| bignose | marvin2: ‘bzr pull’ is not what you want in this case | 02:24 |
| spiv | (Maybe you can omit the --scope? Doesn't hurt to be explicit) | 02:25 |
| marvin2 | bignose: Cool, will give that a try - bzr pull --remember did work, but I don't want to pull from the original location just to set the default parent. | 02:51 |
| bignose | marvin2: yes, ‘bzr pull --remember’ will “work”, if by “work” you mean what ‘bzr pull’ does :-) | 05:58 |
| bignose | if you didn't intend to change the view of the branch history, then it's unlikely to have done what you want. | 05:58 |
| spiv | pull won't necessarily change the branch history at all, e.g. if the branches have diverged. | 06:02 |
| spiv | (But would still update the parent_location with --remember I think) | 06:02 |
| spiv | Probably you could use ‘bzr merge --remember URL; bzr revert’ instead, although in this case you'd lose any local working tree changes you hadn't committed. | 06:03 |
| spiv | Anyway, 2.3 has a UI for setting config variables. | 06:04 |
| cjohnston | Question.. If I have a branch, merged in some code from a merge proposal, and now want to back out that code from the merge proposal, what the best way to do that? bzr revert, bzr remove-branch, ...? I have not committed the code that I merged in | 07:21 |
| poolie | then revert | 07:21 |
| cjohnston | so bzr revert <file-name> is the correct syntax poolie ? | 07:22 |
| poolie | yes | 07:26 |
| poolie | or plain 'revert' to revert the whole tree | 07:26 |
| cjohnston | thank you very much poolie | 07:29 |
| poolie | you're welcome; have a good night | 07:29 |
| cjohnston | thanks.. you too | 07:30 |
| vila | hi all ! | 07:46 |
| === ubot5` is now known as ubot5 | ||
| maxb | james_w: Thanks for the bzr-builddeb MP approvals - just wanted to note that I can't land them myself, so please let me know whether I should wait, poke someone on IRC, or request the team membership to do so | 09:48 |
| quotemstr | Why is bzr complaining about Transport operation not possible: http does not support mkdir() | 12:05 |
| quotemstr | ? | 12:05 |
| quotemstr | Ah. FAQ. | 12:05 |
| james_w | maxb, yeah, sorry for not mentioning it, I'll get to it | 13:30 |
| maxb | np, just wanted to be clear what the next step was | 13:31 |
| speakman | with bzr annotate I can see which one's responible for a certain line of code | 14:23 |
| speakman | but in my case, the last edit of the line was just an uncommenting | 14:23 |
| speakman | how can I trace when it was put there in the first place? | 14:24 |
| rubbs | speakman: this may not be the easist solution, but you can run bzr log filename to see what revisions it was changed on, then use the revision spec on the annotate to see who did it | 14:35 |
| rubbs | not sure if you can see all of the history of jsut one line easily though | 14:35 |
| jelmer | speakman: qannotate and gannotate can help you skip to older revisions more easily | 14:36 |
| speakman | jelmer: thanks | 14:52 |
| bigjools | jelmer: around? | 15:03 |
| jelmer | bigjools: hi! | 15:38 |
| bigjools | jelmer: hey! can you do me a favour and take a quick look at this, there's a failing git import and it's kinda old and embarrassing that nobody chased it up: https://answers.edge.launchpad.net/launchpad/+question/122971 | 15:39 |
| === deryck is now known as deryck[lunch] | ||
| sobersabre | hi | 15:50 |
| sobersabre | I have downloaded email hook. and it worked, i.e. sent an email. | 15:50 |
| sobersabre | I added configuration to ~/.bazaar/bazaar.conf in [DEFAULT] section | 15:50 |
| sobersabre | What is the syntax for addint the rules per branch. is it possible ? | 15:51 |
| sobersabre | hm... I think I've found this. | 15:52 |
| bigjools | jelmer: did I scare you? :) | 15:56 |
| === beuno is now known as beuno-lunch | ||
| vila | bialix, GaryVDM: Ping | 16:13 |
| vila | jelmer: ping, have you ever used dicts as values in config files (don't even try if you haven't please :) ? | 16:18 |
| bigjools | jelmer, jelmer_: did you get my reply? | 16:18 |
| jelmer_ | bigjools: Sorry, my VPS seems to be under a lot of load for some reason | 16:18 |
| vila | OMG, we've lost our pilot ! | 16:18 |
| vila | :) | 16:18 |
| jelmer_ | bigjools: I did get your reply, I'm digging into the error | 16:18 |
| bigjools | jelmer_: great, thanks for looking. | 16:19 |
| jelmer_ | vila: hi! | 16:19 |
| jelmer_ | vila: I haven't, I wouldn't have thought that worked... | 16:19 |
| vila | jelmer: good, forget about it, I never mentioned it :) | 16:20 |
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| lifeless | jam: around ? | 18:13 |
| lifeless | jam: rousskov here is one of the key contributors to squid and is using lp to host his feasture branches; he is getting a 'lock held' message when running 'bzr update' locally - but there is no stale lock on lp or locally - http://bazaar.launchpad.net/~rousskov/squid/3p1-rock/.bzr/ | 18:17 |
| lifeless | jelmer_: or perhaps you are around ? | 18:18 |
| * lifeless is a bit rusty on this code now | 18:18 | |
| rousskov | at crowberry [process #10913], acquired 8 seconds ago. | 18:18 |
| rousskov | process number changes every "bzr update"; time is always small | 18:19 |
| rousskov | "bzr break-lock -v [URL]" does/shows nothing | 18:19 |
| maxb | rousskov: Hi, could you run 'bzr info' in your local branch | 18:20 |
| maxb | In particular I am interested in whether one of the URLs contains the string %7e | 18:20 |
| rousskov | Checkout (format: pack-0.92) | 18:20 |
| rousskov | Location: | 18:20 |
| rousskov | checkout root: . | 18:20 |
| rousskov | checkout of branch: bzr+ssh://bazaar.launchpad.net/%7Erousskov/squid/3p1-rock/ | 18:20 |
| rousskov | Related branches: | 18:20 |
| rousskov | push branch: bzr+ssh://bazaar.launchpad.net/%7Erousskov/squid/3p1-rock/ | 18:20 |
| rousskov | parent branch: /home/rousskov/programs/bazaar/repos/squid/3p1-plus | 18:20 |
| rousskov | submit branch: /home/rousskov/programs/bazaar/repos/squid/v3.1 | 18:20 |
| rousskov | yes, they have %7E | 18:21 |
| maxb | right, in that case this seems to be an URL canonicalization bug in bzr, such that it thinks the encoded and non-encoded form of the ~ character reference different repositories, so it tries to lock them both, and ends up fighting with itself | 18:21 |
| maxb | The easy solution for now is to replace %7E with ~ in your .bzr/branch/branch.conf | 18:22 |
| maxb | Obviously this shouldn't be required, and we need to file a bug and research why this problem is only coming to notice now | 18:22 |
| rousskov | I do not have ~/.bzr/branch/branch.conf. Would ~/.bazaar/locations.conf work? | 18:23 |
| rousskov | Or do you mean ./.bzr/... | 18:24 |
| rousskov | (you do) | 18:24 |
| maxb | yes, I do :-) | 18:24 |
| rousskov | Tree is up to date at revision 9630 of branch bzr+ssh://bazaar.launchpad.net/~rousskov/squid/3p1-rock | 18:25 |
| rousskov | maxb, thank you | 18:25 |
| rousskov | lifeless, thank you | 18:25 |
| maxb | np :-) | 18:25 |
| lifeless | maxb: thanks! | 18:26 |
| lifeless | I'd totally forgetten about this bug | 18:26 |
| rousskov | FWIW, this is an old branch/setup. I did upgrade bzr recently (v2.3.0) | 18:27 |
| lifeless | yah, this was a bzr self incompatability | 18:27 |
| lifeless | it had a bug for a bit where it wronte the %7E | 18:28 |
| lifeless | and then the url handling in it had a bug that got fixed and the two interacted | 18:28 |
| rousskov | makes sense | 18:28 |
| jam | lifeless: I'm around now. | 18:30 |
| rousskov | While I am here, I recently had a contributor doing "bzr push" to an lp branch (instead of "bzr commit") and essentially overwriting my recent commits with his merged and new stuff. Is that a bug or a feature? | 18:31 |
| jam | rousskov: he didn't "overwrite" them, but he likely moved them to be merge commits instead of mainline | 18:31 |
| jam | I can draw a graph if you like | 18:31 |
| jam | you can set "append_revisions_only = True" in .bzr/branch/branch.conf and it will prevent that | 18:32 |
| rousskov | yes, they become hidden, the tags were lost, etc. | 18:32 |
| rousskov | I cannot set append_revisions_only on contributor's computer, can I? | 18:32 |
| rousskov | (should not that be the default?) | 18:32 |
| jam | rousskov: you set it on the branch you are sharing | 18:33 |
| jam | bzr config -d lp:$SHARED_BRANCH append_revisions_only=True | 18:33 |
| jam | though you need a newer bzr for 'bzr config' to exist | 18:33 |
| rousskov | Nice. Will try. | 18:33 |
| jam | rousskov: it should not lose the tags | 18:33 |
| jam | you should still be able to do "bzr log -r tag:foo" | 18:33 |
| rousskov | well, they become invisible in "bzr log" | 18:34 |
| jam | you might try "bzr log -n0" to show merged revisions | 18:34 |
| rousskov | and revision numbers I recorded earlier got changed, so I think I can argue that it was not totally seamless/harmless operation. | 18:35 |
| rousskov | (even if bzr still knows everything I did) | 18:35 |
| jam | rousskov: sure. shared branches should generally be used with append_revisions_only = True. It is something we've talked about making default, though people expressed concern over the transition, et.c | 18:37 |
| rousskov | sure, as usual. Thank you for explaining what happened. And I do see the tags with -n0. | 18:38 |
| poolie | hi all | 21:39 |
| mneptok | poolie: hi! | 21:39 |
| poolie | hey there | 21:40 |
| poolie | how are things at Monty Program? | 21:40 |
| jelmer_ | hey poolie, mneptok | 21:41 |
| * mneptok hands jelmer_ some Chap-Stick and pure, unadulterated fury | 21:42 | |
| mneptok | sorry, it's all i have handy :/ | 21:43 |
| poolie | hey jelmer | 21:43 |
| poolie | what are you up to? | 21:43 |
| jam | hey poolie | 21:43 |
| poolie | hi jam | 21:43 |
| poolie | jelmer we should get your lazy-hooks things unblocked | 21:44 |
| poolie | oh, also, just from looking at the kanban | 21:45 |
| poolie | https://bugs.launchpad.net/bzr-hg/+bug/691994 - is that still in progress in launchpad? | 21:45 |
| jelmer_ | hmm, Chap-Stick, that might come in useful | 21:46 |
| jelmer_ | hmm, there's still something laggy about my connection | 21:47 |
| jelmer_ | poolie: Yeah - I'm trying to finish off another fix for bzr-hg that's related which I'd like to land together with that one | 21:47 |
| poolie | fairy nuff | 21:47 |
| poolie | i just ask because there's an mp that seems to be landed | 21:48 |
| jelmer_ | I'd like to get the lazy hooks stuff unblocked too, I'm a bit confused about the status at the moment. | 21:48 |
| jelmer_ | hi jam | 21:57 |
| poolie | jelmer, i'll try to review and update them | 21:58 |
| jelmer_ | poolie: cool, thanks :) | 22:07 |
| * jelmer_ is reviewing MPs from 2008.. it's a bit embarrassing | 22:07 | |
| jml | I just got this in a test that I recently added to Launchpad: | 22:52 |
| jml | Exception IndexError: IndexError('list index out of range',) in <bound method _LockWarner.__del__ of <bzrlib.lockable_files._LockWarner object at 0x10f65d50>> ignored | 22:52 |
| jml | I have no idea where it comes from or why it happened, and I can't reproduce the error locally. | 22:52 |
| jelmer_ | jml: Does it actually cause anything to fail or is it just a warning? | 22:53 |
| jml | jelmer_: it was printed to stderr during a test where I am trying to make sure nothing gets printed to stderr | 22:53 |
| jelmer_ | jml: ah, ok - so from bzr's perspective it's a warning | 22:54 |
| lifeless | a test before yours isn't cleaning up properly / has found a bzr bug : a gc.collect will likely fix the symptoms, but not help you discover the cause | 22:54 |
| lifeless | jelmer_: thats a fail | 22:54 |
| lifeless | IndexError('list index out of range',) | 22:54 |
| jelmer_ | lifeless: I'm not saying it isn't | 22:54 |
| lifeless | jelmer_: buggy code | 22:54 |
| lifeless | jelmer_: lockwarner isn't meant to crash itself | 22:55 |
| jml | lifeless: I'm not sure I want to add a gc.collect() to this test | 22:55 |
| jelmer_ | I'm not sure what could be raising the IndexError though, given how trivial _LockWarner.__del__ is | 22:56 |
| jelmer_ | jml: could warnings.warn() be raising an IndexError perhaps? | 22:56 |
| jml | jelmer_: how so? (the code I'm executing is sphinx, I don't know it very well) | 22:56 |
| jelmer_ | _LockWarner.__del__ is as trivial as: | 22:57 |
| jelmer_ | if self.lock_count >= 1: | 22:57 |
| jelmer_ | warnings.warn("%r was gc'd while locked" % self.repr) | 22:57 |
| lifeless | is .repr an attribute ? | 22:58 |
| lifeless | or a property | 22:58 |
| jelmer_ | lifeless: it's an attribute that's being passed into LockWarner's constructor | 23:01 |
| lifeless | does *it* have a repr | 23:02 |
| lifeless | or a __str__ that can go boom | 23:02 |
| jelmer_ | ah, sorry | 23:02 |
| jelmer_ | no, it doesn't - it inherits them both from its base class: object | 23:02 |
| lifeless | jelmer_: I mean | 23:03 |
| lifeless | what is self.repr.__str__ | 23:03 |
| lifeless | and self.repr.__repr__ | 23:03 |
| jelmer_ | ah, heh | 23:03 |
| jelmer_ | that wasn't what you were asking though :) | 23:03 |
| jelmer_ | the "repr" argument that's being passed in should be a string from what I can see | 23:04 |
| jelmer_ | as it's just the return value of LockableFiles.__repr__() | 23:04 |
| lifeless | ok | 23:05 |
| lifeless | that seems unfragile | 23:05 |
| lifeless | jml: have you (or your test helpers) fiddled with the guts of warnings ? | 23:05 |
| jml | lifeless: not me. I'm inheriting from lp.testing.TestCase and running in zope, so who knows. | 23:06 |
| mgz | warnings.warn can certainly throw an index error | 23:09 |
| mgz | especially if tests previously have been warnings.filters has been messed with the control/supress warnings for a previous test | 23:10 |
| jml | LP has all sorts of warnings fiddling in it. | 23:11 |
| mgz | hm... actually, code looks safer than I remember, iterates over it, doesn't index | 23:11 |
| mgz | one way to find out, if you can repo | 23:11 |
| mgz | is add try/except/printstack | 23:12 |
| lifeless | raose | 23:12 |
| jml | mgz: I can't. Wish I could. | 23:14 |
| lifeless | jml: why can't you? | 23:14 |
| lifeless | jml: I mean, if it happens in ec2 reliably, thats reproduction isn't it ? | 23:14 |
| jml | lifeless: I've only run it once on ec2. Trying again now. | 23:15 |
| jml | lifeless: the feedback cycle is prohibitively long. | 23:15 |
| lifeless | its terrible | 23:15 |
| lifeless | soon as a ta work item slot turns up we'll do something about that | 23:15 |
| poolie | hi mgz, jml | 23:18 |
| mgz | hey poolie. man I mangled my sentences just now. | 23:23 |
| jml | poolie: hello | 23:25 |
| poolie | hi jml | 23:27 |
| poolie | so the lep seemed to go reasonably well | 23:27 |
| poolie | some constructive feedback | 23:27 |
| jml | poolie: cool | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!