| === r0bby_ is now known as robbyoconnor | ||
| vila | hello bazaristas ! | 07:41 |
|---|---|---|
| poolie | vila, hi | 07:53 |
| nigelb | bazaristas is a bizzare word ;) | 07:55 |
| poolie | vila i want to go soon but i would like to write some config developer docs | 07:55 |
| poolie | first | 07:55 |
| poolie | is there anything more up to date than configuration.txt? | 07:55 |
| vila | I was thinking about that too while discussing with jelmer the other day, | 07:56 |
| vila | he mentioned that devnotes/configuration.txt should go in bzr.dev (can't remember where exactly but there is a place we talk about our plans) | 07:56 |
| vila | but back to the dev subject itself, | 07:56 |
| poolie | ah | 07:57 |
| poolie | yes i think it should go there | 07:57 |
| vila | I happily review/complete whatever you want to wrote | 07:57 |
| poolie | devnotes was interesting but just putting it in trunk is better | 07:57 |
| poolie | we land things faster now | 07:57 |
| vila | ok | 07:57 |
| poolie | we do need to garden out stuff that gets old | 07:57 |
| vila | crap, I have local revisions to push to devnotes | 08:00 |
| vila | pushing^H^H^^Hed | 08:01 |
| vila | I will review/submit that | 08:01 |
| vila | targeting at trunk that is | 08:01 |
| poolie | so reading that document | 08:02 |
| poolie | it's fine | 08:02 |
| poolie | but it starts with a kind of longwinded explanation of current problems | 08:02 |
| poolie | 1- these will eventually be fixed | 08:02 |
| poolie | 2- i just want to look up an option! | 08:03 |
| vila | 1) if we keep track of it yes | 08:03 |
| vila | 2) right, user guide vs reference guide | 08:03 |
| poolie | so what we have in the tree should perhaps be structured as | 08:04 |
| poolie | brief overview | 08:04 |
| poolie | how to use the common cases | 08:04 |
| poolie | more details | 08:04 |
| vila | so, will a rewrite on the document follows ... hehe | 08:04 |
| poolie | then, the kind of changes we want to make | 08:04 |
| vila | 1) how to use 2) reference guide 3) pending issues | 08:05 |
| vila | hehe | 08:05 |
| vila | wfm | 08:06 |
| vila | poolie: any related bug you can think of or should I just go from our discussion here ? | 08:11 |
| poolie | ah for what? | 08:11 |
| poolie | documentation of configuration? | 08:11 |
| poolie | i think | 08:11 |
| vila | clarifying the config , yeah | 08:11 |
| poolie | i'll just put up an mp answering my questions | 08:11 |
| poolie | you can tell me if the answers are right :) | 08:12 |
| vila | hehe, k, no bug then. Can you use a lp:~bzr branch so I can push there too ? | 08:13 |
| vila | poolie: in other news, I requeue a bunch of imports yesterday, | 08:14 |
| poolie | great | 08:14 |
| poolie | good idea about a team branch | 08:15 |
| vila | ~20 now succeeds, ~50 moved from one kind of failure to another, I started digging the find_unimported_versions:check (74 failures) ones which led to an interesting discussion with jelmer | 08:16 |
| poolie | nice work | 08:16 |
| vila | the 74 failures may also be related to the other 43 ones from find_unimported_versions (no :check) | 08:16 |
| poolie | speaking of which, i wasn't sure if you heard the other day i made your terrine | 08:17 |
| poolie | vaguely speaking of which | 08:17 |
| vila | really ?? Great ! So ? | 08:17 |
| poolie | it was good | 08:17 |
| vila | :) | 08:17 |
| poolie | your corrections were on point - it would have been too salty otherwise etc | 08:17 |
| poolie | :) | 08:17 |
| vila | I'm glad you enjoyed it :) Will tell my friend his recipe went around the world ;) | 08:17 |
| vila | poolie: and did you manage with the advices about how ti find if it's cooked or not ? | 08:22 |
| vila | s/ti/to/ | 08:22 |
| poolie | i did | 08:22 |
| poolie | i used a thermometer too | 08:22 |
| vila | cheater :) | 08:23 |
| poolie | i think it could have done with a little less time | 08:23 |
| poolie | anyhow i thought it might please or amuse you to know | 08:24 |
| vila | oooh, that reminds me that I cheat too (yeah, thanks, pleased and amused indeed): | 08:24 |
| vila | I made several terrine in various sizes so the smaller ones are finished first and help get the biggest one right | 08:24 |
| poolie | ok https://code.launchpad.net/~bzr/bzr/doc/+merge/84069 | 08:24 |
| vila | and also allow the chief to taste before serving ;) | 08:25 |
| poolie | :) | 08:25 |
| poolie | ok | 08:26 |
| poolie | i've pushed my stuff | 08:26 |
| poolie | i think i'll log off soon | 08:26 |
| vila | waiting for lp to refresh | 08:26 |
| vila | enjoy your evening (and week-end right ?) | 08:26 |
| poolie | this was leading up to changing to append_revisions_only | 08:26 |
| poolie | thanks, yes | 08:26 |
| vila | yeah, I've seen your bug comment, | 08:26 |
| vila | the last experience we did was on the importer but I need to refresh my memory about why we reverted it and whether or not it should block making it the default (I strongly hope not) | 08:27 |
| vila | and yes, -Oappend_revisions_only should work (and if not, should be fixed) | 08:27 |
| vila | and yes, -Oappend_revisions_only=False should work (and if not, should be fixed) | 08:27 |
| mgz | morning! | 08:29 |
| vila | mgz: hey ! | 08:29 |
| poolie | vila so was my patch actually correct? | 08:30 |
| poolie | :/ | 08:30 |
| vila | which one ? | 08:31 |
| vila | I haven't see a patch for a_r_o yet, but I agree (strongly) with the intent | 08:31 |
| poolie | the doc thing | 08:31 |
| poolie | anyhow | 08:31 |
| poolie | not a big deal | 08:31 |
| poolie | i'm not going to finish a_r_o this week, i think | 08:31 |
| vila | yup, doc thing sounds good, perfect for driving my answers | 08:31 |
| vila | there is one important thing missing though: which stack you chose for a given option defines where it can be defined and where the modifications will be made | 08:32 |
| vila | i.e. GlobalStack or BranchStack for example | 08:33 |
| vila | weird, nexuiz-data is at it again, consuming 4GB without any obvious output... (but 100% CPU) | 08:36 |
| vila | for hours it seems | 08:36 |
| fullermd | Maybe they borrowed some developers from firefox. | 08:37 |
| vila | DuplicateKey: Key new-362 is already present in map, yeah 362 ! will be so fun to debug :-} | 08:38 |
| mgz | vila: do you remember the trick to get localised strerror? I did it on a box at home but now can't get it working here. | 09:14 |
| mgz | what I've done is `dpkg-reconfigure locales` to get some non-english ones, and then set LAND and LC_ALL and use locale.setlocale | 09:15 |
| mgz | but... that seems to not be enough | 09:15 |
| vila | mgz: LANG but yeah should do | 09:15 |
| mgz | yeah, that was just an IRC tyop. | 09:16 |
| vila | mgz: on the other hand, I'm definitely the one to ask for that: I switch to C decades ago and never looked bac k;) | 09:16 |
| vila | this is supposed to Just Work, with additional tweaks via LANG | 09:17 |
| mgz | okay, fail at that, dug up another bug by accident instead | 09:25 |
| mgz | worked it out at second try, also have LANGUAGE env var that breaks things | 09:46 |
| vila | OS ? | 09:47 |
| mgz | ehem. | 09:47 |
| vila | we do weird stuff about locales in the bzr script itself too | 09:47 |
| vila | oh, That one ;) | 09:47 |
| mgz | no, not windows, it's easy on windows :) | 09:48 |
| vila | debian ? | 09:48 |
| mgz | yup. | 09:48 |
| mgz | okay, it's working. | 09:50 |
| mgz | now tempted to see if I can close a long standing bug without even having the change any code... | 09:50 |
| mgz | should be able to run a full selftest even on this machine now the test suite cleans itself up better | 09:52 |
| vila | yak shaving *is* useful ;) | 09:53 |
| vila | jelmer: no wonder doc/developers/plans.txt fell of my radar, it's not part of the online site... something weird happened years ago | 09:54 |
| vila | ha, no, it's part of the sphinx generated docs not the regular ones | 10:05 |
| mgz | still a little memory constrained, errors on fork | 10:06 |
| mgz | trying again with X gone should do it though. | 10:07 |
| jelmer | vila: did you see mydiscusion with james yesterday here on IRC? | 10:32 |
| vila | jelmer: yup, was waiting for you to summarize, | 10:32 |
| vila | so, we keep the upload history, | 10:33 |
| vila | yet, I found your idea interesting too, so longer term we may want to investigate, it sounds like a useful optimization | 10:33 |
| vila | overall, there is more than one history ;) | 10:34 |
| jelmer | yeah, there is some tension here between convenience for packagers and keeping all history | 10:36 |
| * vila nods | 10:38 | |
| === yofel_ is now known as yofel | ||
| mgz | two failures, I think both were known random ones | 11:07 |
| vila | what's the difference between random and spurious in English ? | 11:09 |
| vila | (in the context of test failures I mean, not in general) | 11:10 |
| mgz | spurious implies the failure isn't meaningful, but may always happen | 11:11 |
| mgz | random implies the failure may or may not happen, but might be meaningful | 11:11 |
| vila | thks | 11:12 |
| mgz | some of our issues may be both spurious and random (the test test server ones), but some of the races are random but not spurious | 11:12 |
| mgz | (they could in theory be hit in general usage) | 11:13 |
| mgz | are views documented anywhere? does anything currently use them? | 11:15 |
| mgz | bt.test_sftp_transport.test_bad_connection_ssh fails if paramiko is not installed | 11:17 |
| vila | are your two last messages related ? | 11:20 |
| vila | views are used by some people AIUI | 11:20 |
| vila | bt...bad_connection should use requireFeature, we *have* a paramiko one right > | 11:21 |
| vila | yup, features.paramiko | 11:21 |
| mgz | unrelated, just doing other things while tests run | 11:22 |
| mgz | hm, and the test does use that require | 11:23 |
| mgz | wonder what's going on (apart from general bogosity of using run_bzr outside blackbox) | 11:23 |
| mgz | ...ah, actuallyrun_bzr_subprocess so probably a path issue | 11:24 |
| vila | more MalformedTransform bugs on jubany. Joy ;) | 11:24 |
| mgz | your favourite :) | 11:25 |
| vila | hehe, looks like I'm making progress at using tree transform ;) | 11:27 |
| mgz | so two bugs, one is that run_bzr_subprocess doesn't get my path right, the other is that this test sucks. | 11:28 |
| vila | LOL | 11:29 |
| vila | and trying the version proposed in the comment ? | 11:30 |
| vila | even hardy uses python-paramiko-1.6.4 so that may be worth a try | 11:31 |
| vila | yesterday results of poking jubany: http://webnumbr.com/ubuntu-package-import-failures.from%282011-11-01%29 | 11:32 |
| vila | back to where we were 3 weeks ago :) | 11:32 |
| mgz | it looks like the commented version may be a happier route indeed, if the only flaw was some ssh kipple | 11:33 |
| jelmer | mgz: we do seem to be playing whack-a-mole with unicode bugs, rather than actively trying to find and squash them :( | 12:11 |
| jelmer | I do wonder if python3 (and an attempt to port to it) would be helpful in that regard. | 12:11 |
| jelmer | or to phrase it differently - being explicit about what is encoded and what are bytes would both help our existing python2 version of bzr, and porting to python3 | 12:12 |
| mgz | I'm still tempted by the idea of objectizing paths, but that's not clearly a win | 12:18 |
| mgz | the current state of bytes input, get unicode paths, change to utf-8 for dirstate, maybe change back to unicode for reporting error... is not ideal | 12:19 |
| jelmer | mgz: being forced to use non-bytestring paths on Linux is frustrating | 12:20 |
| mgz | the transcoding could be avoided, what we really want is validation though | 12:21 |
| mgz | which you can't easily do in python except by .decode(...) | 12:21 |
| vila | but you proposed (in that mail ;) some escaping scheme that could be used. With objectized (sp?) paths, this will at least be done in a single place. Obj... paths would also provide a simpler API | 12:34 |
| vila | ideally we'll still accept <whatever> in the current API and start throwing deprecation warnings | 12:35 |
| vila | since neither approach (whack-a-mole / all paths as objects) can be done in one go, starting both would at least make the goal clearer | 12:36 |
| vila | The alternative name of 'safe_utf8' is 'break_things_randomly' :-D | 13:07 |
| jelmer | vila: its name is kindof ironic | 13:09 |
| vila | just found that in mgz's review, burst out laughing because I was expecting an explanation so the joke really took me off-guard :) | 13:09 |
| vila | the most scary is that I'm pretty sure I used it in the past, with confidence, and I can't remember where :-} | 13:10 |
| jelmer | mgz: can we deprecate it? | 13:10 |
| vila | not a lot of uses left according to grep, good surprise | 13:12 |
| chromaticwt | is there a way to push a bzr repo to github? | 14:01 |
| mgz | jelmer, vila: there are lots of things in osutils that would ideally be deprecated | 14:22 |
| mgz | it's a bit too tempting to just dump stuff in there. | 14:23 |
| mgz | chromaticwt: it's possible to push to github with bzr, but you'd need a (git) branch registered via the site already to target | 14:25 |
| === mgz_ is now known as mgz | ||
| vila | mgz: yup, lots of things to clean up there | 14:41 |
| mgz | okay, bug half one worked out and fixed. | 15:23 |
| mgz | test machinery sets $HOME which then breaks the site module's path addition if run_user_subprocess is run | 15:25 |
| vila | huh ? Why would tests use site modules ? | 15:26 |
| vila | talk about isolation... | 15:26 |
| mgz | 'site' is the (ugly) module that runs at python startup and does things like filling in bits of the sys module | 15:27 |
| mgz | one part of that is adding things to sys.path | 15:27 |
| vila | ha, sorry | 15:27 |
| vila | but what kind of $HOME can break that ? | 15:28 |
| vila | isn't it a case where TestCase is used where TestCaseInTempDir should / | 15:28 |
| vila | ? | 15:28 |
| mgz | if HOME is set to a tempdir, when the site module tries to add my user specific python packages in ~/.local it's looking relative to that tempdir | 15:28 |
| mgz | hence, self.requireFeature(features.paramiko) passes, but the spawned subprocess says there's no paramiko | 15:30 |
| mgz | I have a fix. | 15:30 |
| vila | there is no .local dir there, so should be fine or is it that '~' needs to be expanded ? | 15:30 |
| * vila blinks and wait to see the fix :) | 15:31 | |
| mgz | ~/.local expands to /home/martin/.local in the selftest process, but for the subprocess the test spawns it expands to /tmp/bzr/.... | 15:31 |
| vila | and you installed paramiko in ~/.local | 15:31 |
| mgz | right. | 15:31 |
| vila | I'm stil surprised requireFeature() works... | 15:32 |
| vila | does it means it is first called when $HOME is valid ? | 15:32 |
| mgz | paramiko works from bzr - I run bzr as me. | 15:32 |
| mgz | site does it's path lookup once at python startup | 15:32 |
| vila | argh | 15:33 |
| mgz | so bzr gets the right module paths... unless spawned from within a testcase where we set $HOME | 15:33 |
| vila | so what ? We need to force a PYTHONPATH ? | 15:33 |
| vila | this vaguely rings a bell | 15:33 |
| fullermd | Nono, just copy everything in it into the tempdir! | 15:34 |
| vila | didn't run_bzr_subprocess already tweak the env ? | 15:34 |
| mgz | nearly - there's actually a more targetted envvar we can use instead | 15:34 |
| mgz | PYTHONUSERBASE | 15:34 |
| vila | jelmer: looks like import_upstream blows up if a symlink is turned into a dir (probably a packaging mistake) this leads to http://package-import.ubuntu.com/status/rserve.html#2011-12-01%2011:18:38.327140 | 15:54 |
| vila | reproduced locally when importing 0.5-3 where clients is now an exact copy of src/client instead of clients -> src/client | 15:55 |
| mgz | that sounds similar to an error that the path name encoding branch fix exposed as well | 15:55 |
| vila | jelmer: does that ring a bell ? | 15:55 |
| mgz | I think the logic is just old and incorrect. | 15:56 |
| vila | mgz: more context ? | 15:56 |
| mgz | ikiwiki | 15:56 |
| mgz | slightly different place, but I think the problem is similar. | 15:57 |
| vila | in my case, the code involved try to handle renames but this is a kind change (symlink -> dir) | 15:58 |
| mgz | basically the custom transform in bzrtools_import is complicated, a little buggy, and not maintained | 15:58 |
| vila | ha | 15:59 |
| mgz | we've done fixes for this symlink stuff in bzr itself (poolie tackled a bunch of bugs), but this is different code doing the same kind of thing | 15:59 |
| mgz | so, we don't benefit from that. | 15:59 |
| mgz | I said to jelmer when I last looked at this that ideally the bzrtools_ copied modules would ideally just be ripped out and replaced | 16:00 |
| vila | ha | 16:00 |
| mgz | most of the logic isn't used, just the core transform, which should live elsewhere | 16:00 |
| mgz | (and then it would get its bugs and corner cases fixed more easily) | 16:01 |
| vila | just a matter of refactoring under the associated tests umbrella right ? | 16:01 |
| mgz | right. | 16:01 |
| mgz | there are six or so testcases for it | 16:01 |
| vila | better than I thought :-P | 16:02 |
| mgz | probably some more need writing or things would break, but the job is basically to work out what the code is trying to do and then make it use other mechanisms :) | 16:02 |
| mgz | at worst, it would highlight gaps in the bzrlib api that need plugging, and could then share testing but not implementation yet | 16:03 |
| mgz | ^good mgz classic double 'ideally' up there | 16:04 |
| mgz | vila: so, it was on my list for when I wanted to get to know transform code better, if you have a bunch of similar failures now it might be worth tackling before then | 16:06 |
| vila | I think I will file a bug and punt, I've got a good enough explanation for the failure and more important ones to address first :-/ | 16:07 |
| mgz | :) | 16:08 |
| vila | I agree with the feeling that this code is duplicating features that should be implemented elsewhere but it's more a gut feeling that a real understanding | 16:08 |
| mgz | hm... transport.get_transport(something_bogus) doesn't raise these days? | 16:11 |
| mgz | connection doesn't happen till later? | 16:12 |
| vila | yup, always have | 16:13 |
| mgz | okay, ensure_base() should do, the commented out test just needs fixing | 16:15 |
| vila | even .has('not-exist') should be enough (and is already used as an idiom working for read-only transports too) | 16:16 |
| vila | bug #800270 | 16:17 |
| ubot5 | Launchpad bug 800270 in BzrTools "import-tar incorrectly handles symlinks turned into directories" [Medium,Triaged] https://launchpad.net/bugs/800270 | 16:17 |
| vila | mgz: by the way, since you reviewed the 2.4 variant, https://code.launchpad.net/~vila/bzr/test-server-races/+merge/84096 should be easy to review ;) | 16:27 |
| mgz | I have a tab in my browser for that :) | 16:27 |
| vila | You'll even find the comments you were asking for at the time but weren't committed when I submitted :-} | 16:28 |
| mgz | okay, fixed test works, just need to make a less hacky varient | 16:28 |
| vila | i.e. have a look at the revisions dates ;) | 16:28 |
| CaMason | quick Q... how can I get my working tree to be at a particular revision? | 16:44 |
| mgz | `bzr update -r N` | 16:46 |
| mgz | using revert works as well, and may be what you want depending on the circumstance | 16:47 |
| CaMason | ok thanks | 16:49 |
| mgz | what I sometimes do as well, if I want to jump between revisions and maybe base other work of them | 16:50 |
| mgz | is create a new (treeless) branch with `bzr branch -r N dev rN` and then switch my checkout to and from it | 16:51 |
| CaMason | I'm getting a bunch of conflict messages. Taking a bak | 17:01 |
| mgz | if there's a lot of divergence, just having a new tree is sometimes easiest. | 17:05 |
| CaMason | I know what the problem is - some non-versioned files that would otherwise be deleted (folder changed) | 17:08 |
| CaMason | new branch fixed it | 17:08 |
| mgz | ah, yeah, that one is always annoying, the dreaded pyc problem. | 17:10 |
| CaMason | thanks for the assistance | 17:10 |
| mgz | `bzr clean-tree --force --ignored -q && bzr update -r N` is also possible, but annoying to spell | 17:11 |
| vila | mgz: that run_bzr_subprocess diff presented by lp is one of the less informative yourcan get :) It's in tests/__init__.py, ok, but where ? :D | 17:11 |
| vila | .pyc problem is supposed to be addressed with bbzr.transform.orphan_policy=move | 17:12 |
| vila | until we have a way to split precious/junk files, that's the best work around | 17:12 |
| vila | gha tyop | 17:13 |
| vila | bzr.transform.orphan_policy=move in bazaar.conf | 17:13 |
| vila | CaMason, mgz: ^ | 17:13 |
| vila | (yes, there is at least one hook in tree transform ;) | 17:14 |
| * vila EOD, doctor said I still work too much ;) | 17:15 | |
| mgz | EOD happily vila. | 17:15 |
| mgz | if lp let me specify --diff-options=-U20 I'd use it :) | 17:17 |
| timrc | why does pushing a bzr branch a couple times seem to "sort out" this issue? https://pastebin.canonical.com/56636/ | 17:47 |
| timrc | (apologies for the canonical pastebin, I can re-paste to ubuntu if necessary) | 17:47 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === agrimm_ is now known as mull | ||
| wgz | win box lives, and I can still just about manage to get over my aversion to hardware | 20:03 |
| kiko | hey there | 21:02 |
| kiko | I'm still running into https://bugs.launchpad.net/bzr/+bug/855155 | 21:02 |
| ubot5 | Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [High,Confirmed] | 21:02 |
| kiko | is there somebody who can give me a hand into recovery? | 21:02 |
| wgz | kiko: you should just be able to branch into a fresh directory to recover | 21:17 |
| wgz | it's a problem with the dirstate, which is just used for tracking the local tree, so the core repo is fine | 21:19 |
| kiko | wgz, the problem is that the "fresh directory" is /etc | 21:23 |
| kiko | :-/ | 21:23 |
| wgz | do you have any local changes pending? | 21:23 |
| kiko | lots | 21:23 |
| kiko | that's the problem | 21:23 |
| wgz | ...are any renames or executable bit changes that you wouldn't be able to redo? | 21:24 |
| wgz | if not, run `bzr repair-workingtree` | 21:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!