Patches on contrib projects fail testing with "Drupal installation failed".
In the review log: (during execution of "drush si")
PHP Fatal error: Cannot redeclare system_requirements() (previously declared in /var/lib/drupaltestbot/sites/default/files/checkout/modules/system/system.install:11) in /var/lib/drupaltestbot/sites/default/files/checkout/sites/default/modules/rebuild/tests/fixtures/drupal_sites/dev/modules/system/system.install on line 518

Reported occurrences across various contrib projects so far (up until comment #12 below) :
https://qa.drupal.org/pifr/test/766528
https://qa.drupal.org/pifr/test/230468
https://qa.drupal.org/pifr/test/908703
https://qa.drupal.org/pifr/test/643243
https://qa.drupal.org/pifr/test/908198
https://qa.drupal.org/pifr/test/907473
https://qa.drupal.org/pifr/test/909348
https://qa.drupal.org/pifr/test/909218 on #2463
https://qa.drupal.org/pifr/test/910108 on #2448
All of the above occurred on test clients #2443, #2448 & #2463

Comments

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented
Issue summary: View changes
mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented

also happening here #951004: Allow selecting of multiple media items for a multi value media field in the same dialog.

almaudoh’s picture

almaudoh commented

I'm also having this issue at https://qa.drupal.org/pifr/test/230468. At first, I thought it was a random testbot failure, so I made another commit to trigger a test, but still the error persists.

It has stalled tests on smsframework 7.x-1.x branch. Can we fix this?

yched’s picture

yched commented
Priority: Normal » Critical

Seen this on scald issue queues too - all patches fail with :

PHP Fatal error: Cannot redeclare system_requirements() (previously declared in /var/lib/drupaltestbot/sites/default/files/checkout/modules/system/system.install:11) in /var/lib/drupaltestbot/sites/default/files/checkout/sites/default/modules/rebuild/tests/fixtures/drupal_sites/dev/modules/system/system.install on line 518

Dunno how many queues that affects, or whether this is only for a couple test clients (all reports so far seem to only involve test clients #2448 & #2463), but this sounds pretty critical :-/

rjacobs’s picture

rjacobs commented

I'm seeing this repeatedly in the last couple days as well. Here's one reference: https://qa.drupal.org/pifr/test/908703 (same errors as noted in the comments above). As the error takes place during the installation of the testing instance (before the test-specific tasks are run) it certainly seems like a problem that's independent of the project/patch tested.

I don't mean to be posting another "me too" comment, but I'm hopeful that some patterns from specific examples of failing test results is useful. I can't see from the results which test client was used in my case (maybe I'm missing something obvious within the logs), but there must be some handy info in there?

toddy’s picture

toddy commented

I can confirm this PHP fatal error during installation of Drupal, at least since yesterday (2014-11-16). The tests ran (after scheduling a retest) on clients #2448 and #2463.

UPDATE: The test also failed on test client #2443.

https://qa.drupal.org/pifr/test/643243

yched’s picture

yched commented
Issue summary: View changes

Cleaned the issue summary a bit and consolidated the reports so far.

toddy’s picture

toddy commented
Issue summary: View changes

Added test client #2443 to the issue summary.

pieterdc’s picture

pieterdc
Primary language Dutch
Location Ghent
commented
Issue summary: View changes

Reported https://qa.drupal.org/pifr/test/909348

jonathan1055’s picture

jonathan1055 commented

Another failure https://qa.drupal.org/pifr/test/909218 - client #2463

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented

There's actually a rebuild module:

https://www.drupal.org/project/rebuild

The latest commit was right before I reported the first failure. Since that module has automated tests, it probably scheduled a new test after the push (Nov 13).

Maybe a test ran for the Rebuild module, and that test client is not cleaning up? That's why only certain test clients are affected?

The module stores a copy of Drupal:

http://cgit.drupalcode.org/rebuild/tree/tests/fixtures/drupal_sites/dev

jonathan1055’s picture

jonathan1055 commented
Issue summary: View changes

Thanks djdevin that useful and interesting. How do we go about getting the affected clients cleaned up?

Meanwhile, here is a another just now https://qa.drupal.org/pifr/test/910108 on client #2448

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented

I can't do anything unfortunately, asked for help in IRC.

isntall’s picture

isntall commented

I'm going to rebuild the MySQL testbots.

isntall’s picture

isntall commented

New bots have been created. Let us know if the issue persists.

rjacobs’s picture

rjacobs commented

Hummm, it still appears to be an issue. Here's a test result from a re-test I just triggered since comment #15:
https://qa.drupal.org/pifr/test/908703

Looks like that was on client 2508. I can see there there are other recent failures on that client as well (again since comment #15) from other projects. Interestingly though some tests on that same client are working.

My example was a re-test (same test ID). Do I need to try with a brand new patch to test things out properly?

pieterdc’s picture

pieterdc
Primary language Dutch
Location Ghent
commented

I also just triggered a re-test, still fails and also got the same test ID: https://qa.drupal.org/pifr/test/909348

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented

Same here https://qa.drupal.org/pifr/test/766528

That "Rebuild" module keeps being downloaded. Why? Something seems strange with the dependency build. "Quizz" is not a dependency either. Since "Rebuild" contains a copy of Drupal, maybe the dependency map is attempting to download that. Technically it's a fork of Drupal so it's probably being marked as a valid dependency for a core module. That's what is probably happening in this other case with "Quizz" as the fork contains the same module namespace. Quiz depends on the "filter" module so that's probably pulling "rebuild" from the dependency map, since filter.module exists there.

Somewhat similar to #2378459: Forked module with same .module file breaks testbot which is broken because of a fork.

          [dependencies] => Array
                (
                    [1] => Array
                        (
                            [repository] => Array
                                (
                                    [type] => git
                                    [url] => git://git.drupal.org/project/rebuild.git
                                )

                            [vcs_identifier] => 7.x-1.x
                        )

                    [3] => Array
                        (
                            [repository] => Array
                                (
                                    [type] => git
                                    [url] => git://git.drupal.org/project/quizz.git
                                )

                            [vcs_identifier] => 7.x-6.x
                        )
mpotter’s picture

mpotter commented

Also seeing it trying to run tests in Features for this issue: https://www.drupal.org/node/2378343

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented

Makes sense, as features_tests has a hard dependency on "image" - thus bringing in the module that provides it!

brad.bulger’s picture

brad.bulger commented

Same problem in a new patch test for og_vocab - https://qa.drupal.org/pifr/test/911338
Issue #2379169: empty theme value in og_vocab_element_after_build() causes error

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented
Title: PHP Fatal error: Cannot redeclare system_requirements() » Dependency on core module results in PHP Fatal error: Cannot redeclare system_requirements()

Updating title as we know what the issue is now.

isntall’s picture

isntall commented
Assigned: Unassigned » isntall
Status: Active » Needs review

I think this issue has been tracked down and resolved.

To recap:

There was the dependency 'rebuild' that satisfied the requirement of getting a copy of core.
There is an array of projects that shouldn't be dependency 'project_dependency_excluded_dependencies' and rebuild was not it.
The rebuild project is now in that array.

rjacobs’s picture

rjacobs commented

Yep! Two of my previously failing tests have now passed, and the "rebuild" dependency (that was mysteriously added before) is no longer appearing in the related test logs. Looks like the dependency exclusion was the key.

jonathan1055’s picture

jonathan1055 commented

All my failing tests have now re-run and passed. Thank you isntall, djdevin and everyone for investigating and fixing.

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented
Status: Needs review » Reviewed & tested by the community

Thanks, green here too: https://qa.drupal.org/pifr/test/350828

I'd say RTBC

toddy’s picture

toddy commented

The tests of my module are passing now, too. Thanks a lot!
https://qa.drupal.org/pifr/test/643243

almaudoh’s picture

almaudoh commented

RTBC+1. Re-ran SMS Framework 7.x-1.x-dev branch tests and it passed. Thanks!!

proofoftom’s picture

proofoftom commented
Status: Reviewed & tested by the community » Fixed

It seems as if all tests are running now as it's been 3 weeks since any reports. Marking issue as fixed. Thanks isntall and everyone else for helping resolve this!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.