Sanity test failure reports no problem

Late yesterday, I noticed a couple of sanity test failures. What was interesting about these reports was the lack of an error message. I emailed the committer to let them know I was looking into it.

There were two failures. The first against devel/aunit; the second against devel/florist-gpl.

By the time you read this, the above sanity test failures may not contain the original messages. I will include one of them here, for the record:

devel/aunit:

This command (FreshPorts code 2):

make -V PORTNAME -V PKGNAME -V DESCR -V CATEGORIES -V PORTVERSION -V
PORTREVISION -V COMMENT -V COMMENTFILE -V MAINTAINER -V EXTRACT_SUFX -V
BUILD_DEPENDS -V RUN_DEPENDS -V LIB_DEPENDS -V FORBIDDEN -V BROKEN -V
DEPRECATED -V IGNORE -V MASTER_PORT -V LATEST_LINK -V NO_LATEST_LINK -V
NO_PACKAGE -V PKGNAMEPREFIX -V PKGNAMESUFFIX -V PORTEPOCH -V RESTRICTED -V
NO_CDROM -V EXPIRATION_DATE -V IS_INTERACTIVE -V ONLY_FOR_ARCHS -V
NOT_FOR_ARCHS -f /usr/home/dan/ports/devel/aunit/Makefile
DISTDIR=/usr/ports/distfiles PORTSDIR=/usr/home/dan/ports
LOCALBASE=/nonexistentlocal X11BASE=/nonexistentx
2>/tmp/FreshPorts.devel.aunit.make-error.2007.10.23.22.47.4.41649

produced this error:

Checking the logs for those commits, I found these messages:

“/usr/home/dan/ports/devel/aunit/Makefile”, line 33: Unassociated shell command “${ECHO_MSG} ${IGNORE}”
make: fatal errors encountered — cannot continue

and

“/usr/home/dan/ports/devel/florist-gpl/Makefile”, line 35: Unassociated shell command “${ECHO_MSG} ${IGNORE}”
make: fatal errors encountered — cannot continue

There were three places in the code which can generate that particular message in the report:

I grep’d the code for “produced this error” and found three instances. I ruled one out because it was in the category code. The other two were in the port code. The key part of the report is “(FreshPorts code 2)”. A grep for that yielded a single result. That narrowed down the code.

I found a few problems:

1. The code was not displaying the error message (this we knew already).
2. The code was reporting the wrong make command.
3. The code was not properly catching the error message.

After making my code changes, I reran the commit, only to find a relational integrity problem with the database:

$ perl load_xml_into_db.pl ~/FreshPorts/freshports.org/msgs/FreeBSD/recent/2007.10.24.02.47.00.32798.txt.xml -O > loading.txt
DBD::Pg::st execute failed: ERROR: update or delete on table “commit_log” violates foreign key constraint “sanity_test_failures_commit_log_id_fkey” on table “sanity_test_failures”
DETAIL: Key (id)=(278079) is still referenced from table “sanity_test_failures”.
Could not execute SQL delete from commit_log where message_id = ‘200710240246.l9O2kkEn053925@repoman.freebsd.org’ DBI::db=HASH(0x8550758)->err

Oh. Ummm, OK. That is the wrong type of foreign key relationship. The sanity test table looks like this:

CREATE TABLE sanity_test_failures
(
  id serial NOT NULL,
  commit_log_id integer NOT NULL,
  message text NOT NULL,
  CONSTRAINT sanity_test_failures_pkey PRIMARY KEY (id),
  CONSTRAINT sanity_test_failures_commit_log_id_fkey FOREIGN KEY (commit_log_id)
      REFERENCES commit_log (id) MATCH SIMPLE
      ON UPDATE RESTRICT ON DELETE CASCADE
) 
WITHOUT OIDS;

The change was easy:

ALTER TABLE sanity_test_failures DROP CONSTRAINT sanity_test_failures_commit_log_id_fkey;

ALTER TABLE sanity_test_failures
  ADD CONSTRAINT sanity_test_failures_commit_log_id_fkey FOREIGN KEY (commit_log_id)
      REFERENCES commit_log (id) MATCH SIMPLE
      ON UPDATE RESTRICT ON DELETE CASCADE;

Here’s a plug for pgAdmin. The above statement was produced (mostly) by pgAdmin. When you click on the constraint, pgAdmin will display the DDL (aka SQL code) required to create the constraint. I simply altered CASCADE to DELETE. pgAdmin also provides the DROP CONSTRAINT, safely commented out, just in case. I use pgAdmin quite a bit for inspecting databases.

Now that the relational integrity is fixed, I was able to load the commit. The proper error message was produced. BONUS!

The error could be produced manually:

[dan@ngaio:~/ports/devel/aunit] $ make master-sites-all -f /usr/home/dan/ports/devel/aunit/Makefile PORTSDIR=/usr/home/dan/ports LOCALBASE=/nonexistentlocal X11BASE=/nonexistentx
“/usr/home/dan/ports/devel/aunit/Makefile”, line 33: Unassociated shell command “${ECHO_MSG} ${IGNORE}”
make: fatal errors encountered — cannot continue
[dan@ngaio:~/ports/devel/aunit] $

However, the code was still reporting the wrong command. Instead of the master-sites-all command, it was reporting the main make -V PORTNAME -V PKGNAME -V DESCR … command. This was a copy/paste error, easily fixed.

Now the sanity test report is:

devel/aunit:

This command (FreshPorts code 2):

make master-sites-all -f /usr/home/dan/ports/devel/aunit/Makefile
PORTSDIR=/usr/home/dan/ports LOCALBASE=/nonexistentlocal
X11BASE=/nonexistentx
2>/tmp/FreshPorts.devel.aunit.make-mastersites-error.2007.10.24.12.25.5.344

produced this error:

Error message is: “/usr/home/dan/ports/devel/aunit/Makefile”, line 33:
Unassociated shell command “${ECHO_MSG} ${IGNORE}”
make: fatal errors encountered — cannot continue

Which is much more useful!

The fix for this sanity test failure error is out side the scope of this article and is left as an exercise for the committer.