Closed (fixed)
Project:
Project
Version:
6.x-1.x-dev
Component:
Releases
Priority:
Critical
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
21 Feb 2009 at 01:04 UTC
Updated:
3 Jan 2014 at 00:07 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dwwUhh, wow:
http://drupal.org/node/335174
That's one borked release node. ;) I wonder how that happened. I'll debug in a little while, I'm in the middle of something else.
Comment #2
dwwYikes.
A) package-release-nodes.php is inserting new records into the {files} and {project_release_file} tables whenever a -dev snapshot is regenerated, instead of just updating the existing record in those tables. :( This is a bug from #366448: Port packaging script to new {project_release_file} schema
B) (Known bug, but causing the pain here) project-release-create-history.php doesn't know what to do with release nodes that have multiple files in {project_release_file} yet. So, it's confused and adds all the files as if they were separate releases. Since it's doing them in fid order, it gets the oldest files first, which is why you're never seeing the date change.
There are currently 130 release nodes that have more than 1 file in {project_release_file} as a result of this bug. :( I just disabled the repackaging of -dev release nodes for now until I sort out these bugs. Unfortunately, I have to leave in a few minutes, so I probably won't have this fixed and the DB repaired tonight. Hopefully sometime tomorrow.
Comment #3
avpadernoI really thought that was how the new project system worked on Drupal 6. I didn't understand why such thing would be desired, but I thought it could be useful. :-)
Comment #4
dwwOk, I deployed a quick fix for (B) and re-ran the script to generate the XML release history files. Can you confirm that at least you're seeing the most recent date now?
Comment #5
dwwOk, I wrote, tested, committed, and deployed a fix for (A), too. Packaging -dev snapshots is enabled again.
All that's left is cleaning up the extra entries in {files} and {project_release_file}. That's not quite so urgent, so I'm going to downgrade the priority and leave this for the night and go play my gig. ;)
Comment #6
avpadernoI am still seeing wrong dates. I re-run the checking, but I get this report:
I also emptied the cache table used for the update informations (cache_update table), but that doesn't change.
It seems I am not the only to have this problem, as there is a person who keeps to say there aren't updates of XML Sitemap modules.
Comment #7
dwwYeah, my "fix" in #4 ensured we only had one entry in the XML release history files for each release node, but it was always using the oldest fid, not the newest. :( Anyway, I wrote a little script to clean out the DB of the stale duplicate records, and ran it. I also reverted the change from #4 since it wasn't really helping (and is unnecessary now that the DB is fixed). I just regenerated all the history files -- things look right now to my eyes. So, given that the packaging script is working properly now, the DB is clean, and the release history generating script is doing the right thing, I'm marking this fixed.
Comment #8
dwwOh, for the record (and in case anyone else needs it) here's that repair script.
Comment #9
jcmarco commentedI confirm that remote status update is working fine.
Thanks
Comment #10
avpadernoIt is working again.
Thanks to dww for his fixing task.
Comment #11
avpadernoI don't know if it's the same cause, but the Available updates page still doesn't report the latest versions of a module. This time happen with a different module (http://drupal.org/project/dul); the page doesn't show there is a 6.x-1.0 version.
Comment #12
dwwAlmost certainly due to #184418: update(_status) results stale for up to 6 hours.
Comment #13
avpadernoThanks again, dww.