There seem to be two concerns here - how to get
mytestbuild working again - and how to get
regen.sh to work.
The quickfix is to drop the table
The more general fix is to put your codebase to a pristine state (e.g. no local changes/patches; check out the official upstream branch;
git scan status may help). Then you can create a pristine DB using one of these commands:
civibuild restore mytestbuild - This is faster -- it loads a SQL snapshot from the last time you ran
civibuild reinstall mytestbuild - This is slower -- it drops the Drupal+Civi databases, deletes any config files, and recreates them.
This appears to be a regression affecting
regen.sh. To determine this, I did a few things:
- Checkout the latest code from
master and run regen.sh. See the same problem.
- Clear out uncommitted changes (e.g.
git checkout -- sql/civicrm_generated.mysql)
- Repeat above, but checkout tag
4.7.0 instead of branch
master. (When jumping among different versions, I usually use
./bin/givi checkout <TAG> because that checks out corresponding tags in
drupal/, etc. The need to )
After spot-checking a few tags, I determined the problem arose somewhere after 4.7.0 and before 4.7.2. Since the context involves
bin/ and the error involves
CRM/Utils/System, we can make an educated guess that there was a change in one of those folders and skim the log:
git log 4.7.0..4.7.2 bin/
git log 4.7.0..4.7.2 CRM/Utils/System
git log -p 4.7.0..4.7.2 bin/
git log -p 4.7.0..4.7.2 CRM/Utils/System
I'm pretty sure that the regression occurred due to https://github.com/civicrm/civicrm-core/commit/40d5632a25086d7c963538f2b6daf2a2546e16a6 ; undoing that patch allows
regen.sh to run, but you'd need to read/think a bit more figure out a proper fix.