Bugzilla – Bug 1079855
[glibc2.27] libstorage-ng fails test suite
Last modified: 2018-02-12 17:29:39 UTC
openSUSE Factory is in progress of merging GLIBC 2.27 - libstorage-ng is amongst the packages failing to build From the build log: [ 1086s] FAIL: humanstring.test complete log at https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:C/libstorage-ng/standard/i586 There was a similar bug also in yast2-core (see bug 1079630)
See also mvidner's comment in that other bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1079630#c0 glibc now seems to use different thousands separators in some locales, and, adding insult to injury, it's not even visible - it's just another kind of blank.
mvidner found the commit that changed this in glibc: https://sourceware.org/git/?p=glibc.git;a=commit;h=70a6707fa15e63591d991761be025e26e8d02bb6
Pull request: https://github.com/openSUSE/libstorage-ng/pull/460 Glibc now uses a narrow non-breakable space character (U+202F) as a thousands separator in certain locales. This makes some unit tests we did in the libstorage-ng humanstring() function dependent on the version of glibc that it is linked against, and, worse, it's not even well-defined how to get that non-ASCII character properly to the compiler and through the unit test framework we use. We decided to just drop those few unit tests for now. The important thing about testing that function is to check for proper use of Byte/kB/MB/GB etc. for most locales and Octet/kO/MO/GO etc. in French. We need to be able to trust glibc to format numbers correctly in general; all we add is the unit suffix.
The fix will be available with libstorage-ng-3.3.157 or later.
Submit request: https://build.opensuse.org/request/show/575845