python-pillow-2.0.0-3.gitde210a2.fc19 (as well as -2.git2e88848.fc19 and -1.git2f4207c.fc19) fails to build on ppc(64) due to failing tests: Tests/test_image_array.py:13: assert_equal(test("I"), ((100, 128), '<i4', 51200)) # FIXME: wrong? failed: - got ((100, 128), '>i4', 51200), expected ((100, 128), '<i4', 51200) Tests/test_image_array.py:14: assert_equal(test("F"), ((100, 128), '<f4', 51200)) # FIXME: wrong? failed: - got ((100, 128), '>f4', 51200), expected ((100, 128), '<f4', 51200) Tests/test_lib_pack.py:28: assert_equal(pack("I", "I"), [1, 0, 0, 0]) failed: - got [0, 0, 0, 1], expected [1, 0, 0, 0] Tests/test_lib_pack.py:30: assert_equal(pack("F", "F"), [0, 0, 128, 63]) failed: - got [63, 128, 0, 0], expected [0, 0, 128, 63] Tests/test_mode_i16.py:90: assert_equal(tobytes("I"), b"\x01\x00\x00\x00") failed: - got '\x00\x00\x00\x01', expected '\x01\x00\x00\x00' Full log: http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/4514/1014514/build.log
I'll investigate
Created attachment 717867 [details] Fix incorrectly assumed little-endian CPU All these are endianness issues. The attached patch should fix the issues, please give it a try and I'll do a pull request upstream and commit it to the fedora repo.
the results for our big-endian platforms are: ppc (32bit) - all tests are passed s390 (32bit) - all tests expect webp are passed ... running test_file_webp ... Tests/test_file_webp.py:21: assert_image_equal(im, target) failed: - got different content Tests/test_file_webp.py:42: assert_image_equal(im, target) failed: - got different content ... ppc64 (64bit) - test_image_getcolors and test_image_quantize are failing ... running test_image_getcolors ... Tests/test_image_getcolors.py:48: assert_equal(A, None) failed: - got [(3249, (0, 0, 0)), (13135, (255, 255, 255))], expected None Tests/test_image_getcolors.py:52: assert_equal(A, expected) failed: - got [(3249, (0, 0, 0)), (13135, (255, 255, 255))], expected [(3236, (227, 183, 147)), (6297, (143, 84, 81)), (6851, (208, 143, 112))] Tests/test_image_getcolors.py:56: assert_equal(A, expected) failed: - got [(3249, (0, 0, 0)), (13135, (255, 255, 255))], expected [(3236, (227, 183, 147)), (6297, (143, 84, 81)), (6851, (208, 143, 112))] Tests/test_image_getcolors.py:60: assert_equal(A, expected) failed: - got [(3249, (0, 0, 0)), (13135, (255, 255, 255))], expected [(3236, (227, 183, 147)), (6297, (143, 84, 81)), (6851, (208, 143, 112))] Tests/test_image_getcolors.py:64: assert_equal(A, expected) failed: - got [(3249, (0, 0, 0)), (13135, (255, 255, 255))], expected [(3236, (227, 183, 147)), (6297, (143, 84, 81)), (6851, (208, 143, 112))] ... running test_image_quantize ... Tests/test_image_quantize.py:22: assert len(im.getcolors()) == 100 failed: Traceback (most recent call last): File "Tests/test_image_quantize.py", line 22, in test_octree_quantize assert len(im.getcolors()) == 100 AssertionError ... s390x (64bit) - same as ppc64 + the webp failure from s390 scratch build on ppc/ppc64 - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1020659
please fix a typo in the previous comment s390 (32bit) - all tests except webp are passed
The webp test is fixed upstream, the image_get_colors failures are probably a consequence of the quantize code misbehaving, and as for why the quantization code is failing, I'll need to investigate...
I've tried running a fedora ppc64 iso via qemu but all I get is a yellowish screen when running "qemu-system-ppc64 -cdrom /path/to/iso -m 1024M"... Any way I can get a ppc environment running without corresponding hardware?
(In reply to comment #6) > I've tried running a fedora ppc64 iso via qemu but all I get is a yellowish > screen when running "qemu-system-ppc64 -cdrom /path/to/iso -m 1024M"... Any > way I can get a ppc environment running without corresponding hardware? you can get an account on a real ppc64 hardware, please check #fedora-ppc IRC channel on FreeNode in the afternoon EU time or wait for a contact via email. I'll ask the right people to act.
This will require some effort, since overall the quantization code looks very fragile (void* to int casts, assumptions that an unsigned long is 4 bytes, etc - actually a miracle that it works at all on other platforms). But I'm working on it.
Proposing as F19 Alpha blocker, right now we have a workaround in form of python-pillow-2.0.0-3.1.gitde210a2.fc19 which disables the test-suite for ppc/ppc64 and s390/s390x and has no change on x86/x86_64. We need this build to be tagged to f19.
For what reason? Why should this block the release? What is the practical result of the bug?
The secondary arches build packages within buildroots that contains ideally only the same NVR as the buildroots in primary, practically there can be few newer NVRs for packages that fail to build and must be fixed. But definitely no older NVRs are allowed. Not having python-pillow-2.0.0-3.1.gitde210a2.fc19 (and latest pygobject3) tagged in f19 means secondary arches can't build cca 300 packages that existed in f19 before the alpha freeze eg. anaconda or the latest GNOME stuff. The release engineering tag syncing script ensure that same NVRs are tagged between primary and secondaries effectively meaning no newer NVR is possible in secondary. This won't allow to make an Alpha compose on secondaries that matches primary. Risk for inclusion of python-pillow-2.0.0-3.1.gitde210a2.fc19 instead of python-pillow-2.0.0-3.gitde210a2.fc19 in primary is zero as there is no difference in these 2 packages for primary.
switching to Freeze Exception which is more appropriate
Sorry for the silence, illness kept me in bed the past few days... From what I understand, the version disparity is the biggest problem atm - I'll update pillow in F19 and rawhide in primary. As for the issue itself, my efforts on narrowing down the issue have so far been unsuccessful. Attempting to replace various variable types with types from stdint.h to match the assumptions made did not help.
Got it! Patches commited (see [1]) and sent upstream. ppc scratch-build here [2]. [1] http://pkgs.fedoraproject.org/cgit/python-pillow.git/commit/?id=da3613d08948dda9e6597bc47cb1b0ffc641b582 [2] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1033901
python-pillow-2.0.0-5.git93a488e.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-pillow-2.0.0-5.git93a488e.fc19
Package python-pillow-2.0.0-5.git93a488e.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-pillow-2.0.0-5.git93a488e.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5105/python-pillow-2.0.0-5.git93a488e.fc19 then log in and leave karma (feedback).
Discussed at 2013-04-08 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-08/f19alpha-blocker-review-5.2013-04-08-16.01.log.txt . This is accepted as a freeze exception as a secondary arch blocker, but we are *only* granting a freeze exception to the 'workaround' build python-pillow-2.0.0-3.1.gitde210a2.fc19 , not the 'fix' build python-pillow-2.0.0-5.git93a488e.fc19 . The fix build looks like too big and untested a change to be worth endangering the primary arches for.
Adam, thanks, the workaround build is what was requested and is sufficient for our purposes.
python-pillow-2.0.0-3.1.gitde210a2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-pillow-2.0.0-3.1.gitde210a2.fc19
python-pillow-2.0.0-6.gitd1c6db8.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-pillow-2.0.0-6.gitd1c6db8.fc19
python-pillow-2.0.0-3.1.gitde210a2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
python-pillow-2.0.0-6.gitd1c6db8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.