Description of problem: lsfc enters end-less loop when running checks on big-endian arches like s390/s390x and ppc/ppc64 Version-Release number of selected component (if applicable): lfsc-0.20120321-2.fc19 How reproducible: 100% from build.log: ... Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.bacBiY + umask 022 + cd /builddir/build/BUILD + cd lfsc-0.20120321 + opt/lfsc /builddir/build/SOURCES/sat.plf /builddir/build/SOURCES/check.plf and nothing else there even after days
I spent some time yesterday on a fruitless attempt at setting up a ppc64 VM on my Fedora 18 x86_64 desktop. Today I've looked a little at setting up an s390 VM, but it appears that I need to use the hercules emulator. I've got no experience whatsoever with IBM mainframes, hercules, etc. Do you know of a guide somewhere that will help me do this? Something like, "follow these 37 easy steps and you'll have a running Fedora system in an s390 VM!"? I've tried searching the web for such a guide but have so far found only instructions involving disk images containing ancient versions of Fedora.
I'll get you in contact with Brent Baude of IBM who can give you shell on ppc64 machine.
F-16 for s390x in the Hercules emulator should be matter of copying 2 files, but shell access on a real box will be better.
That sounds great. Thanks, Dan. For future reference, though, in case I need to track down s390-specific bugs in the future, which 2 files would I need to copy to get F-16 for s390x going in Hercules?
Please wait a while, I will write a blog article about it (the files are at http://fedora.danny.cz/s390/fedora-16/). Also I hope to be more successful with F-19 inside Hercules than I was with F-17 or F-18.
lfsc-0.20120321-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-6250/lfsc-0.20120321-3.fc19
lfsc-0.20120321-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-6307/lfsc-0.20120321-3.fc18
The issue turns out not be big-endianness after all, but rather that the type "char" defaults to "unsigned char", as opposed to x86 platforms where it defaults to "signed char". This matters because the input files are read in a loop that checks for newline or EOF to stop. One of the test input files does not have a newline at the end of the file, so we depend on the EOF test to stop the loop. However, gcc decides that a comparison of a variable of type (implicitly unsigned) char against the negative value EOF is always false and optimizes it away => infinite loop. Building with -fsigned-char fixes the problem.
it should then fail also on ARM, but I haven't checked this before and it does - see http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1745087
Now I'm feeling paranoid. How many of my packages assume that char is signed? I don't know how to begin auditing for this situation.
lfsc-0.20120321-3.fc19 has been pushed to the Fedora 19 testing repository.
lfsc-0.20120321-3.fc19 has been pushed to the Fedora 19 stable repository.
lfsc-0.20120321-3.fc18 has been pushed to the Fedora 18 stable repository.