I was asked by an openSUSE maintainer whether we are bugged by https://bitbucket.org/izi/polib/issues/96/tests-fail-on-bigendian-platforms So I fired up a scratch build, but apparently, the %check section is just false promise. See: Executing(%check): + /usr/bin/python2 setup.py test ... Ran 0 tests in 0.000s OK + /usr/bin/python3 setup.py test ... Ran 0 tests in 0.000s That is python-polib-1.0.7-12. Upstream uses "python tests/tests.py", so what about: %if 0%{?fedora} || 0%{?rhel} >= 8 %check %{__python2} tests/tests.py %if %{with python3} %{__python3} tests/tests.py %endif # with python3 %endif # 0#{?fedora} || 0#{?rhel} >= 8 Executing(%check): + /usr/bin/python2 tests/tests.py ...................................................................... ---------------------------------------------------------------------- Ran 70 tests in 0.222s OK + /usr/bin/python3 tests/tests.py ...................................................................... ---------------------------------------------------------------------- Ran 70 tests in 0.208s OK
It seems that our test pass on s390x, so here's a PR: https://src.fedoraproject.org/rpms/python-polib/pull-request/1
Except that test is actually skipped: def test_save_as_mofile(self): """ Test for the POFile.save_as_mofile() method. """ import distutils.spawn msgfmt = distutils.spawn.find_executable('msgfmt') if msgfmt is None: try: return unittest.skip('msgfmt is not installed') except AttributeError: return reffiles = ['tests/test_utf8.po', 'tests/test_iso-8859-15.po'] encodings = ['utf-8', 'iso-8859-15'] for reffile, encoding in zip(reffiles, encodings): fd, tmpfile1 = tempfile.mkstemp() os.close(fd) fd, tmpfile2 = tempfile.mkstemp() os.close(fd) po = polib.pofile(reffile, autodetect_encoding=False, encoding=encoding) po.save_as_mofile(tmpfile1) subprocess.call([msgfmt, '--no-hash', '-o', tmpfile2, reffile]) try: f = open(tmpfile1, 'rb') s1 = f.read() f.close() f = open(tmpfile2, 'rb') s2 = f.read() f.close() self.assertEqual(s1, s2) finally: os.remove(tmpfile1) os.remove(tmpfile2) If you don't have installed a package containing /usr/bin/msgfmt (in OpenSUSE it is gettext-runtime, in Fedora/RHEL I guess just gettext), this test is skipped.
Created attachment 1482045 [details] build.log on s390x with tests fully enabled Right, with: BuildRequires: /usr/bin/msgfmt This does fail test_save_as_mofile. Attached build.log
Is there anybody out there? This package has 6 admins. Is none of you responsive? CCing FreeIPA people, so they are aware that one of their dependencies seems abandoned.
I am interested in maintaining this package.
Bump.
Are the s390x failures fixed, not hidden?
(In reply to Miro Hrončok from comment #9) > Are the s390x failures fixed, not hidden? The tests run, and they almost certainly fail since I far as I know polib still does not check the endianess of .mo files, and the tests use little endian .mo files. This is hardly an urgent issue. Fedora's primary architectures are little-endian only, and this issue only applies to using polib to read .mo files that were built for a different architecture. So maybe cool it on the "bump" messages everywhere.
David, I'm totally OK if somebody tells me "this is not a priority". I too have plenty other things to work on. However I'm sending bump messages to places where I feel ignored. Such as the PR that adds the tests - no reaction at all for 3 months while there are 6 maintainers. I'm deeply sorry if my bumps are so annoying, all you have to do to stop them is to respond - even a "I don't care about s390x failures or running test at all, closed" would work for me. Silence is frustrating. Also, if you are so confident that this is a no issue, maybe we should skip this one particular test on s390x with an explanation message in a comment, rather than closing this bug as CLOSED RAWHIDE without even saying why exactly is this CLOSED. If you are not interested in responding to Pull Requests and bugzillas for python-polib, Sundeep Anand would like to maintain it.
Yes - I would like to maintain it :)
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
If there remain nothing to fix here, should we close this bug?