On 11/15/2014 06:07 PM, Jacco Ligthart wrote:
== issues in current RedSleeve ==
I found two issues in the existing RedSleeve RPMs:
- somehow java-1.7.0-openjdk-devel cannot be installed automatically in
mock. no clue why. I could install this package by hand in the chroot
and work from there
What error are you seeing? Which version of mock are you using? What
kernel version / hardware? Can you attach the logs from the results
folder?
* Error: No Package found for java-1.7.0-openjdk-devel
* mock-1.1.41-1.el6.noarch
(http://cdn.opensxce.org/redsleeve/el6/epel-testing/noarch/mock-1.1.41-1.el6.noarch.rpm)
* raspberrypi-kernel-3.12.30+-1.20141025gitc23c002.armv5tel
see attached java*_root.log line 624
after the error I used mock --install <local_java_rpms> to install and
then mock --no-clean java*src.rpm
I see. So the problem appears to be that the repository index doesn't
seem to know about java-1.7.0-openjdk-devel. Very strange, especially
since I just checked the contents of the xml index and it's definitely
listed in there.
probably also interesting is the attached mock.cfg
I strongly recommend you keep a local copy of the repository for
building. It tends to make things a lot faster than pulling packages
from the internet all the time. You'd also get better ability to
troubleshoot issues like this that may or may not be to do with the
repository.
- ruby has a disagreement in armv5tel-linux-eabi vs armv5tel-linux in
such a way that this RPM cannot be used for building other packages.
Both issues are resolved by creating newer packages.
Can you elaborate what you mean by "newer packages"?
well, I build java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el6.0.src.rpm and
ruby-1.8.7.374-2.el6.1.src.rpm which are both newer than what's now in
RedSleeve. The ruby one with my patches for the -eabi issue. put the
result in my local repo and voila, issues gone :)
Which definitely seems to point to a repository issue, which I have no
immediate explanation for. I just tried installing
java-1.7.0-openjdk-devel from the primary repository and that seems to
work fine.
== patched SRPMs ==
I had 4 SRPMs that did not compile directly, but needed patching:
binutils-2.20.51.0.2-5.42.el6.0.src.rpm:
same patch as in the previous version
java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el6.0.src.rpm:
ExclusiveArch
pam-1.1.1-20.el6.0.src.rpm
kernel-headers dependency (as previous)
ruby-1.8.7.374-2.el6.1.src.rpm
no pthread
add '-eabi' to some paths
Is this different to what the older patch does?
Can you please update the patches wiki page?
yes.
The issue is that somehow files end up in a directory
/blah/armv5tel-linux-eabi but that the %files section expects them to be
in /blah/armv5tel-linux . This results in "file not found" errors. The
previous patch moved the files from one to the other so that there are
no longer file not found errors. Downside is that ruby could not find
the files anymore. This patch changes the %files section, so that there
are no errors and ruby *does* work :)
Has the new spec file changed the path in %files section, or has
something started returning a different arch spec?
== SRPMs with errors ==
The following three SRPMs gave errors that I could not quickly resolve.
they will need more research:
boost-1.41.0-25.el6.src.rpm:
after disabling openmpi (as in the previous version) the build breaks
with
/builddir/build/BUILD/boost-1.41.0.cmake0/boost/math/tools/promotion.hpp:
In
instantiation of 'boost::math::tools::promote_args<long double, float,
float, float, float, float>':
/builddir/build/BUILD/boost-1.41.0.cmake0/libs/math/src/tr1/acoshl.cpp:16:
instantiated from here
/builddir/build/BUILD/boost-1.41.0.cmake0/boost/math/tools/promotion.hpp:140:
error: invalid application of 'sizeof' to incomplete type
'boost::STATIC_ASSERTION_FAILURE<false>'
I seem to recall that boost package introduced a FTBFS regression on
ARM as of version 1.41.0-18. :(
It may be worth looking into what changed between 17 and 18 and see if
the patch that breaks it can be fixed or backed out.
python-2.6.6-52.el6.src.rpm:
RPM build errors:
Macro %with_valgrind_config_opt has empty body
File not found:
/builddir/build/BUILDROOT/python-2.6.6-52.el6.arm/usr/lib/python2.6/lib-dynload/ossaudiodev.so
File not found:
/builddir/build/BUILDROOT/python-2.6.6-52.el6.arm/usr/lib/python2.6/plat-linux2
Hmm... This is a new one.
I am speaking from memory here, so take this with a pinch of salt, but
IIRC valgrind used to be broken and thus disabled on ARM. There is a
valgrind that builds (not 100% sure it works perfectly as I haven't
used it, but it does build) in the EL6 repository. It's possible the
SPEC file makes assumptions about availability/functionality of
valgrind which could be related to this.
>
It was my impression that the valgrind issue was more of a warning. That
this was not really breaking the build. I do not understand the
ossaudiodev.so thing (I only found "Failed to find the necessary bits to
build these modules") the plat-linux2 might be me running a 3.x kernel
in stead of 2.6.x
I attached the build log.
Off the top of my head, check the arch specific dependency list. It's
possible that on ARM some dependencies are excluded and they provide
what it takes to build the missing modules later.
You could either try to add those so that the modules can build, or if
they just end up being broken, add configuration options to exclude
building them.
util-linux-ng-2.17.2-12.18.el6.src.rpm:
build error:
libtool: link: armv5tel-redhat-linux-gnueabi-gcc -std=gnu99
-fsigned-char -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -march=armv5te
-o nsenter nsenter.o exec_shell.o strutils.o
nsenter.o: In function `main':
/builddir/build/BUILD/util-linux-ng-2.17.2/sys-utils/nsenter.c:264:
undefined reference to `setns'
collect2: ld returned 1 exit status
I have a suspicion I know what is going on here. I think the setns
requirement is provided by later kernel headers than what we have
available. This may be fixable by putting headers from a later kernel
in place for the build.
But - I have no idea if the resulting binary will then work correctly
on an older kernel. It might work, it might not - I have no idea. I
have a vague recollection from a different bug in a different project
a while back that this might have been added around 2.6.32-431 or so.
== ToDo SRPMs ==
due to long build times and difficult patching I have not yet finished
building:
gcc-4.4.7-11.el6.src.rpm
glibc-2.12-1.149.el6.src.rpm
What hardware are you using? Would it help if I sent you a GuruPlug or
a SheevaPlug?
The GuruPlug I have has a UK plug on it, but it has 2xNIC, 2xUSB and
eSATA. Unfortunately, you will need an external JTAG/serial console
adapter for it.
SheevaPlug has 1xNIC, 1xUSB and no eSATA, but I _think_ I think I have
an EU power plug for one somewhere (I use US plugs on them with a UK
adapter as it is less bulky than EU plug with an UK adapter). You only
need a mini-USB cable to get to the console on those, no external
adapter box needed.
Thanks for the offer. But I think I like your previous offer of access
to your build system better.
Right, I better do something about that, then. Give me a few days to get
it up and running in a DMZ.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
