Bug 1161585
| Summary: | 1.3.90 fails to build on aarch64, ppc64, s390 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Marcin Juszkiewicz <mjuszkie> | ||||||||||||
| Component: | libjpeg-turbo | Assignee: | Petr Hracek <phracek> | ||||||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | rawhide | CC: | blc, dan, negativo17, pbrobinson, phracek | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | aarch64 | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | libjpeg-turbo-1.3.90-2.fc22 | Doc Type: | Bug Fix | ||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2014-11-19 16:25:03 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 467765, 1071880, 922257, 1051573 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Marcin Juszkiewicz
2014-11-07 11:54:46 UTC
Hi Marcin, thanks for the bug. Let's say I would like to test scratch build. How to use koji for this case? There is only target armv7hl. Could you please send me this information? Greetings Petr
> How to use koji for this case? There is only target armv7hl.
All the above run on secondary koji instances so you can run:
for aarch64:
arm-koji build --scratch f22 blah.src.rpm
for ppc64 and ppc64le
ppc-koji build --scratch f22 blah.src.rpm
for s390*
s390-koji build --scratch f22 blah.src.rpm
And if needed we can provide you a login on secondary arch machines running Fedora. Just ask :-) I am solving that issue with upstream. http://sourceforge.net/p/libjpeg-turbo/mailman/libjpeg-turbo-devel/?viewmonth=201411 I will try to apply patches proposed by upstream and let you know. Testing is ongoing. Hi guys, I have tried to build packages but they failed during mock build (some Perl issues) http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2791330 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2187485 http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1611538 I include libjpeg-turbo patch to bugzilla for sure. Created attachment 958915 [details]
Patch for secondary arches
Created attachment 958916 [details]
C file with secondary arches functions
Petr, please try scratch builds against f21, f22/rawhide is still work in progress on secondary arches with broken deps expected. aarch64 (arm.koji) is up to date enough to do scratch builds against F-22 Created attachment 958951 [details]
Patch for seconary arches
The patch includes also fix for md5.
Created attachment 958954 [details]
Patch for secondary arches
Created attachment 958984 [details] Patch for secondary arches This patch makes the libjpeg-turbo buildable. http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1611638 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2188357 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2791595 scm-commit for rawhide https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20141117/1450520.html switched to CLOSED -> RAWHIDE rawhide build (http://koji.fedoraproject.org/koji/taskinfo?taskID=8187068) arm-koji f22 scratch build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2791727 ppc-koji f21 scratch build http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2188756 s390-koji f21 scratch build http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1611673 Notes from upstream and I decided to commented out relevant test ===================== If that's the only test that's failing, then I wouldn't worry about it. Different compilers can cause different results with the floating point DCT/IDCT, but those algorithms are mainly a legacy feature. They are included in 'make test' only because certain SIMD extensions include coverage for them, so 'make test' serves as a regression test for those SIMD extensions. In the case of x86-64, i386, and MIPS, for instance, the floating point DCT/IDCT will always generate well-defined values that are not compiler-dependent (because they are implemented in assembly.) On other platforms (including ARM32, but I have no way of testing ARM64), the floating point DCT/IDCT have always generated deterministic results as well, in my experience, but it could be because I'm always using similar versions of GCC to cross-compile. Note also that when I was referring to PPC64 fixes earlier, those targeted big endian architectures. They wouldn't have affected ppc64le. ====================== |