Bug 1626861 - python-polib %check runs no tests, hides s390x failures
Summary: python-polib %check runs no tests, hides s390x failures
Keywords:
Status: CLOSED CURRENTRELEASE
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: 2020-09-22 08:20 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-22 08:20:56 UTC
Type: Bug
Embargoed:


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.

Comment 14 Parag Nemade 2020-09-22 06:30:15 UTC
If there remain nothing to fix here, should we close this bug?


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