[00:41] <poolie> hi jam, spiv, lifeless
[00:44] <lifeless> hiya
[01:02] <spiv> Morning.
[01:02] <poolie> hi spiv
[01:42] <poolie> spiv, i'm preparing my session for the epic
[01:42] <poolie> what are you up to today
[01:50] <spiv> poolie: working on bug 522637, there seems to be some disagreement between a repo and its fallback about the CHK roots for an inventory (and as a tangent having some ideas on a new hpss verb)
[01:50] <spiv> poolie: then thinking about the epic
[01:50] <poolie> ah that sounds good :)
[01:50] <poolie> i'm just about to propose we fork off 2.2 and do 2.2b4
[01:51] <poolie> i want to make the branch allow at this point non-bugfix changes but no api breakage
[01:51] <spiv> Or at least controlled API breakage :)
[01:51] <poolie> i wonder if having it be different to released stable branches will cause confusion
[01:51] <poolie> no intentional api breakage :)
[01:51] <poolie> actually i think not even any deprecations
[01:52] <poolie> but having an 'api freeze' phase is not unprecedented
[02:36] <jbowtie> I just got approval from legal to release my Bazaar plugin.
[02:37] <jbowtie> I'm planning on pushing it to Launchpad under GPLv2 or later; any best practices for publishing plugin projects?
[02:38] <lifeless> generally they are found on LP in bzr-pluginname projects
[02:38] <lifeless> often people put them in the 'bazaar' project group, which gives ~bzr (the broad set of developers of bzr and its plugins) access to do bug triage etc
[02:39] <lifeless> and sometimes people make the trunk branch owned by ~bzr or a dedicated group which ~bzr is in, so that other folk can update the plugin when API changes break it.
[02:39] <lifeless> these are all optional voluntary things of course
[02:43] <jbowtie> lifeless: Thanks, the 'bazaar' project group stuff I didn't know.
[03:09] <poolie> lifeless: i was just wondering why you declined bug 522637 for 2.0 and 2.1
[03:09] <poolie> is it infeasible to fix there?
[03:09] <lifeless> checking
[03:13] <lifeless> poolie: it was ages ago that I declined it
[03:13] <lifeless> the UI kind of encourages 'propose for' on *problems* but perhaps its *solutions* that should be proposed.
[03:13] <lifeless> its the conflation between bug exists and will-fix-in again.
[03:14] <poolie> maybe so
[03:14] <lifeless> ...anyhow... I suspect the fix will be non trivial
[03:14] <poolie> well, i guess the merge can be proposed to either
[03:14] <lifeless> but spiv is working on it I think ?
[03:14] <poolie> but it may be nice to say "we want to try to fix it in 2.0."
[03:14] <poolie> he is
[03:14] <poolie> if he think it's easy to backport
[03:14] <poolie> we can do that
[03:14] <poolie> was just curious
[03:14] <lifeless> I'd get the fix and then make an assessment of that.
[03:14] <poolie> yep
[03:15] <EdWyse_Home> Is there a way to convert a lightweight checkout to a heavyweight one? or do I just have to re-checkout the whole thing?
[03:16] <lifeless> bzr reconfigure --checkout, I think.
[03:17] <EdWyse_Home> Close enough... Thanks
[03:44] <jbowtie> There we go... https://launchpad.net/bzr-tfs
[03:47] <lifeless> \o/
[03:48] <jbowtie> It's a pure python solution, too (relies on python-ntlm for authentication) - means it works nicely on Linux, not just on Windows.
[03:48] <jbowtie> I suppose now I need to write some documentation, and tests, and so on...
[03:48] <lifeless> thats really cool
[04:41] <lifeless> poolie: brief call ?
[04:56] <poolie> lifeless: hi, sure
[04:56] <lifeless> could you ring my NZ house # ?
[04:56] <thumper> how do I cherry pick a revision?
[04:56] <lifeless> merge -c revno branch
[04:56] <thumper> ta
[05:00] <thumper> jbowtie: that's pretty cool
[05:00] <thumper> jbowtie: I don't suppose you are looking at a visual studio plugin are you?
[05:17] <jbowtie> thumper: Not for a while, too many other things on my plate.
[05:29] <parthm> i am seeing some weird error on pqm for the bad-pattern patch. http://dpaste.com/215805/ .. the tests pass locally.
[05:29] <parthm> any ideas?
[05:35] <parthm> the pqm-stderr has this http://pastebin.com/Fn6zSE79
[05:40] <spiv> parthm: those pastes don't give many clues :(
[05:41] <parthm> spiv: i am downloading pqm-stdout to see if that has something.
[05:43] <lifeless> look at the end of pqm-stdout generally
[05:48] <parthm> is there a quick pattern i can search for? the summary shows 3 failures: http://pastebin.com/XL5NHXu7 ... its difficult to different expected tracebacks from actual failures.
[05:50] <lifeless> have you got subunit installed ?
[05:52] <parthm> lifeless: yes. '/usr/lib/python2.6/dist-packages/subunit/__init__.pyc'
[05:52] <parthm> is DeprecationWarning considered an error? .. http://pastebin.com/V8kEyB1z
[05:53] <lifeless> parthm: 'gunzip -c pqm-stdout.gz | subunit-filter --no-skip | subunit2pyunit'
[05:54] <parthm> lifeless: i don't have subunit-filter and subunit2pyunit. where can I get that?
[05:55] <lifeless> parthm: apt-get install subunit
[05:59] <parthm> lifeless: thats pretty neat. http://pastebin.com/hJ98AauT
[06:01] <parthm> bt.test_globbing and bt.test_osutils seem to work fine locally.
[06:04] <parthm> for re_compile_checked the only difference is that its deprecated now. test results: http://pastebin.com/B5JaL8k9
[06:06] <spiv> parthm: IllegalUseOfScopeReplacer means lazy_import is involved
[06:07] <spiv> parthm: which suggests that it might be sensitive to the exact order imports happen :/
[06:07] <spiv> (And so presence/absence of plugins could affect that)
[06:07] <parthm> spiv: ah yes. i see the error now.
[06:08] <parthm> spiv: there is a direct import (not lazy) "from bzrlib.trace import ( errors, ...)" ... note the trace.
[06:08] <parthm> spiv: interestingly it passes locally. i don't know why.
[06:09] <lifeless> plugins
[06:09] <parthm> spiv, lifeless: the import errors is for globbing.py .. forgot to mention.
[06:10] <parthm> i suspect that will fix the scope error. any idea on the re_compile_checked error?
[06:11] <spiv> parthm: regardnig globbing.py, that is pretty weird that lazy_import is involved in the traceback when it's not used in that file.
[06:14] <parthm> spiv: yes. its surprising. also, the tests passing (locally) with that is weird.
[06:15] <spiv> parthm: regarding the deprecation, I think pqm runs python with -Wall, which means warnings are raised as errors, including deprecations
[06:15] <spiv> The docs on writing tests should explain how to write tests for deprecated functions (i.e. how to expect a deprecation from a particular call)
[06:16]  * parthm goes digging into testing docs for deprecation.
[06:17] <spiv> (I mean "should" in the sense of "I do not know if they actually cover that, but if they don't then please file a bug and/or fix that" :)
[06:18] <spiv> If they don't, you should be able to grep the test suite for how other tests do it.
[06:19] <parthm> spiv: its not mentioned in the testing doc. but HACKING.txt mentions "TestCase.applyDeprecated" without much explanation. i will file a bug for updating the testing doc.
[06:20] <spiv> parthm: thanks :)
[06:21] <parthm> spiv, lifeless: thats for the help in locating the issues :) ... i will try to land this again once these are fixed.
[06:39] <poolie> hi spiv, parthm
[06:40] <parthm> poolie: hi
[07:46] <vila> hi all
[07:47] <lifeless> hiya
[08:04] <parthm> looks like another error. http://pastebin.com/Z4qRJUGX ... looks like re.compile is calling python2.4 re.compile directly and not the lazy one. test passes locally (python2.6)
[08:04] <parthm> lazy re_compile: http://bazaar.launchpad.net/~parthm/bzr/300062-bad-pattern-error-part-1/annotate/head:/bzrlib/lazy_regex.py#L61
[08:04] <parthm> compile failure should be raising InvalidPattern and not re.error. any ideas?
[08:10] <parthm> lifeless: just saw the mail on your move to launchpad. congratulations and thanks for all the reviews and piloting :) good luck.
[08:10] <lifeless> thanks!
[08:17] <parthm> hmm. i ran the test with python2.4 and didn't see any problem. so its not python related.
[08:17] <lifeless> parthm: have you tried with --no-plugins ?
[08:18] <parthm> lifeless: yes. i am running it with no-plugins. the tests pass locally with 2.4 and 2.6.
[08:19] <parthm> looks like re is not being lazy on babune. the stack trace doesn't seem to be going through lazy regex http://pastebin.com/Z4qRJUGX
[08:20] <lifeless> mmm
[08:20] <lifeless> vila: ^ :)
[08:21] <parthm> does the test generate a .bzr.log with exception details?
[08:22] <parthm> vila: "python -Wall ./bzr --no-plugins selftest -v -s bt.test_osutils.TestReCompile" passes locally but fails on pqm.
[08:22] <vila> parthm: what os are you using ?
[08:22] <lifeless> parthm: oh
[08:22] <lifeless> parthm: run other tests that use re perhaps ?
[08:22] <lifeless> parthm: I suspect you're running into a test isolation issue of some sort.
[08:23] <parthm> vila: ubuntu 9.10
[08:23] <lifeless> possibilities: something puts the real re back; something triggers the regex you expect to be lazy before your test runs (solution, use your own private re), $something else.
[08:23] <parthm> lifeless: thats the only test thats failing now (even on pqm). rest all pass.
[08:23] <lifeless> parthm: great.
[08:23] <lifeless> bbiab
[08:24] <vila> parthm: babune is not supposed to change anything regarding loading python modules (the mere thought of it scares the hell out of me)
[08:25] <parthm> vila: is pqm on babune or is it a different system. just curious.
[08:25] <vila> parthm: nah, pqm is a totally different host/chroot/etc
[08:26] <parthm> oh ok. then its what i am seeing on pqm. babune is fine :)
[08:26] <vila> But is pqm still running 2.4 ?
[08:27] <parthm> vila: yes. thats what the error shows http://pastebin.com/Z4qRJUGX
[08:29] <parthm_> sorry. i dropped off.
[08:30] <parthm_> this is the failing test case. http://bazaar.launchpad.net/~parthm/bzr/300062-bad-pattern-error-part-1/annotate/head:/bzrlib/tests/test_osutils.py#L1718
[08:30] <parthm_> maybe its playing badly because i now have assertRaises + applyDeprecated together.
[08:31] <parthm_> but interestingly it works ok locally.
[08:31] <spiv> parthm_: have you tried 2.4 locally?
[08:32] <parthm_> spiv: yes. it passes with 2.4 as well as 2.6.
[08:33] <spiv> I doubt assertRaises or applyDeprecated would interact or otherwise be the cause.
[08:33] <spiv> Perhaps the deprecation decorator itself is involved?
[08:34] <spiv> Though that seems a bit unlikely too.
[08:35] <vila> parthm: too many interacting stuff here to diagnose remotely without reproducing :-/
[08:36] <parthm> vila: yes :( ... will see if i can try to reproduce it locally.
[08:36] <vila> parthm: generally, a test subset pass but not the whole test suite, you need to first run the full suite locally to see if *that* reproduce it
[08:38] <parthm> vila: makes sense. i will try to do that.
[08:39]  * parthm fires the full test suite
[08:41] <vila> lifeless: hmpf, best wishes for your new role but while this isn't fully unexpected it makes me sad :-(
[08:55] <parthm> i am starting to get the "can't start new thread" errors. is there something i can do? i am already using --parallel=fork.
[08:56] <vila> parthm: bump BZR_CONCCURENCY up
[08:57] <vila> BZR_CONCURRENCY
[08:57] <parthm> vila: what should i set it to? i have two cores.
[08:57] <vila> the precise value is: it depends :->
[08:58] <vila> I'd try with 4 then 6 or 8 depending on available resources
[08:58] <vila> parthm: be ready to ^C it if it start swapping like hell
[08:58] <parthm> vila: at the moment its not set. ok. i will try with 4. hopefully my 1gb ram won't be an issue. maybe its time for an upgrade :)
[09:00] <vila> 1GB seems a bit short, all babune slaves have 2GB
[09:00] <parthm> ok. everything seems ok till now ... 1500 tests. ... and its fast :)
[09:01] <vila> parthm: hehe, it sure is :)
[09:03] <lifeless> vila: THANKS
[09:03] <lifeless> bah
[09:03] <lifeless> thanks
[09:10] <parthm> vila: yup. the error is reproducible half way through the full suite run. now i just need to figure out whats causing the laziness to go away.
[10:03] <parthm> forcing lazyness seems to fix the problem http://pastebin.com/b5csDHQd .. while not the _right_ solution, i feel it should be ok as the api being tested is deprecated anyway and is not used.
[10:04] <parthm> should i be filing a bug for test isolation?
[12:59] <lifeless> night
[14:34] <GaryvdM> Hi all - Why do I get this error: http://pastebin.org/386377
[14:34] <GaryvdM> Which differs from the documentation: http://docs.python.org/release/2.6/library/threading.html#id1
[14:38] <GaryvdM> Ah - nvm - must just do lock.acquire(False), not lock.acquire(blocking=False)
[14:50] <mgz> hey Gary. where are you at with the installers? is 2.2b3 is a finished-ish state?
[15:13] <GaryvdM> Hi mgz
[15:13] <mgz> hey.
[15:13] <mgz> I'm just writing up a message for the list, can you read it before I post to make sure it makes sense?
[15:14] <GaryvdM> mgz: 2.2b3-2 does the -OO backed out...
[15:14] <GaryvdM> let me try again..
[15:14] <GaryvdM> mgz: 2.2b3-2 is built with your org  -OO patch backed out...
[15:15] <mgz> need to leave in an hour, won't be around again till Tuesday, so make any final choices on that for me
[15:15] <GaryvdM> mgz: I would like to try you py2exe hack
[15:16] <GaryvdM> mgz: Ok - I'm only going to start trying to build 2.2b4 next week any way
[15:16] <mgz> ah, cool.
[15:16] <GaryvdM> So - yhea - 2.2b3 probably  won't get any more bulids....
[15:16] <GaryvdM> (from me)
[15:17] <GaryvdM> mgz: I was just about to go to ice hockey practice, so I will only be able to read your mail much later.
[15:18] <mgz> ah, I'll just post it when I'm done then.
[15:18] <GaryvdM> ok
[15:18] <GaryvdM> mgz: What is it re?
[15:19] <mgz> what plugin authors need to know about docstring stripping
[15:19] <mgz> bascially summing up what's been said in the merge proposal and in here the last few days
[15:19] <GaryvdM> Oh - ok.
[15:21] <GaryvdM> mgz: I just want to make sure that we are on the same page with the -OO issue: We want to get it so that library.zip is -OO, but the exe's are -O.
[15:22] <mgz> ideally, yup.
[15:22] <GaryvdM> mgz: ok cool.
[15:22] <GaryvdM> bye
[16:06] <mgz> urk, running out of time
[16:15] <mgz> okay, email sent, and I'm leaving
[16:15] <mgz> as did it in a hurry, probably full of mistakes, feel free to correct me on things
[16:15] <mgz> back Tuesday.
[18:45] <LeoNerd> I don't suppose there's much by way of bzr/perforce integration, is there?
[18:46] <rockstar> LeoNerd, I know some Nvidia folks that are doing it, but I don't think it's publicly available.
[18:46] <LeoNerd> Right.. ahwell
[18:57] <james_w> LeoNerd: there is https://code.launchpad.net/bzrp4
[18:58] <james_w> no idea what state it is in
[19:05] <idnar> what are branch nicknames for?
[19:25] <chaosaddict> It seems like with a large repository (6000 commits, 40gb of files+history), routine commands take about an hr to return and use up all available memory. Does anyone know if this is a known issue and if it will be fixed in the future? I'm looking into migrating from Perforce to Bazaar for my company, but right now it looks like it would be much too costly.
[19:28] <idnar> is there an easier way to do "bzr merge -r before:ancestor:trunk.. feature-branch"?
[19:35] <mkanat> chaosaddict: I think one of the problems there is that most VCSes don't expect to be storing enormous binary blobs.
[19:35] <mkanat> chaosaddict: It is a known issue, though, that bzr uses up a lot of memory when dealing with large files.
[19:36] <mkanat> chaosaddict: I'll take a wild guess and say that this is a VCS for a game?
[19:36] <mkanat> Those are the only people I know who store enormous binary blobs in the VCS, are game developers.
[19:36] <mkanat> I understand why, it's just not something that most VCSes are geared toward.
[19:37] <mkanat> idnar: They show up in the log history.
[19:37] <mkanat> idnar: So you can tell what branch a commit was made on.
[19:37] <idnar> okay
[19:43] <chaosaddict> mkanat: It's not for a game. I think we just have a lot of files. It's been complicated by Perforce storing branches as copies of files, so we often have maybe 30 copies of the same file.
[19:43] <mkanat> chaosaddict: All right. But a single checkout is 40GB?
[19:44] <mkanat> chaosaddict: Or just the history is 40GB?
[19:56] <chaosaddict> mkanat: I imported all the code for one product, which probably has multiple logical projects that would normally be tracked separately in bazaar. Additionally, there are maybe 20 branches, that have no concept of a main trunk, so all the files are duplicate each time. The fast-import dump file was 30gb, and the resulting bazaar repository after import is 40GB for all the files, with the history.
[19:57] <mkanat> chaosaddict: Hmm. I wonder if you'd want to somehow hack up the importer to understand that some of those files have a common history.
[20:02] <chaosaddict> I think it did a good job of replicating what was in Perforce. I'm not quite sure how I would fix it. Maybe split off each branch into its own bazaar repository and merge it back into a main branch to preserve the history.
[20:14] <mkanat> chaosaddict: Well, if they have identical files, that won't work.
[20:14] <mkanat> chaosaddict: Because bzr doesn't recognize files by name, but by an internal id.
[20:20] <chaosaddict> mkanat: ah. So if the files don't have the same origin, as far as Bazaar knows, then they can't be merged with history preserved? We have fields in the files that Perforce updates with revision numbers and date submitted, etc, so the files won't even hash to the same value, even if they were the same as far as Perforce was concerned.
[20:20] <mkanat> chaosaddict: Right.
[20:20] <mkanat> chaosaddict: The importer has to understand from the start that those files have a common history.
[20:46] <lifeless> morning
[20:48] <chaosaddict> good morning
[22:14] <detritux> hi
[22:40] <hicham> bzr is acting weird when cloning a repo from lp
[22:44] <hicham> i have 50 MB of history for a 15 revisions branch, and it not finished yet
[23:20] <EdWyse_Office> Is there a way to fix an InconsistentDelta?
[23:21] <EdWyse_Office> I can find a lot of things that tell how to get to that state, but nothing about how to repair from it.