Packaging script incorrectly removes -dev tarballs when there's no new code to package

Same here. Drush reports a MD5 checksum error though in reality is a 404 issue. The page cannot be found. If I download the recommended release instead of dev everything works ok.

I can confirm the issue. It's not a problem with the FTP server, or DNS because it only happens with the development snapshots, not with the official releases.

I tried to download CCK 6.x-2.7, and I was able to download it; when I tried to download the development snapshot for Drupal 6, I got an error 404 page. The page was not from Drupal, though.

There were some project* and solr changes pushed live last night. Attached are the project changes. I'll look around for relevant logs.

Whitespace ignored

With whitespace ignored.

Hm. D'oh.

The current packaging script will call cleanup_failed_build() as soon as the build failed, and cleanup_failed_build() returns FALSE when a -dev build doesn't have to be regenerated.

there was a cleanup_failed_build() function added to the packaging script, which is supposed to remove tarballs in the event that the build fails. it tested out fine on scratch, and it's pretty simple logic, but it's the only thing i see in here that could be causing the problem.

Subscribing...

I committed the following in the drupal.org repository as a quick-fix. Reassigning to Project to discuss an eventual better fix.

=== modified file 'sites/all/modules/project/release/package-release-nodes.php'
--- sites/all/modules/project/release/package-release-nodes.php	2010-07-10 05:17:36 +0000
+++ sites/all/modules/project/release/package-release-nodes.php	2010-07-10 22:46:51 +0000
@@ -351,7 +351,7 @@
   if ($type == 'branch' && $tgz_exists && filectime($full_dest_tgz) + 300 > $youngest) {
     // The existing tarball for this release is newer than the youngest
     // file in the directory, we're done.
-    return false;
+    return true;
   }
 
   // Update any .info files with packaging metadata.

Yes, #777068: profile-only release tarballs not cleaned up if other tarballs fail to build was done wrong. It was causing the -dev tarballs to churn -- every other packaging run deleted the "failed" build. ;)

The logic was supposed to only happen on profile packages, but it's happening on all contribs.

Furthermore, the logic is wrong. DamZ's quick fix is sort of the right approach, but I think it might create other problems. I think we're going to need more than true/false return values here...

Sorry to dirty up an issue that is way over my head, but does this mean the missing dev's will be available again at some point tonight. Or, will the maintainers need to re-upload their dev releases?

@Poieo: The missing -dev are being rebuilt as I write this. It's up to the modules beginning with the letter "o". ;) No, you don't have to do anything (and any attempt to "fix" this by module maintainers would almost certainly make things worse).

Re the return values -- the script really needs to know the difference between "i did useful work that needs to be updated into the release node", "I didn't do anything", and "I hit errors". So, instead of trying to return TRUE/FALSE, we should really just return 'success', 'no-op', and 'error'. Then, the code is fully self-documenting and we can properly handle all 3 cases correctly.

(Better title to reflect the actual nature of this bug)

attached patch should fix the problem in a more robust fashion, using the logic three string values dww proposed in #14

No where the dev tarballs are being rebuilt, they *all* are dated 2010-Jul-10 even if they are in fact very old, causing the update module on Drupal installations pinging for "new releases available" for all modules and themes that you have running at a dev version...

roball: nothing we can do about that...

Patch #16 looks exactly like what I was proposing. I haven't tested it, but visually that's the right fix.

subscribe

tested the patch in #16 thoroughly in a local environment, committed to 6.x-1.x-dev, deployed on drupal.org

sound likes "it's fixed"

can you pls comment as to what end-users should now see/do?

after

drush cc all
drush ref

@ drush up/dl i'm still getting " ... is corrupt (wrong md5 checksum)" errors.

still need to wait for something to propagate?

Can dev tarballs be restored from backup? That filedate is actually kind of important information. I guess doing so is probably more pain than it is worth, but...ugh. I know I personally like to compare -dev filedates to release filedates to guess if there's been recent activity, and now that information could be wrong. Vastly wrong in some cases.

Hmm. CTools (which begins with C) does not have the -dev tarball restored. My reading is that they should all be regenerated by now?

I am experiencing the tarballs missing for views_bulk_operations and uc_views

Me too - there are still missing dev tarballs, eg. http://ftp.drupal.org/files/projects/at_koda-6.x-1.x-dev.tar.gz (#850394: at_koda-6.x-1.x-dev.tar.gz download link 404). Those projects are affected really critical since they do not have an official release yet and have thus no tarball to download from the project site at all!

