Currently, the dbm storage format is the default of NSS. When the NSS test suite is executed, it runs 4 cycles. I believe the first cycle implicitly depends on the dbm database format. We should fix it to explicitly request the dbm format. This approach will probably ensure that the cycle named "upgradedb" also operates on the expected dbm input. The cycle named "sharedb" probably already explicitly requests the sql format. For the pkix cycle, not sure what we should do, I guess it doesn't matter much which format is used. Probably changing it to use sql, too, would be a good idea, but it could continue to rely on the default format.

Hmm, I see the sharedb cycle limits the amount of tests executed. Was that done to avoid redundancy? I think ideally the full set of tests should be executed with the sql format, and potential redundancy removals should be done for dbm.

First attempt, does this patch seem reasonable? I've moved the limitations between standard (name for dbm) and sharedb (name for sql). I'm currently running local tests to check if we still get the same amount of tests. Feedback welcome.

RE comment 1. I think it was to limit the exponential explosion of tests. Tests that weren't all necessarily database based would have some version run as dbm and some version run as sql. There are even a smaller set for updatedb, but many of the updatedb tests that were dropped were database creation tests, which didn't apply to databases that had all the certs and keys already created and updated from dbm.

re comment 2: That looks good. The only thing I'd do is skip upgradedb from sql and run it on the dbm side. upgradedb up grades a dbm database to an sql database. It would be a noop in the sql.

(In reply to Robert Relyea from comment #4) > re comment 2: That looks good. The only thing I'd do is skip upgradedb from > sql and run it on the dbm side. upgradedb up grades a dbm database to an sql > database. It would be a noop in the sql. Thanks, this patch should implement your suggestion.

(In reply to Kai Engert (:kaie:) from comment #2) > I'm currently running local tests to check if we still get the same amount of tests. I saw the same total number of tests executed in all scenarios (with and without patch, search for number of PASSED in output.log).

I think we can land this at any time, even prior to landing bug 1377940, Franziskus, do you agree?

Sure, I don't see a reason to wait with landing this.

Comment on attachment 8913651 [details] [diff] [review] 1403691-v2.patch Review of attachment 8913651 [details] [diff] [review]: ----------------------------------------------------------------- r+ rrelyea

This needs a follow-up fix. Our pkits.sh test suite, which we run on buildbot, only (see bug 1375900), has been changed to be executed in the pkits.sh cycle. The command to change the trust fails, because the database password is required, but not given.

Comment on attachment 8918320 [details] [diff] [review] 1403691-pkits-password.patch Review of attachment 8918320 [details] [diff] [review]: ----------------------------------------------------------------- r+ rrelyea