# BST-TIMEOUT: 900   # ~60 cases; the regress slices alone measured ~120 s, and every
#                      case here forks a 15 MB binary — the 60 s default is not close.
. "$BST_LIB"

# libevent 2.1.12-stable (oe-core recipes-support/libevent), closed on upstream's own
# `test/regress` suite, which OpenEmbedded packages as a ptest.
#
# THE ORACLE IS A NATIVE x86_64 CONTROL BUILD of the identical tarball (sha256
# 92e6de1b…403bb, the sum the recipe pins), with all five oe-core patches applied in
# recipe order, `autoreconf -fi`, and the recipe's own arms plus the distro-wide
# --disable-shared. It reported **312 tests ok, 33 skipped, 0 failed** over 14 groups.
# Every count below was read off that run, never off the source.
#
# WHAT THIS FILE RUNS, AND WHAT IT DELIBERATELY DOES NOT. Upstream's suite forks a
# child per case (240 of the 312 are `[forking]`), and `--no-fork` is NOT an
# alternative mode: the control run in that mode reached 60 cases and then the process
# itself died at et/et_mix_error, which drives an error path fatal to its own process.
# So forking is load-bearing, and it WORKS here — that is this port's main positive
# finding, and the fast groups below are what demonstrate it.
#
# TWO FAMILIES ARE NEVER RUN, because running them costs the machine rather than a
# case, and both are reported as reds instead (a blocked thing stays `not ok`; it is
# not downgraded to a skip to make a run green):
#
#   evbuffer/add_file*  the sendfile-backed variants (*_sendfile and *_nosegment,
#                       whose "default" method IS sendfile) hit sendfile(2) = ENOSYS,
#                       and upstream turns that one errno into an UNBOUNDED failure
#                       loop: addfile_test_writecb calls tt_fail_perror("write") and
#                       event_base_loopexit() but never returns, so the enclosing
#                       `while (evbuffer_get_length(b))` spins forever. One measured
#                       run emitted 5,547,559 identical FAIL lines and took the
#                       console with it. The *_mmap and *_linear variants pass.
#   signal/*            the whole group wedges at signal/simplestsignal — the case
#                       prints its `[forking]` banner and never returns a verdict.
#                       Measured twice, alone and in a full run.
#
# THE FULL UPSTREAM PTEST IS ONE ENVIRONMENT VARIABLE AWAY, for whoever wants it:
#
#     BST_LIBEVENT_PTEST=1 BST_SUITE_TIMEOUT=2400 brintos-selftest 78-libevent.test
#
# and `ptest-runner -t 600 libevent` runs it directly. Both wedge at the add_file
# flood today; that is the ticket's R3 answer, not a gap in this file.

ptestdir=/usr/lib/libevent/ptest
regress=$ptestdir/test/regress

# ------------------------------------------------------------- what shipped ----
# All builtin `test`, so this whole block costs no process.
check_rc libevent/ptest-dir       0 test -d "$ptestdir"
check_rc libevent/ptest-runptest  0 test -x "$ptestdir/run-ptest"
check_rc libevent/ptest-regress   0 test -x "$regress"

# The nine programs do_install_ptest copies. Asserted individually because oe-core
# copies them from ${B}/test/.libs/, which on a static-only distro holds archives and
# NOT these -- the bbappend's whole subject. A partial copy would surface exactly here.
for b in test-init test-eof test-weof test-time test-changelist \
         test-closed test-dumpevents test-fdleak test-ratelim; do
  check_rc "libevent/ptest-bin-$b" 0 test -x "$ptestdir/test/$b"
done

# ...and NOT the .o beside each of them: the same glob matches both, and upstream's
# never had to care because .libs/ holds no objects.
check_rc libevent/ptest-no-objects 1 test -e "$ptestdir/test/test-init.o"

# One archive per library the recipe builds, plus the headers and the .pc.
for a in libevent.a libevent_core.a libevent_extra.a libevent_pthreads.a; do
  check_rc "libevent/archive-$a" 0 test -s "/usr/lib/$a"
done
check_rc libevent/header-event    0 test -s /usr/include/event2/event.h
check_rc libevent/header-config   0 test -s /usr/include/event2/event-config.h
check_rc libevent/pkgconfig       0 test -s /usr/lib/pkgconfig/libevent.pc

# The distro is static-only, so no DSO may exist. libtool's wrapper directory is the
# same thing the ptest install had to work around, so its absence is asserted too.
check_rc libevent/no-shared-object 1 test -e /usr/lib/libevent-2.1.so.7
check_rc libevent/no-libtool-libs  1 test -d "$ptestdir/test/.libs"

