Packaging of mailarchive module is breaking the packaging script

packaging script has failed the last four attempts with this:

ERROR: <em>mail2cms</em> does not exist after cvs export -r %tag -d <em>mail2cms</em> <em>contributions/modules/mail2cms</em>

Warning: require_once(./includes/theme.maintenance.inc): failed to open stream: No such file or directory in /var/www/drupal.org/htdocs/includes/bootstrap.inc on line 1532

Fatal error: require_once(): Failed opening required './includes/theme.maintenance.inc' (include_path='.:/usr/share/php5:/usr/share/php') in /var/www/drupal.org/htdocs/includes/bootstrap.inc on line 1532
Finished: FAILURE

we only bootstrap drupal at the beginning of the script, so the only thing i can imagine is that drush is tanking during a profile build. http://drupal.org/project/managingnews would be the profile built right after the last project in that output above, and it does have a non-standard config of having a DRUPAL-6--1 branch but having releases disabled.

killes spotted that http://drupal.org/project/mailarchive was again breaking the packaging runs. his theory is that somehow a redirect is being triggered. i have no idea how this could happen simply from running a CVS checkout of the module, then tar'ing it.

at any rate, i've disabled releases on the module for now, so that the other 5000 projects can package properly while we figure out the problem.

Fascinating. No ideas why mailarchive would cause this problem. Do the packaging scripts in any way run the php code being packaged? That seems highly unlikely...?

mailarchive_rss has a broken .info, because dependencies is not defined as an array:

; $Id: mailarchive_rss.info,v 1.1 2007/09/22 21:37:48 jeremy Exp $
name = Mail Archive RSS
description = Provide RSS feeds for mail archives.
dependencies = mailarchive
package = Mail Archive

Because of this, the experimental project_info module (from #102102: Parse project .info files: present module list and dependency information) causes the script to die:

function project_info_package_info_process($rid, array $records, array $info) {
  foreach ($info as $module => $module_info) {
    project_info_package_info_process_dependencies($rid, $records[$module], $module_info['dependencies']);
  }
}

dies when $module_info['dependencies'] is not an array because of the type-hint in the function signature:

function project_info_package_info_process_dependencies($rid, array $module, array $dependencies) {
}

Do we actually use the data from the project_info module, or can we actually kill it until it matures?

I committed a quick fix to bzr.

man, great sleuthing, DamZ!

i re-enabled releases for mailarchive and triggered a build of the branch releases for the module, no issues.

You say that this is fixed but I still see tons of modules with this July 11 date and I made a small change to one of my projects and it is still stuck...

The project is here:

http://drupal.org/project/ladybug

Not only that, the tarball offered is older than even the latest changes of June. As if the generation of the tarball was stuck in time...

Let me know if you need any additional info.

Thank you.
Alexis

the july 11th date was the repair date of the last bug in the development tarball packaging code -- most modules that haven't had a commit since then will show that creation date.

you've only had one change since july 11th, and that was less than 24 hours ago. if the package hasn't been rebuilt in 24 more hours, set this to active again and i'll have a look at the issue

Hi Hunmonk,

I thought the amount of time was 12h... But anyway, it is still Jul 11 today... Since the 14th... You know...

There are a couple other module that, even if I update they still show in yellow and they both have Jul 11 as their last changes date:

http://drupal.org/project/captcha_pack
http://drupal.org/project/recaptcha

I do not know, however, whether they made changes since then.

Thank you.
Alexis

use the 'View CVS messages' link on the project pages to find out when a project last had a commit.

no idea why your dev tarball isn't being rebuilt. i tried firing off the packaging manually, but it still skipped it. in the end i deleted the old tarball and ran the packaging manually again, and it finally behaved:

http://drupal.org/node/824706

looking more closely at the 6.x-1.x-dev release node, this was the creation time for it: June 11, 2010 - 02:18. that was right during the middle of when we were recovering from that dev tarball bug -- it's possible that creating the release node during that time is what caused the issue.

hunmonk,

Thank you for looking into this...

I hate to be an annoyance, but there is another problem. The package was indeed regenerated, but somehow, it still uses old versions of the source files.

The main example is in template.php

The new file (version 1.4) can be seen here:

http://drupalcode.org/viewvc/drupal/contributions/themes/ladybug/templat...

and we see this statement

drupal_add_js(drupal_get_path('theme', 'ladybug') . '/scripts/jquery.pngFix.js'); 

When you look in the tarball, the statement is the old one (version 1.1)

drupal_add_js('scripts/jquery.pngFix.js');

I think I heard of problems like that with CVS. Maybe the directory where you check out files needs to be cleaned up (although I would think you already do that?)

Anyway, the date is fixed, but not the content...

Thank you.
Alexis

now i see your original problem -- the packaging script was not broken in this case, just your understanding of it... ;)

look carefully at your 6.x-1.x-dev release -- it's built against the DRUPAL-6--1 branch, and you're committing fixes to the HEAD branch.

Is this fixed? I'm still waiting for http://drupal.org/node/924022 to be packaged (which isn't a dev release) - it's been quite some time now...

Pobster

http://drupal.org/node/924022 has a package, as far as I can see.

The package doesn't seem to exist.

"Not Found

The requested URL /files/projects/cache_converter-6.x-1.0.tar.gz was not found on this server.

Apache Server at ftp.drupal.org Port 80"

Hmm... Maybe this issue is unrelated then?

Pobster

As the page reports the MD5 hash, I would guess the archive has been created. The fact the link to the archive doesn't work could be a signal of another problem in the packaging script (as well as a signal of a completely different problem).

Ah that is a good point if it has a hash then it *was* created. I'm assuming that it must package it on the D.org server then transfer it over to OSUs ftp server. I guess simply the transfer failed?...

Pobster

See #924098: Package links return error 404.
It seems the problem is not related with this issue; the packaging script creates the archive, but the archive seems to not be copied to its final destination.

Ah excellent, thank you.

Pobster

this issue has been fixed for a long time. please stop using it to report other issues with the packaging system -- open new issues!

also, #924098-3: Package links return error 404

Apologies, as you can probably tell from my posts, I assumed it was related.

Pobster