hunmonk deployed the fix, but it doesn't look like the every 12-hours packaging run happened yet.

I'm running the script manually again now. Once that finishes, I'll run it again to make sure the bug is actually gone. ;)

Stay tuned...

"Done packaging releases from branches: 9258 built, 9585 considered."

The rsync to ftp.drupal.org should be done by now.

All the release history XML files are being regenerated now. It's taking a long time, since this is the worst case -- basically it has to regenerate the history for all 5000 contribs. :( It's 1:36am here, so I need to sleep. I'll take a look at this first thing in the morning and see if the release history is cool, and make sure that the tarballs aren't needlessly rebuilt when the script runs again.

Thanks to those that stayed late to work this out! Your fellow Drupal peeps appreciate what you do!

Drush is reporting an invalid checksum when issuing the command -drush dl views_bulk_operations-6.x-3.x-dev.tar.gz

subscribe

http://drupal.org/node/850786

I hate posting this in the general forum instead of issue ques because I cant see the responses when I click on "My issues"

However, I awoke as I normally do to find out that the "Available Updates" was really crazy today. I update everyday, but today found 40 of my modules had available updates on the same day? Thats crazy.

When I downloaded them many were only 1k big, and gave rar errors.

Any ideas?

You know, with something so huge as this dont you think someone should post this info on the front page of drupal so everyone knows whats up?

Why even have to ask about it? It seems like a pretty important issue. Would have saved me a lot of time from downloading 40 modules.

#850724: http://ftp.drupal.org/files/projects/location-6.x-3.x-dev.tar.gz not found is a duplicate of this issue. ... and is still a problem, but #28 looks like it might resolve itself in time.

@All: Stuff happens. Please relax. If you use -dev modules, it's the Wild West, and crazy things can happen. That's one of many reasons why it's so discouraged to rely on -dev. No, I don't think this bug is worthy of front page news. -dev is fragile, and unstable. Get over it. ;)

The http://ftp.drupal.org/files/projects/location-6.x-3.x-dev.tar.gz tarball is working fine for me.

I just re-ran the packaging script and it did exactly what it's supposed to. It ignored most -dev, and the ones it rebuilt I did some spot checking and the maintainer had in fact committed some changes.

Yes, it's a hassle that all the tarball datestamps are wrong. To that end, we're considering restoring them all from backup, then re-running packaging to re-generate anything that happened since the backup. However, that's going to take a while. And, while it's happening, update status is going to be really confused, too. If we do it, it'll be later this afternoon (after the World Cup Final!). ;) Right now, a full backup is running, so that's going to take probably over an hour itself.

Why not changing the drupal.org packaging script to set the value of datestamp (into the .info files) to the date of the last CVS commit instead of the current time?

@roball: Because that'd be wrong. The file metadata should match the files themselves. Plus, the .info files are only a tiny part of the problem here. We also need the datestamp in the {files} table for these files, so that things are propagated to the release history XML files, etc, etc.

The script could also set the file's last-modified timestamp to that date.

I should have reiterated: "I have better things to do than worry about how -dev behaves in update status". ;) It's a mess. -dev sucks. Get over it.

Just like nearly 2 years using drupal for me and dev fixes a lot of my problems all the time so its always first in my workflow.... Scary to see the hearbeat of drupal quiver.... ok as long as it works again. I dont care anything about football . Drupal is much better.

ok I still have a problem using --- reports ---- available updates..... I can still see every dev with an update... any idea?

I'm still getting the error with my D6 -devs, D7 -devs are ok, should I commit a small change to trigger a rebuild for the D6's, fyi these all start with "a".

@Jeff Burnz: Please provide specific links that don't work -- I don't have time to go hunting and guessing which links you're trying. ;)

@All: nnewton was worried about the restore from backup, and given that it'd require a bunch of extra work to make that all possible (it's not as simple as re-running the packaging script, after all), we aborted the plan to restore the old -dev tarballs. So yeah, if you have a lot of -dev, update status is going to be telling you to update.

Jeff - another workaround would be to just release an alpha version, wouldn't it?

#43

Every dev version I have says there is an update available, even some releases recommending dev over stable when I click on reports--available updates... i think that is what he means. When downloading these 1k rar files they are not truly updates.

So I cant get any updates for drupal for 2 days.

I have marked #851298: Available update report, all dev versions dated 2010-Jul-11 as duplicate of this report.

CAn you tell me is the dev system for upgrading modules now pernamently dead? What is the suggested new way to get module updates?

