[00:02] hi spiv, all [01:13] * thumper looks for bzr guru [01:13] who is awake [01:13] ok, I admit it. [01:13] I'm still awake [01:13] hi jelmer :) [01:13] what's up thumper ? :-) [01:14] I have an interesting process problem [01:14] lets say I'm doing a bug fix [01:14] based off trunk [01:14] and after some investigation I have a small patch [01:14] now, that patch is identified as being simple enough for an SRU [01:14] so I'd like to make my branch now based of the SRU branch [01:14] but I want my changes kept [01:14] any ideas? [01:15] thumper: so you'd like to cherry pick your fix into an older release series? [01:15] or just rebase the branch [01:15] or do you want to create a patch to go into the debian/patches directory of your SRU package? [01:16] I suppose you could shelve, then pull override? [01:16] we have a series branch for the SRU work [01:16] thumper: Are you doing any commits in the mean time? [01:16] maybe... [01:16] I'm trying to nut out a simple process [01:16] thumper: if not, I would just do "bzr merge -d sru --uncommitted trunk" [01:16] for working on SRUable bug fixes [01:17] jelmer: so making a new branch? [01:17] thumper: otherwise just "bzr merge -r-3..-1 trunk" if you want to cherrypick the last three commits - though that doesn't preserve the commit history [01:17] thumper: I would definitely make a new branch for the SRU work [01:17] I'm not interested in the commit history for this case [01:18] ok, too hard to rebase the existing? [01:18] thumper: rebasing works too, but the problem with rebasing is that you're applying all commits individually [01:18] how does merge --uncommitted work when the other branch is based off a much older revision? [01:18] so if each one fails to apply, you have to resolve conflicts in each one. [01:18] but it gives you the conflict markers et al? [01:19] thumper: yeah, --uncommitted should work in that case [01:19] ok, cool [01:19] thanks [01:19] thumper: you do get the conflicts, but you have to resolve them and run "bzr rebase-continue" for each commit that conflicts [01:19] thumper: if you have 2 commits that's probably not an issue [01:19] thumper: if you're backporting 40 commits it becomes more annoying :) [01:20] jelmer: I'd probably rather avoid rebase... [01:20] (presuming most of them conflict, of course) [01:20] thumper: in that case using "bzr merge -rFROM..TO ../trunk" to cherrypick existing revisions, or "bzr merge --uncommitted" indeed seem like the best choices [01:21] jelmer: thanks for that [01:24] jelmer: -3..-1 only takes two commits right? [01:24] the last and second last? [01:28] thumper: yes [01:28] thumper: "bzr help merge" also has a pretty good description [01:28] kk, ta [07:59] Hi all [08:06] kinkie: hi [08:06] hi all ! [08:24] Oh, vila's up. Must be bedtime. [08:26] fullermd: huh ? Are you ill ? [08:26] :-p [08:28] Mentally or physically? :p [08:29] Well, we're talking about some recent change so I guess it means the later :) [08:49] jelmer: ping, workflow question, I've landed the fix for bug #904704, should I: 1) mark the bug fix committed, 2) target 2.8, or both or something else ? [08:49] Launchpad bug 904704 in bzr-builddeb "non utf-8 encoded changelogs cannot be parsed with recent python-debian" [High,In progress] https://launchpad.net/bugs/904704 [08:59] Hi everyone. I've just got a regression in a script I have written when using bzr 2.5 and was wondering if anyone can help me out? [09:00] ChrisCauser: show us your script and we'll see what happens ;) [09:00] vila: Thanks http://paste.ubuntu.com/771983/ [09:01] ChrisCauser: but basically, yes, this a good place to ask [09:01] I'm afraid I'm going to be horrifically vague because bzr 2.5 is on my home computer and I'm at work [09:01] Basically, this is a bash prompt for bzr [09:01] in 2.3 and 2.4, it works as you'd think [09:02] in 2.5, I get [:] output, because I get a NotABranchError being caught in line 51 [09:03] I get the same error if I use open_containing in line 39 [09:03] k, was about to suggest that, [09:04] The only oddness I can remember is that if I say open '/home/causer/working_copy', the error says that it cannot find a branch in '/home/causer/working_copy/' [09:05] which you disagree with because bzr can find a branch there otherwise right ? [09:05] Also, if the cwd is '/home/causer/working_copy/sub_directory', the error says the url is '/home/causer/working_copy/' again (i.e. it sort of knows that it is a branch) [09:05] yes, exactly [09:05] right, it finds a .bzr/branch dir [09:06] what kind of branch is that ? What does 'bzr info -v' says ? [09:06] Hang on a second. I'll just install 2.5 on my work computer [09:07] line 40 is useless isn't it ? [09:07] hmm, using branch.nick *after* unlock is... blurry [09:09] This script is full of historical artefacts. You are correct about line 40 [09:10] vila: howdy, have a python-testtools question for you [09:10] vila: we have 0.9.6-0~bazaar1.0.IS.8.04 of python-testtools installed, but there's a 0.9.8-1~bazaar1-0.IS.10.04 lurking in lucid-cat-proposed - do you know if it's safe to promote that package so it gets installed on the servers? [09:10] mthaddon: hello ! [09:10] vila: http://paste.ubuntu.com/771990/ [09:11] mthaddon: according to jml who is testtools ubermaster, quoting "using 0.9.6 is close to criminal", [09:11] vila: This is the error I get http://paste.ubuntu.com/771991/ [09:11] vila: ok, cool - the reason I'm asking is because he has asked for 0.9.8 and I'm wondering if we can use it across the board - so that sounds like a yes - thx [09:12] mthaddon: so using 0.9.8 should be ok, but I defer to jml and mgz who knows the compatibility better than me [09:12] mthaddon: as far as bzr itself is concerned, yes [09:12] thx [09:12] vila: the NEWS file has got all known compat issues. I'm pretty sure we're OK though [09:12] * jml means to submit the latest release to Debian & backport 0.9.12 to lucid if possible [09:12] jml: thanks, my confidence was ~90%, going up to 99% if you say so [09:14] ChrisCauser: looking, [09:15] first things that comes to mind so far but not guaranteed to fix your issue: you want a try:finally to unlock when you're really done instead of ad-hoc, you want to make sure you properly initialize bzrlib [09:15] ChrisCauser: your script works for me [09:15] vila: double check the Changes section of 0.9.8 to be extra sure [09:15] vila: What version of bzr are you using? I'm using the daily ppa [09:16] ChrisCauser: I've been running from source since... can't remember [09:16] revno 6376 right now [09:16] jml: loooking [09:17] mthaddon: Hold on ! [09:17] holding [09:17] mthaddon: there is a pending bug regarding upgrading pqm [09:18] vila: you're saying we can't upgrade to 0.9.8 just yet on bzr's pqm instance? [09:18] mgzctl alarm ring [09:18] mthaddon: searching the bug, from memory, compat issue for older bzr series [09:19] vila: Hmm. I'm on 6349. Python is 2.6. Well, I'll take a look myself and if I find anything, I'll let you know. Thanks for the help anyway [09:19] bug #839461 [09:19] Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461 [09:20] vila: but we're already on 0.9.6 on pqm, so it seems like we'd already be in trouble there [09:20] mthaddon: ok, so, basically, mgz will knows better than me or at least it will be easier for me to discuss with him [09:20] ouch [09:21] mthaddon: bumper to critical, I'll get in touch with you once mgz is up and running ;)( [09:21] k, thx [09:22] ChrisCauser: gimme as sec [09:25] vila: Thanks [09:26] ChrisCauser: what's your mininum python version requirement ? [09:26] mum, sry :) [09:27] vila: For the script? I guess it's the minimum for bzr which is 2.6 [09:27] lol, what an idiot, you're right of course :) [09:28] :) [09:30] ChrisCauser: http://paste.ubuntu.com/772000/ is how I would spell it these days [09:31] ChrisCauser: does this make a difference ? [09:32] vila: No, unfortunately. I'm looking at the source, and it seems like no _probers are being registered in the ControlDirFormat class. I'm trying to find out what a prober is now :S [09:33] a prober decides which format should be used based on whatever it feels appropriate: which files are there, what do they content, what kind of server, etc [09:34] not having probers means nothing can be used [09:34] Ah, Ok. Well, apparently I have no probers, and ControlDirFormat.register_format is not being fired [09:35] hmm,add a 'print bzrlib.__file__' after import bzrlib to double-check which version you're using [09:36] vila: Looks good: /usr/lib/pymodules/python2.6/bzrlib/__init__.pyc [09:36] and 'bzr version' tells you the same story or a different path ? [09:39] ChrisCauser: Also, try with BZR_PLUGIN_PATH=-site [09:39] vila: Yes, it's the same. I have now got it working. I have to "import bzrlib.bzrdir" explicitly in the script [09:40] O_o [09:40] ChrisCauser: file a bug please [09:40] and what if you set BZR_PLUGIN_PATH ? [09:41] ChrisCauser: and anything interesting in .bzr.log ? [09:41] .bzr.log looks pretty uninteresting [09:42] BZR_PLUGIN_PATH makes no difference [09:45] hehe, well done vila, spot on ! [09:45] at least we know the issue doesn't come from a plugin ;) [09:46] ChrisCauser: I'm out of ideas for now, but I not used to write scripts using bzrlib, try again later, jelmer and mgz may know better [09:48] ChrisCauser: if nothing else, 'with bzrlib.intialize()' should be enough, if it's not, t's a bug [09:48] 'I not used'... "I'm not used" and I need more coffee :) [09:49] vila: Thanks a lot for all your help. I'm pretty sure the problem is that the prober being registered in bzrlib.bzrdir.__line__ == 1143 should be registered on initialize(). [09:49] Perhaps it was a speed consideration that it was left out [09:49] Anyway, many thanks for all the hard sleuthing. I'll file a bug report [09:50] 1143 does not match, what's the line content / [09:50] ? [09:50] controldir.ControlDirFormat.register_prober(BzrProber) ???? [10:00] failing to get network operational this morning... [10:01] vila: are we going to do another release off 2.2? [10:02] https://launchpad.net/bzr/+milestones says 2012-02-09 but is subject to change depending on bugs fixed [10:02] vila: Yes, that's the one. I've filed a bug report [10:02] https://bugs.launchpad.net/bzr/+bug/905218 [10:02] Ubuntu bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New] [10:03] I hope it is detailed enough [10:03] wgz: so, a new 2.2 is pretty unlikely but I'd rather not discover a compat issue when trying to do a release to fix a critical issue... [10:04] wgz: my turn now :) [10:04] wgz: did you get some results for news_merge on pqm ? [10:04] the only obvious locations.conf seemed to last modified 3 years ago [10:05] while we have mthaddon it would be good to ask him if that's the current one or if the real thing is elsewhere [10:05] good point [10:05] let's talk about testools first then [10:05] what are the options ? [10:06] well, I'm not too worried about upgrading it, various small things have broken and then been fixed across versions [10:06] is 2.2 compatible with 0.9.8-1~bazaar1-0.IS.10.04 (available according to mthaddon) or should we instead check for 0.9.12 and wait for jml to provide it for lucid ? [10:07] or separate pqm from the other ? [10:07] if it turns out something fails with the new version, we just need to land whatever bzrlib change is required [10:07] but 0.9.8 should be fine for 2.2 [10:07] whereas newer versions would require some test output fix backporting [10:07] can you double-check that and update bug #839461 ? [10:07] Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [Critical,Confirmed] https://launchpad.net/bugs/839461 [10:08] sure [10:08] I just bumped it to critical waiting for a more precise diagnosis [10:08] heh, I don't have a 2.2 tree here [10:08] I think I deleted it as no longer relevent [10:08] * wgz branches [10:09] mwhahah, you want to make our compat overlord cry ? [10:13] well, I *run* a pre-2.2 version as my base bzr on this box [10:15] okay, with trunk testtools, get three: [10:15] AttributeError: 'module' object has no attribute 'ExtendedTestResult' [10:15] will roll back to 0.9.8 [10:15] there's a change I fixed that in I could backport to 2.2 [10:18] * vila nods and notes that 0.9.12 seems possible (this will have my preference) [10:20] no s- bt.test_selftest errors with 0.9.8 [10:21] I'll do a more extensive subset and see if there's anything else, but I expect it to be okay [10:24] okay, two doctest isolation problems that weren't backported... [10:32] dammit! was a laptop hardware bug [10:32] can probably transfer to the right box now [10:38] wgz: "laptop hardware bug" ? Related to testtools ? [10:38] yeay! and it's still morning [10:39] no, related to me not being able to get on the network this morning [10:39] enabling then disabling the wireless made the wired hardware start responding [10:40] will have to remember that for next time. [10:40] so I don't spend quite as long checking the cabling... [10:42] http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8 [10:43] all known issues, nothing testtools related [10:43] so 0.9.8 is a valid alternative for bzr-2.2 ? [10:43] yup. [10:44] jml, mthaddon : ^ [10:44] jml: is that ok with you or do you need 0.9.12 somewhere (in which case, when ? ;) [10:45] vila: that's great, thx [10:45] vila: we'll go with 0.9.8 for now [10:46] wgz: I never know how to interpret (grok?) these pages [10:46] click on the little coloured boxes [10:46] * vila nods [10:46] but how can I conclude: nothing wrong here [10:47] what I did was: [10:47] for the whole page without clicking on all red (only ?) [10:47] 1) see there was no big red bar for any of the rows [10:47] that would indicate a test module failed to import [10:48] then I clicked on the little red and orange boxes, and saw they were all failures I know about already, mostly related to the selftest environment being slightly different [10:48] ha, ok [10:48] ideally, you'd just look at the whole page and go "no red or orange!" [10:48] but the testsuite isn't quite that solid [10:49] yeah, now I understand that I can't get that without practice ;) [10:49] eg: [10:49] http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#bb.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home [10:49] this is a problem with the test, and the design of trace [10:49] hehe, I almost mentioned just that one :) [10:50] the test wants to escape isolation and get real `bzr version` output [10:50] http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#%28doctest%29bzrlib [10:50] and fails if trace.enable_default_logging() hasn't been called [10:51] ^that's an old doctest error that's fixed on trunk, basically it's spelt wrong and happened to work in some cases, again because of bad isolation [10:51] oh, ChrisCauser encountered an issue in a script even after calling bzrlib.initialize() bug #905218 [10:51] Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New] https://launchpad.net/bugs/905218 [10:52] right, we have a bunch of issues that selftest doesn't catch by default because it generally runs in a fully set up environment [10:52] the import tariff type tests are a way around that [10:52] a job for a subprocess test [10:55] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5494 <- fix for that bzrlib doctest issue [10:55] and you're still based on 2.2 because this runs with ? [10:56] * vila tries to refresh his memory ;) [10:56] ...without testtools :) [10:56] :-D [10:57] . o O (This guy is schizophrenic, not only does he needs 2 nicks, he also manages to contribute (significantly) to a tool he doesn't use ;) [11:16] ha, okay, with trunk the only new errors are in [11:16] jelmer: like promised: bug 905275 reported [11:17] Launchpad bug 905275 in bzr-git (Ubuntu) "git clone bzr::lp:armel-cross-toolchain-base creates duplicated tags" [Undecided,New] https://launchpad.net/bugs/905275 [11:17] the bad part is the fix for that is from my testcase collection branch, so there's no direct backport possible [11:19] wgz: gut feeling == skip those tests for 2.2 and be done [11:20] wgz: if this is enough to allow us to use 0.9.12, the risk is negligible [11:20] though... I do have one neat rev for it: [11:21] wgz: would be clearer with from bzrlib.testools.testresult import doubles [11:22] wgz: but small enough as it is for SRUs [11:22] err, but good enough as it is, being small, for SRUs [11:23] wgz: could you update the bug with a summary/bug task creation whatever you feel appropriate :) [11:24] wgz: and thanks a lot, that's far clearer now, death to FUD ! :) [11:26] will just test 2.3/2.4 as well while here [11:57] Hey all [11:57] Quick question: [11:58] Once one "bzr update -r N", how to tell which revision the current working tree currently represents? [11:58] "bzr revno" still shows the tip [11:59] `bzr revno --tree` [12:09] jelmer: toying around with your feature-flags branch, ./bzr selftest -s bt.test_bzrdir hangs in bzrlib.tests.test_bzrdir.TestHTTPRedirections_pycurl.test_loop tracked down to bzr-svn [12:09] jelmer: I'll switch to BZR_PLUGIN_PATH-site [12:09] jelmer: I'll switch to BZR_PLUGIN_PATH=-site [12:25] vila: 0.9.8 is a valid alternative. 0.9.12 is at the mercy of a willing volunteer to package [12:25] vila: which might end up being me, but others are welcome to go ahead. [12:43] jml: thanks for confirming [12:50] bah, initialize is still a mess [12:50] pass setup_ui=False and you get a traceback [12:55] what's needed to get the old (quiet) behaviour bad again: [13:13] wgz: the more I think about library state, the more I believe it should provides a sensible default behavior when importing bzrlib and *then* allows calls to initialize() to override whatever you want [13:14] yeah. [13:15] tests and bzr commands would then be executed into a with bzrlib.initialize() block setting the needed bits and restoring the previous state when leaving the block [13:15] should scale for threads too [13:16] this should also limit the places where you need to pass the state around to: commands, tree, branch and repo signgificant calls without requiring passing it across the whole API [13:16] meh and tests of course [13:23] see r6210 as well [13:31] hehe, yeah, I know this one :) [13:31] I don't like the global_state=None approach hence my "provides a sensible default behavior when importing bzrlib" [13:32] in other words, let's initialize *something* cleanly and *then* give ways to tweak === yofel_ is now known as yofel [14:59] Hi. I am getting this error: [14:59] bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'StringIO' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory [14:59] second time I call branch = bzrlib.branch.Branch.open_containing(self.url)[0] [14:59] any idea what is wrong? [15:00] we need more context to know what's going wrong, it's a symptom of lazy import misuse [15:00] so, full traceback, and ideally the module with your code as well? [15:01] I am trying to fix the buildbot, bzrpoller [15:01] ah... it's an error in trace [15:01] from bzrlib.lazy_import import lazy_import [15:01] lazy_import(globals(), """ [15:01] from cStringIO import StringIO [15:01] ... [15:01] http://pastebin.ubuntu.com/772280/ [15:02] call is at line 287 [15:02] you can probably avoid it by doing `with bzrlib.initialize(): your_main()` in your script [15:02] aha [15:03] so the bzrlib.initialize() should be called only once? [15:03] file a bug against bzr, because the bad code is in bzrlib.trace [15:03] ok. I will file a bug. thanks! [15:03] and yes, the fix is probably just to make init happen once at the right time [15:05] include the full traceback in the bug, and say what you run to hit it [15:06] any suggestion for the title? [15:06] or just put any title that will be updated [15:06] if required [15:06] "IllegalUseOfScopeReplacer from replacement of StringIO" or something [15:06] ok [15:09] Hi, is there any way to get bzr-builder to use pbuilder to build its package? [15:11] lamalex: at the moment, no [15:11] lamalex: though you should be able to use --no-build and then use pbuilder manually [15:13] wgz: I tried wrapping the call to bzrlib.branch.Branch.open_containing in a with: bzr.initialize() block, and also tried to call bzr.initialize() just after the import bzrlib, but I get the same error [15:13] adiroiban: could also just be a race, which we have a bug for already [15:14] but it's config not trace that needs fixing, I guessed wrong [15:15] wgz: unfortunately I am stuck with python 2.5 so I am using bzr 2.3.4 [15:15] so, try "from bzrlib import config; config.StringIO()" before spawning threads [15:16] which will deal with that particular one at least [15:16] it seems like config.StringIO() solve the problem... [15:16] thanks! [15:22] jelmer, ah, that's a good idea [15:22] jelmer, i was looking through the source to try and find where it actually builds and i can only find where it builds the source package [15:25] lamalex: it doesn't build binary packages at all [15:26] oh, ha [15:26] but --no-build and pbuilder should work for building a binary package [15:49] vila: what's the easiest way to create a stack from a string? [16:04] jelmer: a store from a string and then a stack from a store like I did for your commit builder branch ? [16:05] vila: ah, thanks [16:05] bzrlib.tests.test_commit.py [16:06] jelmer: and hi ! :) [16:06] * vila scrolls back for stacked questions [16:08] jelmer: ping, workflow question, I've landed the fix for bug #904704, should I: 1) mark the bug fix committed, 2) target 2.8, or both or something else ? [16:08] Launchpad bug 904704 in bzr-builddeb "non utf-8 encoded changelogs cannot be parsed with recent python-debian" [High,In progress] https://launchpad.net/bugs/904704 [16:08] also, ChrisCauser encounter a weird issue: bug #905218 [16:08] Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Critical,Confirmed] https://launchpad.net/bugs/905218 [16:09] jelmer: I thought the prober could ring a bell with you [16:09] vila: yep, target 2.8 and mark as fixcommitted [16:09] vila: yeah, that makes sense [16:09] vila: we don't import bzrlib.bzrdir necessarily [16:09] vila: so we don't register the prober for .bzr in some cases. We should probably import bzrlib.bzrdir from bzrlib.initialize() [16:10] but the end result is that open_workingtree ends up raising NotABranch because no prober is registered [16:11] vila: right, because we haven't registered the prober for .bzr/ [16:12] a bit weird that importing workintree.py doesn't trigger importing bzrdir.py... [16:12] and also why wasn't it the case for bzr-2.4 ? (Probably more lazy loading related) [16:12] vila: yeah, more lazy loading [16:13] vila: there isn't much in bzrlib.workingtree that is bzr-specific [16:13] vila: so nothing uses bzrlib.bzrdir [16:13] yeah, wt.py vs wt4.py ? [16:13] vila: right - wt.py just contains the main API, which is shared by bzr and foreign formats [16:14] vila: I wonder what the better fix is, explicitly importing "bzrlib.bzrdir" at the top of wt.py, or adding "import bzrlib.bzrdir" to bzrlib.initialize? [16:15] I think in bzrlib.workingtree [16:15] as we're already doing something similar in bzrlib.branch and bzrlib.repository [16:15] or registering the bzr prober lazily somehwere ? [16:15] ha, that's probably best then [16:31] jelmer: Thanks a lot for the help with #905218 [16:33] ChrisCauser: np [16:34] we've been reducing the number of imports that bzr does at startup time, and that's now biting us [16:38] jelmer: I guessed that was the problem, but on the flip side, I /really/ do appreciate the work in this area. Bzr is so much quicker now. I really notice it [16:43] jelmer: worth mentioning in the what's new ;) [16:44] vila: what is? [16:45] jelmer: more lazy loading => bzr quicker [16:45] vila: ah, yeah [17:13] wow config_dir is called too many times... [17:15] wgz: hmm, how can you tell? [17:15] ah, I see now [17:16] well, GlobalStore is called very often [17:18] If it's now called more often than GlobalConfig, I call it progress ;-) [17:18] is there a reason test_osutils.TestGetuserUnicode tests use LOGNAME rather than USERNAME? [17:19] I broke them because LOGNAME is meaningless on win. [17:19] welcome to environ and its standardS [17:26] okay, I have a kinda-plan with directories [17:26] on startup, bzr should resolve and prepare any well known locations it needs, then stash them somewhere obvious (ie... fix global_state) [17:27] so, this is the 'home' config location, a cache directory, whereever we think .bzr.log should go... anything else? [17:28] currently there are 6 or so bugs about locations of things, that would be easiest to fix in one big go rather than moving stuff around piecemeal [17:44] hmm [17:45] I wonder if there's an easy way to discover whether a file system supports the executable bit, other than trying to change it on a particular file [17:46] would be nice if pathconf didn't suck [17:46] alas, it does. [17:46] jelmer: Could create a file once and then stat() it everafter. [17:47] Hmm, that'd be a problem if it was moved onto a different fs that did or didn't support the exec bit... [17:48] Peng: also, some C libs emulate the exec bit based on file extension [17:48] Peng: yes, and file systems that don't support the X bit have different defaults for the executable bit. [17:48] rather than actually storing a bit with the file [17:50] jelmer: so, it's easy to discount support in a few cases [17:50] proving support is hard [17:50] though not quite as hard as proving bug-free support :) [17:52] you could cover the common cases if you can use (and trust) a syscall to give you the filesystem type [17:52] I bet nfs makes life hard there though [17:53] mgz: I agree the sensible thing to do is: [17:53] * assume win32 doesn't support the executable bit [17:54] * on other platforms, assume the executable bit is support unless we can somehow determine that it definitely isn't [17:54] conf.set('xxx', ''), val = conf.get('xxx') , val == '""' >.< [17:55] yeah, a configuration option would indeed also be a possibility [17:55] I wish we had a per-tree configuration though.. [17:55] nah, was mentioning the siliest bug ever, re-read [17:56] setting a conf option to '', re-reading it, get '""', not '' [17:56] ah :) [17:56] heh [17:56] configobj apparently, been there since epoch [17:57] why we never ran into it.... [17:58] okay, I'm going to finish off the lazy_import threading branch [17:59] won't help people marooned on bzr 2.3 like earlier, but the current code is insane compared to MvG's [17:59] mgz: cool [18:00] mgz: I think I found an alternative [18:00] doing a fix for that dumb use of StringIO on 2.3 onwards is probably also worthwhile [18:00] jelmer: do tell [18:01] mgz: it's not exactly ideal but better than what we have now [18:01] mgz: use stat('.bzr/format') to get st_dev [18:02] then use getmntent to find the file system type.. [18:03] and nfs won't be clever and lie [18:03] ? [18:03] mgz: well, we'll get back "nfs" for nfs mounts [18:03] if so, that's worth doing. [18:04] mgz: and there's no way of knowing what the underlying fs is, but we can just default to assuming it supports the executable bit [18:04]