The package system on adds some additional information to the info files contained in the modules when dowloading the from the site which looks like:

; Information added by packaging script on 2012-05-22
version = "7.x-2.0-alpha2+2-dev"
core = "7.x"
project = "libraries"
datestamp = "1337646472"

This additional information breaks the libraries_info() test. Unsetting the four entries by applying the attached patch the test will also be successful when the module is downloaded from

#5 libraries_info_test_drupal_org-gitdiff.patch680 byteschemical
PASSED: [[SimpleTest]]: [MySQL] 135 pass(es). View
libraries_info_test_drupal_org.patch609 byteschemical
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch libraries_info_test_drupal_org_0.patch. Unable to apply patch. See the log in the details link for more information. View


sun’s picture

Version: 7.x-2.0-alpha2 » 7.x-2.x-dev
Priority: Major » Minor
Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, libraries_info_test_drupal_org.patch, failed testing.

tstoeckler’s picture

I opened #1606606: release packager corrupts info files that are not modules, themes, or install profiles over in drupalorg.module for the packaging problem. I'll add a short comment to explain the problem and a @see to that issue pre-commit.
...unless you feel like re-rolling for that which would be super-awesome! :)

sun’s picture

As the testbot proves, I don't think that this patch here will fly at all, because it removes the 'version' property.

Perhaps we should split this specific test out into a separate test case and use checkRequirements() to verify that we're dealing with a git clone/checkout and the .info file has not been tampered with.

But then again, perhaps that's not worth the effort... who's running tests on non-git-clones in the first place? :P

chemical’s picture

680 bytes
PASSED: [[SimpleTest]]: [MySQL] 135 pass(es). View

My previous patch was generated with 'diff' and not 'git diff' so the path was missing a slash. I have made a new patch which can be applied with 'git apply'.

The four entries are not present in the variable $library in the test of libraries_info() when running a git-cloned version of the module. Unsetting the four entries when not present has no effect but will make the test work when fetched from as a package. Maybe libraries_info() should unset the entries to counter the packaging problem.

@sun: If tests not necessarily are successful when a module is fetched as package from, how do I know that the module is working as expected when fetched as a package? When you do automated testing every time you change a file you test again — actually all modules on should be tested again after the transformation by Drupal's packaging system because the code is being modified.

tstoeckler’s picture

Status: Needs work » Needs review

Re @sun/#4: The info file itself doesn't have a version property, so unsetting shouldn't be a problem.

Maybe we should just call this fixed and wait for the drupalorg issue to be resolved.

Setting to needs review to see if the tests pass.

tstoeckler’s picture

Status: Needs review » Fixed

Decided to commit this, to get it out of the way. Can't hurt IMO.
I added a little comment. The diff is here:

Status: Fixed » Closed (fixed)

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