In re #35: I understand your points about development packages, but disagree about your conclusion about notifying the Drupal community. I think *some* kind of note or announcement in a prominent place should be made.

Like it or not, there are MANY websites that use development modules that are affected by this, and to bury this in a forum is disrespectful of all the people who manage those sites.

absolutely.. dev has been recommended under some updated modules even...

Re #47: No, it's not permanently dead. If you "upgrade", then it'll be working again if new -devs are packaged from here on out. Just pretend like every module you're using actually had a commit on July 11th, which is certainly possible.

People who think it is a good idea to use dev-releases on live sites will now hopefully know better why this is not recommended.

There's nothing to do here.

#51 you are quite wrong. There are several modules were dev releases are recommended. This is not an individual module issue. This is a drupal project dostrobution issue.

#50 So you are saying, if there is a new dev released for all of these modules which are listed with july 11th dates, and the release is newer than July 11th, we will no longer see July 11th as the updated date?

@AntiNSA: As I said, just pretend every module on drupal.org had a commit on July 11th. So, all the tarballs were rebuilt. Everything works like it always did. If someone commits again on July 12th, the tarball is rebuilt and update status will tell you that the July 12th copy is the most recent.

ok thanks I now understand.

@Gerhard: In an ideal world, yes. Unfortunately, there are far too many maintainers who put up interesting and useful modules on drupal.org and then let them languish in development without so much as an alpha forever. Or fix bugs in the dev of a stable release and then go years without another release. So the fact is that many people do use dev versions not because they are stupid but because poor maintenance doesn't leave them much choice.

The flip side of that is that there are some dev snapshots that are very good. I often run the dev snapshots of cck/views/panels/ctools because they are rarely broken. I take care, of course, when upgrading from dev to dev because even they make mistakes now and then but, on the whole, they are quite usable.

Michelle

@Gerhard: Michelle has stated this more eloquently than I could have. +1 Michelle

David

subscribe,

We can deal with this problem until a fix. It's a little confusing but it's easy to know what the real new dev version of modules are.

Meanwhile, It's very annoying for new drupal users that built their website from start.

There are several modules were dev releases are recommended.

no, the dev release can't be recommended, it is not possible..

Michelle: The dev release could be quite usable, but the stable release is more stable than development release, by definition.

If you want a stable release, then create an issue in that module's issue queue..
this issue is fixed.

@Pasqualle

I'm not agree with you at all.

You CAN'T make a complete website with only recommended version. It's impossible. You have to use dev. version.

As Michelle said

"many people do use dev versions because poor maintenance doesn't leave them much choice."

Poor maintenance, it's not a choice for some modules. The problem of compatibility between modules is inevitable. Maintainers can't always make a recommended release after each bug.
It's something we had learned to deal with.

> no, the dev release can't be recommended, it is not possible..

well ...

drush pm-releases `drush pm-list | cut -d "(" -f 2 | cut -d ")" -f 1` | grep -i recom | grep dev
varnish 6.x-1.x-dev 2010-Jul-11 Supported, Recommended, Development, Installed
contact 6.x-2.x-dev 2010-Jul-11 Supported, Recommended, Development
devel 6.x-1.20 2010-Apr-21 Supported, Recommended
devel_themer 6.x-1.x-dev 2010-Jul-11 Supported, Recommended, Development, Installed
expire 6.x-1.x-dev 2010-Jul-11 Supported, Recommended, Development, Installed
dialog 6.x-1.x-dev 2010-Jul-11 Supported, Recommended, Development, Installed

#60 theres more too :) Its all good though... everything is working again. let it go guys.. this cant be the thread about evil dev's :)

@ 61: I'd let this drop, too--Gladly. I just wish that open lines of communication could be encouraged in the Drupal community, instead of finger pointing.

It appears to me like someone committed code prematurely (with substantial impact across the Drupal community), and then, instead of owning to that fact openly, they hoped that the problem would go away. So, instead of an announcement placed prominently on the site advising the community of users that an error was made to the core Drupal website and that the inconvenience is unavoidable, we get a thread under the Drupal issue queue in which the user community is harangued and made to seem like it is the problem (cf. #35, 39 and 51).

I agree. It's not about pointing fingers but about solving the issue instead of blaming someone because "he/she doesn't know better" than use dev versions.

Owning the problem is the first step towards solving it.

The problem *has been* fixed, and a decision has been reached. This thread is now locked.

[edited to increase politeness]