I am not sure what is preventing us to stabilize a newer db version than 4.8. I see other distributions like Fedora having 5.3 for some time without issues, and only a few packages requiring them to still package 4.8 (that is already done in our case as we have slotted versions for even more versions that are probably not needed for years). Thanks
I had bug 319587 for this process, and then there was no progress thereafter. Let's do it. Target Stable Keywords: alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86 Arches, please test: - If tests PASS: stabilize. - If tests FAIL: please post your output here for review and I'll give you a yay/nay for stable based on the test failure. Test instructions USE='cxx tcl -java -doc' FEATURES=test emerge =db-5.3.28-r2 You'll want to give it LOTS of cores; it'll take 2-12 hours depending on your system.
Stable on alpha.
arm stable
NACK. sys-libs/db-5.3.28-r2 cannot be stabilized until sys-devel/libtool-2.4.6-r1 is stabilized, due to, e.g., bug 601098. To summarize, libtool needs to pass along "-fuse-ld" to the linker driver in order for tc-ld-disable-gold to be effective.
amd64 stable
Stable for HPPA.
sparc stable
x86 stable
ia64 stable
ppc/ppc64 stable
(In reply to Robin Johnson from comment #1) > Arches, please test: > - If tests PASS: stabilize. > - If tests FAIL: please post your output here for review and I'll give you a > yay/nay for stable based on the test failure. Tests fails on arm64: Checking output from ALL.OUT.24 ... UNEXPECTED OUTPUT: FAIL:02:12:52 (00:00:00) pair: expected 0, got 1 Checking output from ALL.OUT.30 ... UNEXPECTED OUTPUT: FAIL:02:08:24 (00:00:00) pair: expected 0, got 1 Checking output from ALL.OUT.34 ... UNEXPECTED OUTPUT: FAIL: repmgr_start:address already in use Checking output from ALL.OUT.38 ... UNEXPECTED OUTPUT: FAIL: env163: BDB2034 unable to allocate memory for mutex; resize mutex region UNEXPECTED OUTPUT: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery Checking output from ALL.OUT.42 ... UNEXPECTED OUTPUT: FAIL:02:00:04 (00:00:00) pair: expected 0, got 1 Checking output from ALL.OUT.50 ... UNEXPECTED OUTPUT: FAIL:02:13:01 (00:00:00) pair: expected 0, got 1 Checking output from ALL.OUT.69 ... UNEXPECTED OUTPUT: FAIL:02:33:35 (00:00:00) pair: expected 0, got 1 The ALL.OUT.* files are kept around for now for any necessary details to judge stabilization. Poke on IRC or so.
Another arm64 run, with -j4 instead of -j75 (same 96-core box): failures: FAIL: condition {[stat_field $masterenv rep_stat "Next LSN expected"] == [stat_field $clientenv rep_stat "Next LSN expected"]} not achieved in 20 seconds. BDB5096 received panic event BDB5096 received panic event BDB5096 received panic event FAIL:08:18:18 (00:00:00) pair: expected 0, got 1 FAIL:05:55:24 (00:00:00) pair: expected 0, got 1 FAIL:07:30:02 (00:00:00) pair: expected 0, got 1 FAIL:07:32:36 (00:00:00) pair: expected 0, got 1 FAIL: env163: BDB2034 unable to allocate memory for mutex; resize mutex region BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery FAIL:02:25:10 (00:00:00) pair: expected 0, got 1 FAIL:09:20:19 (00:00:00) pair: expected 0, got 1
<robbat2> leio: i think possibly good enough to stable sys-libs/db there for now, i think it's kernel related, not db itself as such: arm64 stable; last arch - closing.
