Team Chat Logs

August 10, 2009

2009 7
Mo Tu We Th Fr Sa Su
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
<< <   > >>

[05:59:59]<evil_twin>b.e.o: Ticket #301 (Improve recipe handling.) updated - <http://bitten.edgewall.org/ticket/301#comment:2> - trac@…
[06:00:59]<evil_twin>b.e.o: Ticket #428 (Bitten installation problem) created - <http://bitten.edgewall.org/ticket/428> - hugobosscool26@…
[06:01:59]<evil_twin>b.e.o: Ticket #230 (Permit xinclude in build recipies) updated - <http://bitten.edgewall.org/ticket/230#comment:2> - trac@…
[06:05:48]<kirean>hi, is there any known problems running bitten on python 2.6?
[06:06:40]<davidfraser>kirean: Not known by me...
[06:06:43]<kirean>I get this running "sudo python setup.py test":
[06:06:43]<kirean>http://paste.lisp.org/display/85123
[06:07:28]<davidfraser>Hmmm, looks like the logging objects have been shut down
[06:07:48]<davidfraser>Are you using multiprocessing somewhere? bitten doesn't use it itself, and that's what's causing the error
[06:09:10]<kirean>not that I'm aware of
[06:12:08]<kirean>any tip on how to procede investigating what's causing this?
[06:22:06]<davidfraser>What are you trying to test? Looks like you're running the bitten tests themselves - I'd grep all the relevant source code for multiprocessing
[06:26:06]<evil_twin>b.e.o: Ticket #428 (Bitten installation problem) closed - <http://bitten.edgewall.org/ticket/428#comment:1> - osimons
[06:28:21]<osimons>i've run tests on both windows and linux 2.6, and see no such error. wonder what is different with your setup? try without the 'sudo'? tests are run in-place. optionally "PYTHONPATH=. python setup.py test" to be sure
[06:28:32]<osimons>kirean: ^^ that was for you - forgot to address :-)
[06:34:50]<osimons>kirean: the message looks to be from atexit.py, and logging.py registers a shutdown function to be run on exit. does it happen running tests for other sw? like trac?
[06:35:05]<osimons>bbl
[06:44:56]<kirean>yes, I am trying to run the bitten tests
[06:45:04]<kirean>without sudo, same error
[06:47:08]<evil_twin>b.e.o: Ticket #428 (Bitten installation problem) updated - <http://bitten.edgewall.org/ticket/428#comment:2> - hugobosscool26
[06:50:56]<kirean>and also same error when first exporting PYTHONPATH=.
[06:53:51]<kirean>trying to run tests for trac as well
[06:56:25]<kirean>getting the same error on trac test as well:
[06:56:25]<kirean>http://paste.lisp.org/display/85123#2
[07:06:39]<kirean>hmm, what have I done ;-)
[07:13:41]<kirean>what could I have done that causes this?
[07:22:22]<davidfraser>kirean: print out sorted(sys.modules) when you start up python, and from inside the last of the tests. Then try and work out at which point multiprocessing is being loaded
[07:25:26]<kirean>davidfraser: thanks, I'll try that first thing tomorrow.. gotta go now
[07:25:37]<davidfraser>ok kirean, hope it helps
[07:47:22]<evil_twin>b.e.o: Download edited - <http://bitten.edgewall.org/wiki/Download?version=2> - osimons
[07:49:23]<evil_twin>b.e.o: Wiki Start edited - <http://bitten.edgewall.org/wiki/WikiStart?version=26> - osimons
[08:14:12]<pacopablo>morning
[08:28:04]<davidfraser>afternoon pacopablo
[08:32:03]<pacopablo>so, I've got a bit of a testing issue
[08:32:18]<pacopablo>I'm working on fixing bitten to work with multi-repos
[08:33:04]<pacopablo>and I created a get_repos() function that can differentiate between 0.11 and multirepos trac installs
[08:33:40]<pacopablo>the problem is that bunches of tests fail due to it finding a multirepos install
[08:33:56]<pacopablo>and the test setup simply injects the get_repository() method
[08:34:40]<pacopablo>http://bitten.edgewall.org/attachment/ticket/342/t342_multi_repos.patch
[08:34:44]<pacopablo>there is my patch
[08:35:15]<pacopablo>as you can see, I'm adding a module level flag to indicate the presence of absense of multirepos
[08:35:40]<pacopablo>I've tried importing the variable and modifying it in the test class setup, but it doesn't seem to stick
[08:36:35]<pacopablo>so, I need to figure out a way to fool the test
[08:36:58]<pacopablo>additionally, I need to create multireops specific tests, but that's a separate issue entirely
[08:37:04]<pacopablo>any suggestions?
[08:39:17]<davidfraser>pacopablo: Are you saying it's erroneously detecting a multirepos trac install?
[08:41:17]<pacopablo>no, it's detecting it properly
[08:41:35]<pacopablo>cus I'm running on a box that had multirepos installed
[08:42:06]<pacopablo>the problem is that it detects multirepos by importing trac.versionscontrol.api.RepositoryManager
[08:42:21]<pacopablo>so when run in the test, it's pulls that from the full trac install
[08:42:39]<pacopablo>but then when executing the test, it's operating on the mock repository
[08:42:51]<pacopablo>which isn't multirepos compatible
[08:43:31]<pacopablo>additionally, when running under multirepos, instead of pulling the repository from the env, you load a RepositoryManager object (passing in the env)
[08:49:30]<davidfraser>Ah, I see
[08:49:57]<davidfraser>pacopablo: Does the database not contain a different schema update version?
[08:50:01]*davidfraser is off for supper
[08:57:50]*osimons just finished his
[08:59:13]<osimons>pacopablo: hmm. tests. right. likely tests should cover both types - for the tests that where repository is something more than just 'stuffing' to get req mocking working
[09:00:01]<osimons>=> either more tests, or some test-flag that selects the right method depending on the trac installed...
[09:02:15]<pacopablo>well, i was thinking that the solution would be more tests.
[09:02:34]<pacopablo>one set of test there multirepos what forced to False, and then another set with it forced to True
[09:02:54]<pacopablo>the problem right noww is getting the "forcing" part working right
[09:03:18]<pacopablo>I'm re-working the patch to use db schema version as the determining factor
[09:03:26]<pacopablo>that may make it easier for us to fake it
[09:07:01]<osimons>pacopablo: or abstract the get() into its own method on the testcase class to keep loc down and make it easy to change. i suppose the easiest is a check for hasattr()
[09:07:37]<osimons>oh. perhaps it will be None for Mock env...
[09:13:25]<pacopablo>ok, switching it to checking the db schema version isnt' bad
[09:13:48]<pacopablo>it also makes faking the get_version() method on the env object easy
[09:21:40]<osimons>pacopablo: it all depends on how your bitten patch looks and what changes are needed - no doubt you'll see what level of complexity is needed for acceptable coverage of old and new
[09:25:41]<pacopablo>ah, fark, now I managed to screw things up such that I'm getting the AttributeError: 'module' object has no attribute 'tests'
[09:25:44]<pacopablo>error
[09:25:48]<pacopablo>stupid unittest
[09:25:56]<pacopablo>won't tell me where my error really is
[09:30:01]<pacopablo>hahahahahaha!!!!
[09:30:19]<pacopablo>well, it really helps to be working on the RIGHT checkout of bitten
[09:30:51]<pacopablo>I had two check outs (moving from svn to git) and was making changes in both of them, thinking they were the same one
[09:31:08]<pacopablo>I was wondering why some of my changes didn't seem to be working ;)
[09:47:05]<osimons>pacopablo: fail and fail again.... the spirit of testing...
[09:48:57]<pacopablo>yeah ;)
[09:49:04]<pacopablo>so, I've got a design question
[09:49:30]<pacopablo>one thing that multirepos does or "introduces" is the concepts of a repository path
[09:49:56]<pacopablo>ie, it's not just simply a repository, it's a path that find the given repository for you
[09:50:27]<pacopablo>I see this being the build configuration path
[09:50:51]<pacopablo>however, collect_changes() takes the repository and the config
[09:51:24]<pacopablo>would it make more sense to add the repository_path to collect_changes? or simply remove the repository parameter
[09:51:35]<pacopablo>since if we have a config, we should be able to get a repository
[09:53:24]<osimons>bitten should really just use the path that includes repos - if that is what you asked
[09:54:26]<pacopablo>he, not exactly
[09:55:03]<pacopablo>currently: collect_changes(reops, config, db=None)
[09:55:07]<pacopablo>should it change to:
[09:55:18]<pacopablo>collect_changes(repos, config, repos_pathc, db=None)
[09:55:20]<pacopablo>or
[09:55:30]<pacopablo>collect_changes(config, db=None)
[09:55:53]<pacopablo>as we can get the repos based on config.path
[09:59:01]<osimons>pacopablo: you need to ask easier questions - find something i know the answer to... :-)
[10:00:00]<osimons>likely we already have a repos before calling, so at some stage in the request we need to resolve the path into (repos, repos_path) and then we ought to pass all three in
[10:00:56]<pacopablo>so, this is where multirepos makes things a little less clear
[10:01:28]<pacopablo>currently, that's pretty much correct, we load the repos, and then pass it into collect_changes
[10:01:46]<pacopablo>this works because only one repository exists
[10:02:02]<pacopablo>so it's used for all configs
[10:02:20]<pacopablo>multirepos changes this as you can have a different repos for each config
[10:02:31]<osimons>pacopablo: which may also soon switch to also be stored on the builds themselves...
[10:02:56]<osimons>ie. so that the build remember its own path in case config switches to new path later...
[10:03:05]<osimons>but yes, same difference
[10:03:31]<pacopablo>http://bitten.edgewall.org/attachment/ticket/342/t342_multi_repos.patch
[10:04:18]<pacopablo>so in web_ui.py in that patch, about line 87, I move the lookup of the repository form outside the loop, to inside the loop
[10:04:48]<pacopablo>so for each config, we get the corresponding repository (and path) and pass those into collect_changes
[10:05:24]<pacopablo>that works. I could, however, move the repository lookup into collect_changes, since all the data necessary to laod the repository is in the config
[10:06:04]<pacopablo>the net effect is the same
[10:06:53]<pacopablo>it really just changes the signature of collect_changes
[10:07:38]<pacopablo>and does reduce some duplicate code
[10:13:58]<osimons>yeah. drop the repos resolving outside collect_changes()
[10:14:07]<pacopablo>k
[10:15:08]<osimons>grep'ed and read the source - no need to pass the repos, and we don't seem to use it for anything else on the 'outside'
[10:30:56]<pacopablo>hmm, req.authname :(
[10:31:23]<pacopablo>supposedly needed for getting the repository
[10:31:51]<pacopablo>though is it really needed at this point? shouldn't this be wrapped by other perm checking?
[10:32:00]<pacopablo>ie, if they get here they have permissions?
[10:33:01]<osimons>right - it is for the authorizer... and quite important. pass authname then?
[10:34:33]<osimons>user may not be allowed to access path etc. - it will then barf when doing get_node() which it may do for a number of reasons - don't exist, no permission etc.
[10:36:27]<pacopablo>k, will pass authname then
[10:55:51]<pacopablo>Ran 235 tests in 3.786s
[10:55:51]<pacopablo>OK
[10:55:54]<pacopablo>woowoo!
[10:56:18]<pacopablo>bbiab, tiem to go fight with a DSL modem :(
[10:56:19]<osimons>superb!
[15:34:52]<evil_twin>b.e.o: Ticket #414 (Error processing a build) updated - <http://bitten.edgewall.org/ticket/414#comment:17> - schneider@…
[15:37:58]<evil_twin>b.e.o: Ticket #414 (Error processing a build) updated - <http://bitten.edgewall.org/ticket/414#comment:18> - Mike Schneider <schneider@…>
[15:57:00]<evil_twin>b.e.o: Ticket #414 (Error processing a build) updated - <http://bitten.edgewall.org/ticket/414#comment:19> - Mike Schneider <schneider@…>