enchant-2 fails to build from source in unstable. A build ends with

| prefixDir: ., expectedPrefixDir: .
| language en, userLanguage C.UTF-8
| provider/get_user_language.cpp:87:1: error: Failure in EnchantGetUserLanguage_LocaleIsC_LocalIsEn: strncmp(language, userLanguage, strlen(language)) == 0
| provider/get_user_language.cpp:90:1: error: Failure in EnchantGetUserLanguage_LocaleIsC_LocalIsEn: userLanguage[2] == '_'
| FAILURE: 1 out of 474 tests failed (2 failures).
| Test time: 36.23 seconds.
| FAIL main.test (exit status: 2)
|
| ============================================================================
| Testsuite summary for enchant 2.8.2
| ============================================================================
| # TOTAL: 2
| # PASS:  1
| # SKIP:  0
| # XFAIL: 0
| # FAIL:  1
| # XPASS: 0
| # ERROR: 0
| ============================================================================
| See tests/test-suite.log for debugging.
| ============================================================================
| make[5]: *** [Makefile:1872: test-suite.log] Error 1
| make[5]: Leaving directory '/build/reproducible-path/enchant-2-2.8.2+dfsg1/tests'
| make[4]: *** [Makefile:2007: check-TESTS] Error 2
| make[4]: Leaving directory '/build/reproducible-path/enchant-2-2.8.2+dfsg1/tests'
| make[3]: *** [Makefile:2073: check-am] Error 2
| make[3]: Leaving directory '/build/reproducible-path/enchant-2-2.8.2+dfsg1/tests'
| make[2]: *** [Makefile:643: check-recursive] Error 1
| make[2]: Leaving directory '/build/reproducible-path/enchant-2-2.8.2+dfsg1'
| dh_auto_test: error: make -j1 check TESTSUITEFLAGS="-j1 --verbose" VERBOSE=1 returned exit code 2
| make[1]: *** [debian/rules:37: override_dh_auto_test] Error 25
| make[1]: Leaving directory '/build/reproducible-path/enchant-2-2.8.2+dfsg1'
| make: *** [debian/rules:12: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2

It seems like reproducible builds also reproduce this, but the web site
is too slow to download a build log atm.

Helmut

I was unable to reproduce this build failure using a basic
sbuild+unshare with Debian unstable later on Wednesday.

Afterwards, I uploaded the latest version of enchant but I changed the
source package name from enchant-2 to enchant. The build completed on
all Debian architectures:
https://buildd.debian.org/status/package.php?p=enchant

Since you mentioned "reproducible builds", see
https://salsa.debian.org/gnome-team/enchant/-/blob/debian/latest/debian/salsa-ci.yml

However, Salsa CI's default jobs now include debrebuild instead of
reprotest so I'll likely remove that snippet in the future.

debrebuild is passing both in Salsa CI and at
https://reproduce.debian.net/excuses.html?source_name=enchant
https://qa.debian.org/excuses.php?package=enchant
https://salsa.debian.org/gnome-team/enchant/-/pipelines

I guess FTBFS at https://tests.reproducible-builds.org is still a bug
but not RC.

Thank you,
Jeremy Bícha

I think debhelper and/or meson enforce building with C_UTF-8 for
packages built with meson so I think this bug might be unreproducible
if enchant used meson. Enchant uses autotools though.

Thank you,
Jeremy Bícha

Control: severity -1 minor
Control: retitle -1 enchant-2 FTBFS with bad LANGUAGE

I'm sorry. This turns out to be a defect in my build environment. A bad
LANGUAGE environment variable spoiled the build.

I did notice that it wasn't failing on the buildds and therefore retried
it several times before filing. I prematurely concluded that the
reproducible builds failure was the same. The root cause was my
environment injecting a bad LANGUAGE=C. I don't think anyone does this.
I'll leave it up to you whether to fix or close.

Helmut

Hi,

I came across this bug when doing reproducible builds efforts for
deepin. I noticed that tests/provider/get_user_language.cpp was removed
upstream since v2.8.3[1]. Could you confirm whether the problem still
exists?

Thank you!

[1]: https://github.com/rrthomas/enchant/commit/250e0d4

Best,
Tianyu Chen @ deepin

Indeed, this test failure can't happen since upstream 2.8.3, so I'm not
sure why the bug was marked as present in 2.8.16+dfsg-1.