On 11/15/2014 12:47 PM, Jacco Ligthart wrote:
Hi List,
I created updated RPMs since upstream version 6.6 was recently released.
What I miss is an overview of which (S)RPMs are in need of updating, so
I only (mostly) created RPMs that I use myself.
I have a total list of 69 SRPMs that need(ed) to be recompiled. From
this list 60 went relatively easy. I made for these no changes to the
SRPMs. Some (I cant recall which) were depending on other SRPMs in the
same list, so they only got compiled in the second go.
Awesome stuff! I'm going to digest this and roll it into the distro.
== 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?
- 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"?
== 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?
== 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.
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.
== Resources ==
patches to the SRPMs:
http://cdn.opensxce.org/redsleeve/el6/updates-testing/patches/
All (S)RPMs in repo format (Yum!):
http://cdn.opensxce.org/redsleeve/el6/updates-testing/
Since you have been doing a lot of work on this recently, would you like
an @redsleeve.org address forwarded to you?
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
