Bug 1161585 - 1.3.90 fails to build on aarch64, ppc64, s390
Summary: 1.3.90 fails to build on aarch64, ppc64, s390
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libjpeg-turbo
Version: rawhide
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Hracek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker PPCTracker ARM64, F-ExcludeArch-aarch64 F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2014-11-07 11:54 UTC by Marcin Juszkiewicz
Modified: 2014-11-19 16:25 UTC (History)
5 users (show)

Fixed In Version: libjpeg-turbo-1.3.90-2.fc22
Clone Of:
Environment:
Last Closed: 2014-11-19 16:25:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Patch for secondary arches (27.14 KB, patch)
2014-11-19 09:12 UTC, Petr Hracek
no flags Details | Diff
C file with secondary arches functions (11.15 KB, text/x-csrc)
2014-11-19 09:12 UTC, Petr Hracek
no flags Details
Patch for seconary arches (27.91 KB, patch)
2014-11-19 12:21 UTC, Petr Hracek
no flags Details | Diff
Patch for secondary arches (27.91 KB, patch)
2014-11-19 12:40 UTC, Petr Hracek
no flags Details | Diff
Patch for secondary arches (28.60 KB, patch)
2014-11-19 14:33 UTC, Petr Hracek
no flags Details | Diff

Description Marcin Juszkiewicz 2014-11-07 11:54:46 UTC
Description of problem:

libjpeg-turbo got updated to prerelease 1.3.90 version. And then failed to build on secondary architectures: aarch64, ppc64, s390.

Version-Release number of selected component (if applicable):

1.3.90-1

How reproducible:

always

Steps to Reproduce:
1. do a build on aarch64 (arm-koji) or ppc64 (ppc-koji) or s390 (s390-koji)

Actual results:

Package fails in testsuite.

Expected results:

Packages passes testsuite.

Additional info:

libjpeg-turbo development scheme is weird - 1.4.x branch (which 1.3.90 was built from) was created in a way that bisecting change which broke builds is impossible.

Comment 1 Petr Hracek 2014-11-11 15:34:28 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

Comment 2 Peter Robinson 2014-11-11 15:37:22 UTC
> 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

Comment 3 Dan Horák 2014-11-18 18:21:57 UTC
And if needed we can provide you a login on secondary arch machines running Fedora. Just ask :-)

Comment 4 Petr Hracek 2014-11-19 09:01:14 UTC
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.

Comment 5 Petr Hracek 2014-11-19 09:11:34 UTC
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.

Comment 6 Petr Hracek 2014-11-19 09:12:14 UTC
Created attachment 958915 [details]
Patch for secondary arches

Comment 7 Petr Hracek 2014-11-19 09:12:53 UTC
Created attachment 958916 [details]
C file with secondary arches functions

Comment 8 Dan Horák 2014-11-19 09:20:21 UTC
Petr, please try scratch builds against f21, f22/rawhide is still work in progress on secondary arches with broken deps expected.

Comment 9 Peter Robinson 2014-11-19 10:51:31 UTC
aarch64 (arm.koji) is up to date enough to do scratch builds against F-22

Comment 10 Petr Hracek 2014-11-19 12:21:33 UTC
Created attachment 958951 [details]
Patch for seconary arches

The patch includes also fix for md5.

Comment 11 Petr Hracek 2014-11-19 12:40:59 UTC
Created attachment 958954 [details]
Patch for secondary arches

Comment 13 Petr Hracek 2014-11-19 16:25:03 UTC
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.
======================


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