# ------------------------------------------- upstream's own suite, fast groups ----
# Each slice is one `regress` invocation, and the assertion is upstream's own summary
# line. The two known-red cases are skipped HERE and asserted separately below, so a
# slice's own count stays a clean equality rather than "N or N-2".

run_slice() {   # run_slice <id> <want-ok-count> <regress args...>
  id=$1; want=$2; shift 2
  out=$("$regress" "$@" 2>&1)
  got=$(printf '%s\n' "$out" | sed -n 's/^\([0-9]*\) tests ok\..*/\1/p')
  if [ -z "$got" ]; then
    bst_notok "$id" "no summary line: $(_bst_1line "$out")"
  else
    check_eq "$id" "$want" "$got"
  fi
}

# main: 64 cases. 4 skip on their own (simpleclose_*_et), 2 are the attributed reds
# below, so 58 remain. Measured 58, in ~10 s.
run_slice libevent/regress-main 58 main.. :main/del_wait :main/del_notify

# evbuffer: 59 cases, of which the 8 sendfile-path ones are never run (above). 51
# remain -- 41 in-process plus the 10 *_mmap / *_linear add_file variants, which are
# exactly the evidence that the family's failure is sendfile's and not evbuffer's.
run_slice libevent/regress-evbuffer 51 evbuffer.. \
  :evbuffer/add_file_sendfile :evbuffer/add_file_nosegment \
  :evbuffer/add_big_file_sendfile :evbuffer/add_big_file_nosegment \
  :evbuffer/add_file_offset_sendfile :evbuffer/add_file_offset_nosegment \
  :evbuffer/add_file_offset2_sendfile :evbuffer/add_file_offset3_sendfile

# The remaining fast, non-networking groups, whole and unmodified: rpc 8, evtag 4,
# finalize 4, heap 1 = 17. (et is left out: et/et_mix_error is the case that kills its
# own process by design, and one of its three skips on this arm anyway.)
run_slice libevent/regress-misc 17 rpc.. evtag.. finalize.. heap..

# ------------------------------------------------- the reds, each attributed ----
# Each asserts what a WORKING platform gives, so it turns green by itself when its
# issue lands and nothing here has to be rewritten at that point.

# BRINTOS-WORKAROUND: brintos/linux-in-the-browser#120 revisit — relative timers are
# inaccurate here, so libevent's 270 ms deadline lands outside its own 100 ms window.
check libevent/del-wait "$regress" main/del_wait

# BRINTOS-WORKAROUND: brintos/hardwarejs#12 revisit — the futex BITSET ops answer
# ENOSYS in the Worker fast path, so pthread_join aborts with glibc's own "The futex
# facility returned an unexpected error code." and the child is lost. That exact
# message is what this case prints, which is why it is #12 and not #17.
check libevent/del-notify "$regress" main/del_notify

# BRINTOS-WORKAROUND: brintos/hardwarejs#17 revisit — a different failure from
# del_notify's despite both being pthread cases: this one prints no futex message and
# instead trips the runtime's own "hwjs-user-rt VIOLATION: orphan at clear: parked
# slot not empty at bracket entry", i.e. the leaked coroutine park slot of #17.
check libevent/thread-basic "$regress" thread/basic

# BRINTOS-WORKAROUND: brintos/linux-in-the-browser#105 revisit — an indirect call
# dispatched after a coroutine resume traps with "null function or function signature
# mismatch", here in regress's own run_legacy_test_fn.
check libevent/bufferevent-zlib "$regress" bufferevent/bufferevent_zlib

# The two families that are never run. Asserted as reds directly, because the run is
# what costs the machine -- see the header. Both carry their issue so the branch and
# the case are swept up together when it closes.
#
# BRINTOS-WORKAROUND: brintos/linux-in-the-browser#151 remove — sendfile(2) = ENOSYS.
# The 10 *_mmap / *_linear variants asserted by regress-evbuffer above are the control
# that makes this the drain mechanism's fault and not evbuffer's.
bst_notok libevent/add-file-sendfile \
  "sendfile(2) = ENOSYS (linux-in-the-browser#151), and upstream loops on it unbounded (5.5M FAIL lines) — not run"

# BRINTOS-WORKAROUND: brintos/linux#21 remove — signals are delivered only at the next
# command dispatch, so a process BLOCKED waiting for one never receives it. That is
# exactly event_base_dispatch(), hence the whole group and not one case.
bst_notok libevent/signal-group \
  "signal/simplestsignal wedges with no verdict (brintos/linux#21); the whole 10-case group is unrunnable — not run"

# ------------------------------------------------------- the opt-in full run ----
if [ -n "${BST_LIBEVENT_PTEST:-}" ]; then
  out=$(cd "$ptestdir" && sh ./run-ptest 2>&1)
  check_out libevent/ptest-full "TOTAL:" printf '%s\n' "$out"
fi