| poolie | hi spiv, all | 00:02 |
|---|---|---|
| * thumper looks for bzr guru | 01:13 | |
| thumper | who is awake | 01:13 |
| jelmer | ok, I admit it. | 01:13 |
| jelmer | I'm still awake | 01:13 |
| thumper | hi jelmer :) | 01:13 |
| jelmer | what's up thumper ? :-) | 01:13 |
| thumper | I have an interesting process problem | 01:14 |
| thumper | lets say I'm doing a bug fix | 01:14 |
| thumper | based off trunk | 01:14 |
| thumper | and after some investigation I have a small patch | 01:14 |
| thumper | now, that patch is identified as being simple enough for an SRU | 01:14 |
| thumper | so I'd like to make my branch now based of the SRU branch | 01:14 |
| thumper | but I want my changes kept | 01:14 |
| thumper | any ideas? | 01:14 |
| jelmer | thumper: so you'd like to cherry pick your fix into an older release series? | 01:15 |
| thumper | or just rebase the branch | 01:15 |
| jelmer | or do you want to create a patch to go into the debian/patches directory of your SRU package? | 01:15 |
| thumper | I suppose you could shelve, then pull override? | 01:16 |
| thumper | we have a series branch for the SRU work | 01:16 |
| jelmer | thumper: Are you doing any commits in the mean time? | 01:16 |
| thumper | maybe... | 01:16 |
| thumper | I'm trying to nut out a simple process | 01:16 |
| jelmer | thumper: if not, I would just do "bzr merge -d sru --uncommitted trunk" | 01:16 |
| thumper | for working on SRUable bug fixes | 01:16 |
| thumper | jelmer: so making a new branch? | 01:17 |
| jelmer | 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 |
| jelmer | thumper: I would definitely make a new branch for the SRU work | 01:17 |
| thumper | I'm not interested in the commit history for this case | 01:17 |
| thumper | ok, too hard to rebase the existing? | 01:18 |
| jelmer | thumper: rebasing works too, but the problem with rebasing is that you're applying all commits individually | 01:18 |
| thumper | how does merge --uncommitted work when the other branch is based off a much older revision? | 01:18 |
| jelmer | so if each one fails to apply, you have to resolve conflicts in each one. | 01:18 |
| thumper | but it gives you the conflict markers et al? | 01:18 |
| jelmer | thumper: yeah, --uncommitted should work in that case | 01:19 |
| thumper | ok, cool | 01:19 |
| thumper | thanks | 01:19 |
| jelmer | thumper: you do get the conflicts, but you have to resolve them and run "bzr rebase-continue" for each commit that conflicts | 01:19 |
| jelmer | thumper: if you have 2 commits that's probably not an issue | 01:19 |
| jelmer | thumper: if you're backporting 40 commits it becomes more annoying :) | 01:19 |
| thumper | jelmer: I'd probably rather avoid rebase... | 01:20 |
| jelmer | (presuming most of them conflict, of course) | 01:20 |
| jelmer | 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:20 |
| thumper | jelmer: thanks for that | 01:21 |
| thumper | jelmer: -3..-1 only takes two commits right? | 01:24 |
| thumper | the last and second last? | 01:24 |
| jelmer | thumper: yes | 01:28 |
| jelmer | thumper: "bzr help merge" also has a pretty good description | 01:28 |
| thumper | kk, ta | 01:28 |
| kinkie | Hi all | 07:59 |
| vila | kinkie: hi | 08:06 |
| vila | hi all ! | 08:06 |
| fullermd | Oh, vila's up. Must be bedtime. | 08:24 |
| vila | fullermd: huh ? Are you ill ? | 08:26 |
| vila | :-p | 08:26 |
| fullermd | Mentally or physically? :p | 08:28 |
| vila | Well, we're talking about some recent change so I guess it means the later :) | 08:29 |
| vila | 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 |
| ubot5 | 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:49 |
| ChrisCauser | 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? | 08:59 |
| vila | ChrisCauser: show us your script and we'll see what happens ;) | 09:00 |
| ChrisCauser | vila: Thanks http://paste.ubuntu.com/771983/ | 09:00 |
| vila | ChrisCauser: but basically, yes, this a good place to ask | 09:01 |
| ChrisCauser | 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 |
| ChrisCauser | Basically, this is a bash prompt for bzr | 09:01 |
| ChrisCauser | in 2.3 and 2.4, it works as you'd think | 09:01 |
| ChrisCauser | in 2.5, I get [:] output, because I get a NotABranchError being caught in line 51 | 09:02 |
| ChrisCauser | I get the same error if I use open_containing in line 39 | 09:03 |
| vila | k, was about to suggest that, | 09:03 |
| ChrisCauser | 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:04 |
| vila | which you disagree with because bzr can find a branch there otherwise right ? | 09:05 |
| ChrisCauser | 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 |
| ChrisCauser | yes, exactly | 09:05 |
| vila | right, it finds a .bzr/branch dir | 09:05 |
| vila | what kind of branch is that ? What does 'bzr info -v' says ? | 09:06 |
| ChrisCauser | Hang on a second. I'll just install 2.5 on my work computer | 09:06 |
| vila | line 40 is useless isn't it ? | 09:07 |
| vila | hmm, using branch.nick *after* unlock is... blurry | 09:07 |
| ChrisCauser | This script is full of historical artefacts. You are correct about line 40 | 09:09 |
| mthaddon | vila: howdy, have a python-testtools question for you | 09:10 |
| mthaddon | 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 |
| vila | mthaddon: hello ! | 09:10 |
| ChrisCauser | vila: http://paste.ubuntu.com/771990/ | 09:10 |
| vila | mthaddon: according to jml who is testtools ubermaster, quoting "using 0.9.6 is close to criminal", | 09:11 |
| ChrisCauser | vila: This is the error I get http://paste.ubuntu.com/771991/ | 09:11 |
| mthaddon | 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:11 |
| vila | 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 |
| vila | mthaddon: as far as bzr itself is concerned, yes | 09:12 |
| mthaddon | thx | 09:12 |
| jml | 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 | |
| vila | jml: thanks, my confidence was ~90%, going up to 99% if you say so | 09:12 |
| vila | ChrisCauser: looking, | 09:14 |
| vila | 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 |
| vila | ChrisCauser: your script works for me | 09:15 |
| jml | vila: double check the Changes section of 0.9.8 to be extra sure | 09:15 |
| ChrisCauser | vila: What version of bzr are you using? I'm using the daily ppa | 09:15 |
| vila | ChrisCauser: I've been running from source since... can't remember | 09:16 |
| vila | revno 6376 right now | 09:16 |
| vila | jml: loooking | 09:16 |
| vila | mthaddon: Hold on ! | 09:17 |
| mthaddon | holding | 09:17 |
| vila | mthaddon: there is a pending bug regarding upgrading pqm | 09:17 |
| mthaddon | vila: you're saying we can't upgrade to 0.9.8 just yet on bzr's pqm instance? | 09:18 |
| vila | mgzctl alarm ring | 09:18 |
| vila | mthaddon: searching the bug, from memory, compat issue for older bzr series | 09:18 |
| ChrisCauser | 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 |
| vila | bug #839461 | 09:19 |
| ubot5 | Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461 | 09:19 |
| mthaddon | vila: but we're already on 0.9.6 on pqm, so it seems like we'd already be in trouble there | 09:20 |
| vila | 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 |
| vila | ouch | 09:20 |
| vila | mthaddon: bumper to critical, I'll get in touch with you once mgz is up and running ;)( | 09:21 |
| mthaddon | k, thx | 09:21 |
| vila | ChrisCauser: gimme as sec | 09:22 |
| ChrisCauser | vila: Thanks | 09:25 |
| vila | ChrisCauser: what's your mininum python version requirement ? | 09:26 |
| vila | mum, sry :) | 09:26 |
| ChrisCauser | vila: For the script? I guess it's the minimum for bzr which is 2.6 | 09:27 |
| vila | lol, what an idiot, you're right of course :) | 09:27 |
| ChrisCauser | :) | 09:28 |
| vila | ChrisCauser: http://paste.ubuntu.com/772000/ is how I would spell it these days | 09:30 |
| vila | ChrisCauser: does this make a difference ? | 09:31 |
| ChrisCauser | 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:32 |
| vila | 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:33 |
| vila | not having probers means nothing can be used | 09:34 |
| ChrisCauser | Ah, Ok. Well, apparently I have no probers, and ControlDirFormat.register_format is not being fired | 09:34 |
| vila | hmm,add a 'print bzrlib.__file__' after import bzrlib to double-check which version you're using | 09:35 |
| ChrisCauser | vila: Looks good: /usr/lib/pymodules/python2.6/bzrlib/__init__.pyc | 09:36 |
| vila | and 'bzr version' tells you the same story or a different path ? | 09:36 |
| vila | ChrisCauser: Also, try with BZR_PLUGIN_PATH=-site | 09:39 |
| ChrisCauser | vila: Yes, it's the same. I have now got it working. I have to "import bzrlib.bzrdir" explicitly in the script | 09:39 |
| vila | O_o | 09:40 |
| vila | ChrisCauser: file a bug please | 09:40 |
| vila | and what if you set BZR_PLUGIN_PATH ? | 09:40 |
| vila | ChrisCauser: and anything interesting in .bzr.log ? | 09:41 |
| ChrisCauser | .bzr.log looks pretty uninteresting | 09:41 |
| ChrisCauser | BZR_PLUGIN_PATH makes no difference | 09:42 |
| vila | hehe, well done vila, spot on ! | 09:45 |
| vila | at least we know the issue doesn't come from a plugin ;) | 09:45 |
| vila | 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:46 |
| vila | ChrisCauser: if nothing else, 'with bzrlib.intialize()' should be enough, if it's not, t's a bug | 09:48 |
| vila | 'I not used'... "I'm not used" and I need more coffee :) | 09:48 |
| ChrisCauser | 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 |
| ChrisCauser | Perhaps it was a speed consideration that it was left out | 09:49 |
| ChrisCauser | Anyway, many thanks for all the hard sleuthing. I'll file a bug report | 09:49 |
| vila | 1143 does not match, what's the line content / | 09:50 |
| vila | ? | 09:50 |
| vila | controldir.ControlDirFormat.register_prober(BzrProber) ???? | 09:50 |
| wgz | failing to get network operational this morning... | 10:00 |
| wgz | vila: are we going to do another release off 2.2? | 10:01 |
| vila | https://launchpad.net/bzr/+milestones says 2012-02-09 but is subject to change depending on bugs fixed | 10:02 |
| ChrisCauser | vila: Yes, that's the one. I've filed a bug report | 10:02 |
| ChrisCauser | https://bugs.launchpad.net/bzr/+bug/905218 | 10:02 |
| ubot5 | Ubuntu bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New] | 10:02 |
| ChrisCauser | I hope it is detailed enough | 10:03 |
| vila | 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:03 |
| vila | wgz: my turn now :) | 10:04 |
| vila | wgz: did you get some results for news_merge on pqm ? | 10:04 |
| wgz | the only obvious locations.conf seemed to last modified 3 years ago | 10:04 |
| wgz | 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 |
| vila | good point | 10:05 |
| vila | let's talk about testools first then | 10:05 |
| vila | what are the options ? | 10:05 |
| wgz | well, I'm not too worried about upgrading it, various small things have broken and then been fixed across versions | 10:06 |
| vila | 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:06 |
| vila | or separate pqm from the other ? | 10:07 |
| wgz | if it turns out something fails with the new version, we just need to land whatever bzrlib change is required | 10:07 |
| wgz | but 0.9.8 should be fine for 2.2 | 10:07 |
| wgz | whereas newer versions would require some test output fix backporting | 10:07 |
| vila | can you double-check that and update bug #839461 ? | 10:07 |
| ubot5 | Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [Critical,Confirmed] https://launchpad.net/bugs/839461 | 10:07 |
| wgz | sure | 10:08 |
| vila | I just bumped it to critical waiting for a more precise diagnosis | 10:08 |
| wgz | heh, I don't have a 2.2 tree here | 10:08 |
| wgz | I think I deleted it as no longer relevent | 10:08 |
| * wgz branches | 10:08 | |
| vila | mwhahah, you want to make our compat overlord cry ? | 10:09 |
| wgz | well, I *run* a pre-2.2 version as my base bzr on this box | 10:13 |
| wgz | okay, with trunk testtools, get three: | 10:15 |
| wgz | AttributeError: 'module' object has no attribute 'ExtendedTestResult' | 10:15 |
| wgz | will roll back to 0.9.8 | 10:15 |
| wgz | there's a change I fixed that in I could backport to 2.2 | 10:15 |
| * vila nods and notes that 0.9.12 seems possible (this will have my preference) | 10:18 | |
| wgz | no s- bt.test_selftest errors with 0.9.8 | 10:20 |
| wgz | I'll do a more extensive subset and see if there's anything else, but I expect it to be okay | 10:21 |
| wgz | okay, two doctest isolation problems that weren't backported... | 10:24 |
| wgz | dammit! was a laptop hardware bug | 10:32 |
| wgz | can probably transfer to the right box now | 10:32 |
| vila | wgz: "laptop hardware bug" ? Related to testtools ? | 10:38 |
| mgz | yeay! and it's still morning | 10:38 |
| mgz | no, related to me not being able to get on the network this morning | 10:39 |
| mgz | enabling then disabling the wireless made the wired hardware start responding | 10:39 |
| mgz | will have to remember that for next time. | 10:40 |
| mgz | so I don't spend quite as long checking the cabling... | 10:40 |
| wgz | http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8 | 10:42 |
| wgz | all known issues, nothing testtools related | 10:43 |
| vila | so 0.9.8 is a valid alternative for bzr-2.2 ? | 10:43 |
| wgz | yup. | 10:43 |
| vila | jml, mthaddon : ^ | 10:44 |
| vila | jml: is that ok with you or do you need 0.9.12 somewhere (in which case, when ? ;) | 10:44 |
| mthaddon | vila: that's great, thx | 10:45 |
| mthaddon | vila: we'll go with 0.9.8 for now | 10:45 |
| vila | wgz: I never know how to interpret (grok?) these pages | 10:46 |
| wgz | click on the little coloured boxes | 10:46 |
| * vila nods | 10:46 | |
| vila | but how can I conclude: nothing wrong here | 10:46 |
| wgz | what I did was: | 10:47 |
| vila | for the whole page without clicking on all red (only ?) | 10:47 |
| wgz | 1) see there was no big red bar for any of the rows | 10:47 |
| wgz | that would indicate a test module failed to import | 10:47 |
| wgz | 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 |
| vila | ha, ok | 10:48 |
| wgz | ideally, you'd just look at the whole page and go "no red or orange!" | 10:48 |
| wgz | but the testsuite isn't quite that solid | 10:48 |
| vila | yeah, now I understand that I can't get that without practice ;) | 10:49 |
| wgz | eg: | 10:49 |
| wgz | http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#bb.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home | 10:49 |
| wgz | this is a problem with the test, and the design of trace | 10:49 |
| vila | hehe, I almost mentioned just that one :) | 10:49 |
| wgz | the test wants to escape isolation and get real `bzr version` output | 10:50 |
| vila | http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#%28doctest%29bzrlib | 10:50 |
| wgz | and fails if trace.enable_default_logging() hasn't been called | 10:50 |
| wgz | ^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 |
| vila | oh, ChrisCauser encountered an issue in a script even after calling bzrlib.initialize() bug #905218 | 10:51 |
| ubot5 | Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New] https://launchpad.net/bugs/905218 | 10:51 |
| wgz | 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 |
| wgz | the import tariff type tests are a way around that | 10:52 |
| vila | a job for a subprocess test | 10:52 |
| wgz | http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5494 <- fix for that bzrlib doctest issue | 10:55 |
| vila | and you're still based on 2.2 because this runs with ? | 10:55 |
| * vila tries to refresh his memory ;) | 10:56 | |
| wgz | ...without testtools :) | 10:56 |
| vila | :-D | 10:56 |
| vila | . 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 ;) | 10:57 |
| wgz | ha, okay, with trunk the only new errors are in <http://zippedmartin.dyndns.org/xmlbin/newtestresult#bt.test_selftest> | 11:16 |
| hrw | jelmer: like promised: bug 905275 reported | 11:16 |
| ubot5 | 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 |
| wgz | the bad part is the fix for that is from my testcase collection branch, so there's no direct backport possible | 11:17 |
| vila | wgz: gut feeling == skip those tests for 2.2 and be done | 11:19 |
| vila | wgz: if this is enough to allow us to use 0.9.12, the risk is negligible | 11:20 |
| wgz | though... I do have one neat rev for it: <http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5340.12.7> | 11:20 |
| vila | wgz: would be clearer with from bzrlib.testools.testresult import doubles | 11:21 |
| vila | wgz: but small enough as it is for SRUs | 11:22 |
| vila | err, but good enough as it is, being small, for SRUs | 11:22 |
| vila | wgz: could you update the bug with a summary/bug task creation whatever you feel appropriate :) | 11:23 |
| vila | wgz: and thanks a lot, that's far clearer now, death to FUD ! :) | 11:24 |
| wgz | will just test 2.3/2.4 as well while here | 11:26 |
| niemeyer | Hey all | 11:57 |
| niemeyer | Quick question: | 11:57 |
| niemeyer | Once one "bzr update -r N", how to tell which revision the current working tree currently represents? | 11:58 |
| niemeyer | "bzr revno" still shows the tip | 11:58 |
| wgz | `bzr revno --tree` | 11:59 |
| vila | 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 |
| vila | jelmer: I'll switch to BZR_PLUGIN_PATH-site | 12:09 |
| vila | jelmer: I'll switch to BZR_PLUGIN_PATH=-site | 12:09 |
| jml | vila: 0.9.8 is a valid alternative. 0.9.12 is at the mercy of a willing volunteer to package | 12:25 |
| jml | vila: which might end up being me, but others are welcome to go ahead. | 12:25 |
| vila | jml: thanks for confirming | 12:43 |
| wgz | bah, initialize is still a mess | 12:50 |
| wgz | pass setup_ui=False and you get a traceback | 12:50 |
| wgz | what's needed to get the old (quiet) behaviour bad again: <http://paste.ubuntu.com/772153/> | 12:55 |
| vila | 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:13 |
| wgz | yeah. | 13:14 |
| vila | 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 |
| vila | should scale for threads too | 13:15 |
| vila | 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 |
| vila | meh and tests of course | 13:16 |
| wgz | see r6210 as well | 13:23 |
| vila | hehe, yeah, I know this one :) | 13:31 |
| vila | I don't like the global_state=None approach hence my "provides a sensible default behavior when importing bzrlib" | 13:31 |
| vila | in other words, let's initialize *something* cleanly and *then* give ways to tweak | 13:32 |
| === yofel_ is now known as yofel | ||
| adiroiban | Hi. I am getting this error: | 14:59 |
| adiroiban | bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'StringIO' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory | 14:59 |
| adiroiban | second time I call branch = bzrlib.branch.Branch.open_containing(self.url)[0] | 14:59 |
| adiroiban | any idea what is wrong? | 14:59 |
| wgz | we need more context to know what's going wrong, it's a symptom of lazy import misuse | 15:00 |
| wgz | so, full traceback, and ideally the module with your code as well? | 15:00 |
| adiroiban | I am trying to fix the buildbot, bzrpoller | 15:01 |
| wgz | ah... it's an error in trace | 15:01 |
| wgz | from bzrlib.lazy_import import lazy_import | 15:01 |
| wgz | lazy_import(globals(), """ | 15:01 |
| wgz | from cStringIO import StringIO | 15:01 |
| wgz | ... | 15:01 |
| adiroiban | http://pastebin.ubuntu.com/772280/ | 15:01 |
| adiroiban | call is at line 287 | 15:02 |
| wgz | you can probably avoid it by doing `with bzrlib.initialize(): your_main()` in your script | 15:02 |
| adiroiban | aha | 15:02 |
| adiroiban | so the bzrlib.initialize() should be called only once? | 15:03 |
| wgz | file a bug against bzr, because the bad code is in bzrlib.trace | 15:03 |
| adiroiban | ok. I will file a bug. thanks! | 15:03 |
| wgz | and yes, the fix is probably just to make init happen once at the right time | 15:03 |
| wgz | include the full traceback in the bug, and say what you run to hit it | 15:05 |
| adiroiban | any suggestion for the title? | 15:06 |
| adiroiban | or just put any title that will be updated | 15:06 |
| adiroiban | if required | 15:06 |
| wgz | "IllegalUseOfScopeReplacer from replacement of StringIO" or something | 15:06 |
| adiroiban | ok | 15:06 |
| lamalex | Hi, is there any way to get bzr-builder to use pbuilder to build its package? | 15:09 |
| jelmer | lamalex: at the moment, no | 15:11 |
| jelmer | lamalex: though you should be able to use --no-build and then use pbuilder manually | 15:11 |
| adiroiban | 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 |
| wgz | adiroiban: could also just be a race, which we have a bug for already | 15:13 |
| wgz | but it's config not trace that needs fixing, I guessed wrong | 15:14 |
| adiroiban | wgz: unfortunately I am stuck with python 2.5 so I am using bzr 2.3.4 | 15:15 |
| wgz | so, try "from bzrlib import config; config.StringIO()" before spawning threads | 15:15 |
| wgz | which will deal with that particular one at least | 15:16 |
| adiroiban | it seems like config.StringIO() solve the problem... | 15:16 |
| adiroiban | thanks! | 15:16 |
| lamalex | jelmer, ah, that's a good idea | 15:22 |
| lamalex | 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:22 |
| jelmer | lamalex: it doesn't build binary packages at all | 15:25 |
| lamalex | oh, ha | 15:26 |
| lamalex | but --no-build and pbuilder should work for building a binary package | 15:26 |
| jelmer | vila: what's the easiest way to create a stack from a string? | 15:49 |
| vila | jelmer: a store from a string and then a stack from a store like I did for your commit builder branch ? | 16:04 |
| jelmer | vila: ah, thanks | 16:05 |
| vila | bzrlib.tests.test_commit.py | 16:05 |
| vila | jelmer: and hi ! :) | 16:06 |
| * vila scrolls back for stacked questions | 16:06 | |
| vila | 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 |
| ubot5 | 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 |
| vila | also, ChrisCauser encounter a weird issue: bug #905218 | 16:08 |
| ubot5 | Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Critical,Confirmed] https://launchpad.net/bugs/905218 | 16:08 |
| vila | jelmer: I thought the prober could ring a bell with you | 16:09 |
| jelmer | vila: yep, target 2.8 and mark as fixcommitted | 16:09 |
| jelmer | vila: yeah, that makes sense | 16:09 |
| jelmer | vila: we don't import bzrlib.bzrdir necessarily | 16:09 |
| jelmer | vila: so we don't register the prober for .bzr in some cases. We should probably import bzrlib.bzrdir from bzrlib.initialize() | 16:09 |
| vila | but the end result is that open_workingtree ends up raising NotABranch because no prober is registered | 16:10 |
| jelmer | vila: right, because we haven't registered the prober for .bzr/ | 16:11 |
| vila | a bit weird that importing workintree.py doesn't trigger importing bzrdir.py... | 16:12 |
| vila | and also why wasn't it the case for bzr-2.4 ? (Probably more lazy loading related) | 16:12 |
| jelmer | vila: yeah, more lazy loading | 16:12 |
| jelmer | vila: there isn't much in bzrlib.workingtree that is bzr-specific | 16:13 |
| jelmer | vila: so nothing uses bzrlib.bzrdir | 16:13 |
| vila | yeah, wt.py vs wt4.py ? | 16:13 |
| jelmer | vila: right - wt.py just contains the main API, which is shared by bzr and foreign formats | 16:13 |
| jelmer | 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:14 |
| jelmer | I think in bzrlib.workingtree | 16:15 |
| jelmer | as we're already doing something similar in bzrlib.branch and bzrlib.repository | 16:15 |
| vila | or registering the bzr prober lazily somehwere ? | 16:15 |
| vila | ha, that's probably best then | 16:15 |
| ChrisCauser | jelmer: Thanks a lot for the help with #905218 | 16:31 |
| jelmer | ChrisCauser: np | 16:33 |
| jelmer | we've been reducing the number of imports that bzr does at startup time, and that's now biting us | 16:34 |
| ChrisCauser | 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:38 |
| vila | jelmer: worth mentioning in the what's new ;) | 16:43 |
| jelmer | vila: what is? | 16:44 |
| vila | jelmer: more lazy loading => bzr quicker | 16:45 |
| jelmer | vila: ah, yeah | 16:45 |
| wgz | wow config_dir is called too many times... <http://float.endofinternet.org/xmlbin/dev_testtools_trunk#bb.test_version.TestVersion.test_main_version> | 17:13 |
| jelmer | wgz: hmm, how can you tell? | 17:15 |
| jelmer | ah, I see now | 17:15 |
| jelmer | well, GlobalStore is called very often | 17:16 |
| vila | If it's now called more often than GlobalConfig, I call it progress ;-) | 17:18 |
| wgz | is there a reason test_osutils.TestGetuserUnicode tests use LOGNAME rather than USERNAME? | 17:18 |
| wgz | I broke them because LOGNAME is meaningless on win. | 17:19 |
| vila | welcome to environ and its standardS | 17:19 |
| wgz | okay, I have a kinda-plan with directories | 17:26 |
| wgz | on startup, bzr should resolve and prepare any well known locations it needs, then stash them somewhere obvious (ie... fix global_state) | 17:26 |
| wgz | so, this is the 'home' config location, a cache directory, whereever we think .bzr.log should go... anything else? | 17:27 |
| wgz | 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:28 |
| jelmer | hmm | 17:44 |
| jelmer | 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:45 |
| mgz | would be nice if pathconf didn't suck | 17:46 |
| mgz | alas, it does. | 17:46 |
| Peng | jelmer: Could create a file once and then stat() it everafter. | 17:46 |
| Peng | Hmm, that'd be a problem if it was moved onto a different fs that did or didn't support the exec bit... | 17:47 |
| mgz | Peng: also, some C libs emulate the exec bit based on file extension | 17:48 |
| jelmer | Peng: yes, and file systems that don't support the X bit have different defaults for the executable bit. | 17:48 |
| mgz | rather than actually storing a bit with the file | 17:48 |
| mgz | jelmer: so, it's easy to discount support in a few cases | 17:50 |
| mgz | proving support is hard | 17:50 |
| mgz | though not quite as hard as proving bug-free support :) | 17:50 |
| mgz | you could cover the common cases if you can use (and trust) a syscall to give you the filesystem type | 17:52 |
| mgz | I bet nfs makes life hard there though | 17:52 |
| jelmer | mgz: I agree the sensible thing to do is: | 17:53 |
| jelmer | * assume win32 doesn't support the executable bit | 17:53 |
| jelmer | * on other platforms, assume the executable bit is support unless we can somehow determine that it definitely isn't | 17:54 |
| vila | conf.set('xxx', ''), val = conf.get('xxx') , val == '""' >.< | 17:54 |
| jelmer | yeah, a configuration option would indeed also be a possibility | 17:55 |
| jelmer | I wish we had a per-tree configuration though.. | 17:55 |
| vila | nah, was mentioning the siliest bug ever, re-read | 17:55 |
| vila | setting a conf option to '', re-reading it, get '""', not '' | 17:56 |
| jelmer | ah :) | 17:56 |
| mgz | heh | 17:56 |
| vila | configobj apparently, been there since epoch | 17:56 |
| vila | why we never ran into it.... | 17:57 |
| mgz | okay, I'm going to finish off the lazy_import threading branch | 17:58 |
| mgz | won't help people marooned on bzr 2.3 like earlier, but the current code is insane compared to MvG's | 17:59 |
| jelmer | mgz: cool | 17:59 |
| jelmer | mgz: I think I found an alternative | 18:00 |
| mgz | doing a fix for that dumb use of StringIO on 2.3 onwards is probably also worthwhile | 18:00 |
| mgz | jelmer: do tell | 18:00 |
| jelmer | mgz: it's not exactly ideal but better than what we have now | 18:01 |
| jelmer | mgz: use stat('.bzr/format') to get st_dev | 18:01 |
| jelmer | then use getmntent to find the file system type.. | 18:02 |
| mgz | and nfs won't be clever and lie | 18:03 |
| mgz | ? | 18:03 |
| jelmer | mgz: well, we'll get back "nfs" for nfs mounts | 18:03 |
| mgz | if so, that's worth doing. | 18:03 |
| jelmer | 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 |
| jelmer | mgz: at least it means we'll get it right for FAT, etc | 18:04 |
| mgz | well, or fall back to trying a dance | 18:04 |
| mgz | if we can trust 'ext4' (ho ho) then at least the common case doesn't need funny business | 18:04 |
| vila | and we'll keep assuming that's true for the whole wt | 18:05 |
| mgz | ...can anyone think of a reason not to use trace.mutter from inside lazy_import resolution? | 18:06 |
| jelmer | mgz: overhead? | 18:06 |
| vila | trace lazy import | 18:06 |
| mgz | only for duplicate resolution, so not all the time... will double check the loop issue | 18:07 |
| jelmer | mgz: still there? | 19:20 |
| mgz | jelmer: yup, just had a break for dinner | 19:43 |
| mgz | did the basic simplifications I suggested for the lazy_import change | 20:37 |
| mgz | but wonder if there isn't a proper race-aware way of doing this | 20:37 |
| mgz | where the first thread to both get, and delete, scope, gets to do the work | 20:38 |
| mgz | this could mean other threads are stuffed waiting for it to finish I guess, so deadlock | 20:39 |
| mgz | meph. | 20:39 |
| mgz | can still use that to work out if it's a race or a reuse though | 20:40 |
| Noldorin | hey folks | 20:45 |
| Noldorin | hi mgz | 20:45 |
| mgz | hey Noldorin | 20:45 |
| Noldorin | how's... things? | 20:46 |
| Noldorin | saw the b4 release of 2.5 :-) | 20:47 |
| Noldorin | looking good | 20:47 |
| mgz | getting there :) | 20:52 |
| Reggie | can anyone help a relative bzr novice out? I have someone who pushed a change to remote repo A, and then merged that to remote repo B and then C. The change should have only gone into C | 21:48 |
| Reggie | what's the easiest way to remove it from A and B? | 21:48 |
| Reggie | I know I can overwrite the affected files with the files from current-1 and then do a normal commit but hoping there is an easier or more standard way to do it | 21:49 |
| Reggie | thanks | 21:49 |
| jelmer | hi Reggie | 21:55 |
| Reggie | hi | 21:55 |
| jelmer | Reggie: bzr uncommit is what you're looking for probably | 21:55 |
| Peng | It sounded to me like it was too late for uncommitting. | 21:56 |
| Reggie | dev commited locally and then pushed to remote branch | 21:56 |
| wgz | <http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html#reverse-cherrypicking> | 21:56 |
| wgz | <http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html#undoing-the-last-commit> | 21:56 |
| Reggie | then merged up to B and C locally and pushed them | 21:56 |
| Reggie | now we need to remove the last changeset on the remote repos A & B | 21:57 |
| wgz | whether you want to uncommit or merge a reversion depends on how public the branches in question are | 21:57 |
| Reggie | these are not public | 21:57 |
| Reggie | internally hosted | 21:57 |
| wgz | if lots of people use them, they'd get confused if you rewrite history on them by removing the commit entirely | 21:57 |
| Reggie | not an issue | 21:58 |
| wgz | then uncommit and email to everyone saying "whoops" is generally fine | 21:58 |
| Reggie | here is where I get confused. I do a bzr uncommit and now I see the changed files (which is correct). what then? the bzr uncommit doesn't effect the remote repo? | 21:59 |
| Reggie | do I need to do the bzr uncommit on the remote repo? | 21:59 |
| wgz | yeah, you just pass it as the location | 21:59 |
| wgz | so, `bzr uncommit A` `bzr uncommit B` | 22:00 |
| Reggie | will repo C get confused? the change needs to be in C (these repos are chained together) | 22:00 |
| wgz | depends how you did the merge. | 22:00 |
| wgz | you can branch all three locally, try it out and see | 22:01 |
| wgz | then do it for real when you have the state you want | 22:01 |
| Reggie | devs do merges on their local workstations. they would typically push in folder A then from inside folder B they would do bzr pull; bzr merge ..\A; bzr commit -m"merged"; bzr push | 22:01 |
| Reggie | make sense? | 22:02 |
| wgz | this is getting out of basic fixing a mistake, and into workflows | 22:02 |
| wgz | what would the correct series of operations have been? | 22:02 |
| Reggie | make change in C and push only to C | 22:02 |
| Reggie | instead dev thought the fix should go all the way back to A | 22:03 |
| Reggie | this is a single product versioned. vesrion A, vesrion B, version C | 22:03 |
| wgz | and C is newest. | 22:03 |
| Reggie | yup | 22:03 |
| wgz | uncommit on all three then do it right is fine then. | 22:03 |
| Reggie | any big problem with overwriting the changed files with files from revision-1 and doing a new set of commits/pushes? | 22:04 |
| wgz | if this happened some revisions back, you'd want to reverse the merge on A, merge up to B, merge up to C *then revert the tree but keep the merge* | 22:04 |
| Reggie | I say that because repo C may be already been changed by others so uncommit there might be challenging | 22:04 |
| wgz | if you can replay the new changes on C that's also fine, but deeper into history rewrite territory | 22:05 |
| Reggie | yes, I think you just said what I was trying to say. basically undo the change manually in A & B and then do what I call null-merge to C | 22:06 |
| Reggie | the bad change is the very last change on A & B but it's not the last change on C | 22:06 |
| wgz | that option is basically just `bzr merge -r-1..-2 -d A A; bzr commit A; bzr merge -d B A; bzr commit B; bzr merge -d C B; bzr revert C; bzr commit C` | 22:10 |
| Reggie | right | 22:10 |
| Reggie | :) | 22:10 |
| wgz | `bzr revert *` rather. | 22:10 |
| wgz | you want to keep the merge, but not the changes. | 22:11 |
| Reggie | wgz, thanks. really appreciate the help | 22:11 |
| Noldorin | wgz, oh yeah, was going to ask. does bzr have 'service' plugins like hg does? like for notifying you when someone pushes? | 22:21 |
| Noldorin | on a bzr server | 22:21 |
| Noldorin | that is | 22:21 |
| Noldorin | also, does LP specifically have them? | 22:22 |
| wgz | bzr does, lp doesn't as far as I'm aware, but various things you can use for landing changes like pqm and tarmac can notify | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!