Bug 1626861 - python-polib %check runs no tests, hides s390x failures
Summary: python-polib %check runs no tests, hides s390x failures
Keywords:
Status: MODIFIED
Alias: None
Product: Fedora
Classification: Fedora
Component: python-polib
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ding-Yi Chen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker
TreeView+ depends on / blocked
 
Reported: 2018-09-09 21:34 UTC by Miro Hrončok
Modified: 2019-08-13 19:15 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-10 16:39:53 UTC


Attachments (Terms of Use)
build.log on s390x with tests fully enabled (181.07 KB, text/plain)
2018-09-10 08:46 UTC, Miro Hrončok
no flags Details

Description Miro Hrončok 2018-09-09 21:34:12 UTC
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

Comment 1 Miro Hrončok 2018-09-09 21:36:43 UTC
It seems that our test pass on s390x, so here's a PR:

https://src.fedoraproject.org/rpms/python-polib/pull-request/1

Comment 2 Matěj Cepl 2018-09-10 07:55:50 UTC
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.

Comment 3 Miro Hrončok 2018-09-10 08:46:49 UTC
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

Comment 6 Miro Hrončok 2018-10-22 07:06:30 UTC
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.

Comment 7 Sundeep Anand 2018-10-22 09:43:17 UTC
I am interested in maintaining this package.

Comment 8 Miro Hrončok 2018-12-10 12:34:09 UTC
Bump.

Comment 9 Miro Hrončok 2018-12-10 16:51:00 UTC
Are the s390x failures fixed, not hidden?

Comment 10 David Shea 2018-12-10 17:04:14 UTC
(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.

Comment 11 Miro Hrončok 2018-12-11 06:46:17 UTC
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.

Comment 12 Sundeep Anand 2019-03-25 08:58:32 UTC
Yes - I would like to maintain it :)

Comment 13 Ben Cotton 2019-08-13 19:15:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.


Note You need to log in before you can comment on or make changes to this bug.