Resolved ptest failures in espeak-ng package

[v-aaditya]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

Resolved ptest failures in espeak-ng package by disabling parallel build in check section.

In brief, during the espeak-ng test build, libtool attempts to link the espeak test library src/libespeak-ng-test.la, which depends on many objects generated from src/libespeak-ng/*.c. The build logs show libtool compile steps producing PIC objects under src/libespeak-ng/.lib and libtool wrapper (.lo).

However, the error indicates the expected wrapper file src/libespeak-ng/test_la-translate.lo is not a valid libtool object, typically meaning the file either does not exist as a proper ".lo" text wrapper or otherwise corrupted. In the test log file, this seems to be the root cause of the issue, where the library is linked before being built. This mismatch commonly occurs when using Automake's subdir-objects with custom suffix rules or parallel/concurrent builds that race on object generation.

AI Analysis relevance (In %) / Reasoning

AI Analysis relevance (In %): 99

Build/Dependency Information

The PR is a leaf PR which builds alone successfully.

Change Log

• modified: SPECS/espeak-ng/espeak-ng.spec

Does this affect the toolchain?

NO

Associated issues

• Work Item: https://dev.azure.com/mariner-org/mariner/_workitems/edit/14940

Test Methodology

• Local build was successful.

• Screenshot to confirm that the check section is built serially.

• License check script shows no warning.

• Build logs:
  espeak-ng-1.52.0-2.azl3.src.rpm.log
  espeak-ng-1.52.0-2.azl3.src.rpm.test.log

[v-aaditya]

Buddy Build has been triggered - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1056796&view=results

[v-aaditya]

Buddy Build has been triggered - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1056796&view=results

Buddy Build has passed.

[Kanishk-Bansal]

Root cause analysis is correct — the libtool race condition with parallel builds is a well-known class of bug in autotools projects

define _smp_mflags -j1 is a global override — not scoped to %check

Using %define _smp_mflags -j1 inside %check redefines the macro globally for the rest of the spec. While this works here because %check is the last section that calls %make_build, it's fragile. If anyone adds a %post build step or reorders sections, the build phase would also get -j1.

Recommendation: Use %make_build -j1 check directly (or make -j1 check) instead of redefining the macro. This is more explicit and avoids side effects. Alternatively, %global _smp_mflags -j1 would at least make the intent clearer, but the inline override is still preferred

[v-aaditya]

Root cause analysis is correct — the libtool race condition with parallel builds is a well-known class of bug in autotools projects

define _smp_mflags -j1 is a global override — not scoped to %check

Using %define _smp_mflags -j1 inside %check redefines the macro globally for the rest of the spec. While this works here because %check is the last section that calls %make_build, it's fragile. If anyone adds a %post build step or reorders sections, the build phase would also get -j1.

Recommendation: Use %make_build -j1 check directly (or make -j1 check) instead of redefining the macro. This is more explicit and avoids side effects. Alternatively, %global _smp_mflags -j1 would at least make the intent clearer, but the inline override is still preferred

Sure, will update the spec file accordingly and confirm by executing local build and Buddy build.

[v-aaditya]

@Kanishk-Bansal Could you please re-trigger the Buddy Build !

[v-aaditya]

@Kanishk-Bansal Could you please re-trigger the Buddy Build !

The Buddy Build has been triggered and has also passed !

[Kanishk-Bansal]

Changes LGTM

[kgodara912]

Minor correction in parallel execution of only check section due to failure in parallel execution. Buddy build is successful. LGTM.