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. >> 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
