On 09/03/2014 04:52 PM, Jacco Ligthart wrote:
On 08/26/2014 12:00 PM, Gordan Bobic wrote:
Thanks for doing this I'll review these when I'm back, rebuild, and
include in the official repository.
If I were to make an armv5tel machine (or several) remotely
accessible, along with the build scripts I use, would you be interest
in becoming a regular co-maintainer?
Not sure how much time I can dedicate to this. My work will soon require
much more of my time than the last couple of weeks.
Obviously, you also have quite some time restrictions, so maybe a bit of
shared load is a good idea.
I remember seeing requests for ARM hardware on the CentOS list. Is there
any progress there? It might be much easier if we could use their koji.
There is an Centos-arm list: [email protected]
But no activity on it. I need to do some postings, but I have IEEE 802
wireless coming up in Athens in a week, then the Holidays hit...
next I'll try to build gcc and glibc.
Best of luck - I never managed to get glibc to build. There are extra
ARM patches required (look at the F12/F13 glibc, which is the most
recent distribution that ships with glibc 2.12 - it comes with an
extras source tar ball).
I'll be more interesting to see the documentation of you manage to get
it to work, though.
gcc build fairly easy. It needed actually less patches than previously.
All the libgcc_post_upgrade stuff is now in the upstream SRPM. The patch
I used is here:
http://cdn.opensxce.org/redsleeve/el6/updates-testing/patches/
The only issue is that gcc needs 34 hours of compile time. And the first
two tries were aborted by the OOM-killer :( In the end I build it on the
raspi image on KVM on intel, with swap on a tmpfs.
glibc seems much more difficult.
I've read multiple bugzilla items and mailinglist posts (often from you)
but it does not seem to have a conclusion.
I'll try some more and get back with details in a separate post.
Quick question though, can you remember why the
"gcc44-libgcc-fno-stack-protector.patch" is commented out in the gcc
.spec? The more I read the more I think that could be needed for glibc
building.
Another option might be to maintain an additional repository with
packages that are beyond the EL6 versions because of the virtual
impossibility of maintaining EL6 packages for architectures that
aren't supported upstream and are extensively broken by distro
specific patches beyond a certain version (e.g. the kernels beyond
2.6.32-200 are completely broken on anything except x86, and even
there they may contain bugs that are avoided by pure configuration
lottery as exemplified by the bugzilla link I sent earlier. In the
extras repository case, it may be easier to get a much newer glibc
working that doesn't require extra patching (e.g. look at the steam
x86 mini-repository I put together for el6 here:
http://ftp.redsleeve.org/pub/steam/ )
That's what I had in mind for specific raspberry things like the kernel
and other /boot stuff. For other items I hesitate a bit. There is a
point where you get far enough from upstream that you lose the
advantages of following them and are basically creating your own distro
with a lot of extra work involved. Not sure where that point is though.
More recent gcc srpm builds find out of the box, but is severely
broken and fails to build various packages.
Do you have examples of those packages, so I can test my gcc version?
* when building tzdata, I found that asking for java-devel results in
installation of java-1.7.0-openjdk instead of a -devel package (message:
Tables Package java-1.6.0-openjdk-devel is obsoleted by
java-1.7.0-openjdk). I think this is an error in the java-1.7.0 build.
On a related note, the el6 java 1.7.0 package was ahead of upstream el6,
however the latest java from upstream catched up and is now at a still
more recent version
Indeed, look at the packages page on the wiki. I had to leapfrog the
EL6 version because that comprehensively failed to build due to too
many issue to chase and fix.
I've seen the page. I reread my text and it is a bit vague. The only
thing I wanted to say is that the most recent version from upstream
leapfrogs the latest RSEL. So there is a chance that this will compile
easier.
related question, do you have a guestimate for compile time of java?
* in ruby the .spec moves /usr/lib/ruby/1.8/armv5tel-linux-eabi to
/usr/lib/ruby/1.8/armv5tel-linux. This breaks building rpms depending on
ruby (notably qpid from MRG)
Patches welcome. :)
This is easy one: remove hunk #3 from
http://ftp.redsleeve.org/pub/patches/ruby-1.8.7.352-13.el6.src.rpm.patch
I did the reverse on an installed version to get qpid build against
ruby. (I did not build ruby)
Jacco
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
