You may have seen this in your new port report recently:
16 Jul 2006 http://www.FreshPorts.org/devel/p5-Class-Multimethods-Pure/ http://www.FreshPorts.org/devel/p5-Luka/ Exception handling and reporting framework
What is missing is a description for devel/p5-Class-Multimethods-Pure. It should be there. And if you click on the link provided, you’ll see it. So why doesn’t the description appear in the report?
It’s all about timing.
The following is more or less what I told one FreshPorts reader when he reported the problem to me. I’ve copied and pasted the email here because it pretty much says what I wanted to say here.
Each report knows the last time it was run. That is stored in the db. Each report includes data added to the database since the last run.
Looking at the port page, the port was added at 17 Jul 2006 01:09:59.
The cron job that generates that report runs at 1810 PST. The email headers of that cron job say “Sun, 16 Jul 2006 18:11:12 -0700 (PDT)” which means that job started about 1 second after that port was added.
The port would have been added to the database and the transaction committed. That is why it appears in the report. However, the port has not been “refreshed” (i.e. make -V) from the files. Therefore, the short description is empty.
It’s a small window but sometimes it gets caught.
The add and the refresh are done in two different transactions because the refresh process can take a long time.
The easiest way to deal with this would be to allow existing processing of commits to finish before reporting. That could be done by adding the following to the reporting scripts:
- set OFFLINE flag (All FreshPorts scripts should not run if the flag is set)
- wait for existing processes to finish (this could be a while)
- grab the list of things to report upon
- clear the offline flag
- produce the report
That is not very simple… It sounds simple, but I think waiting for existing processes to finish is a bit dodgy.
I’ve also considered sliding the reporting window. Instead of reporting upon everything since the last run, report on everything since the last report date – 10 minutes up until 10 minutes ago. This would given a port 10 minutes to get refreshed after being added. However, large commits (several hundred commits) would still
take a long time to refresh.
Now that I think upon it, it may be simplier to alter the reporting code to say “[description not available]” for those few instances (perhaps 5 or 6 times a year) that this situation occurs.
###
That’s the end of the email. This morning I made the code changes, tested them, and put them into production. Testing them is pretty simple, but threatens to spam all FreshPorts users if not done correctly. First I alter the database query so that only my user id is included in the output. Then I delete entries from the report_log table and run the report. It’s something like this:
delete from report_log where report_date > '2006-04-08 19:53:26.622607-04';
Why did I chose that date for my testing? Well, it’s the most recently added port in my copy of the FreshPorts database that I have on my laptop. How did I discover that port? With this query:
select max(date_added) from ports;
By deleting the entries from the report log, the next running of that report will include details of that newly added port.
Oh, and this is what the resulting report email looked like:
08 Apr 2006 http://www.freshports.org/devel/ruby-eet/ Ruby support for reading and writing EET files http://www.freshports.org/games/marsnomercy/ [description was not available but the link above will have full details] http://www.freshports.org/games/vdrift-data/ Vdrift driving simulation data files http://www.freshports.org/graphics/ruby-redact/ An edje compiler written in ruby
