Here's some minor code cleanups for generic_stage_target and stage2_target. In stage2_target, I removed set_root_path(), since it was copied from stage1_target, and it was just plain wrong for stage2. I also removed set_source_path() because it was functionally equivalent to the in generic_stage_target, except it used seedcache without checking to make sure it was in self.settings. In generic_stage_target, I just removed a few duplicated lines of code in set_source_path(). I'm running a full stage build now with my patch applied to the latest released catalyst. It's only on stage1, but I don't foresee problems.
Created attachment 102504 [details, diff] cleanup patch
Weird. When I got up this morning, the catalyst run was "stuck" on stage2. I killed it and checked the log. This is where it was: * System has been bootstrapped already! * If you re-bootstrap the system, you must complete the entire bootstrap process * otherwise you will have a broken system. * Press enter to continue or CTRL+C to abort ... Okay, it looks like it was pulling from /var/tmp/catalyst/tmp/default/stage1-i686-2007.0_pre/ instead of /var/tmp/catalyst/tmp/default/stage1-i686-2007.0_pre/tmp/stage1root/ like it's supposed to. Instead of removing set_source_path() in stage2_target(), I'll fix it to check SEEDCACHE.
Created attachment 102539 [details, diff] new patch This new patch still does a bit of cleanup while still fixing things. I copied set_source_path() from generic_stage_target() and hard-coded /tmp/stage1root/ onto the end of the path instead of bastardizing self.settings["root_path"] for the job like was previously done before. It was essentially still hard-coded before, just in a dumb way :) I tested it as far as running 'catalyst -a -f -p /tmp/stage2.spec'. It rsync'd from the proper place and started bootstrapping.
Added to SVN
Fixed in 2.0.1
