On 09/03/2014 09: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.
CentOS project won't be doing an EL6 port, they are working on the EL7 port.
Also, having looked into this at some length, Koji is an immensely
complicated, very patchy piece of software with little or no practical
use and no advantages over a few bash scripts containing 100 lines or
less. I use such scripts and mock.
There is a commonly held misconception that Koji performs dependency
checking, and thus can speed up builds of large package sets. It does no
such thing. I keep meaning to write something that will analyze all the
spec files and attempt to come up with a source and binary dependency
tree, but it is not a trivial piece of work. CPU time is cheap (even
when it's slow ARMs) and man-hours are expensive, so nothing happens.
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/
I found I didn't need any patches to get the newer gcc to build. The
problem is that it didn't work.
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.
34 hours sounds like a lot. What did you try to build it on? I seem to
recall it took well under a day on a DreamPlug with an eSATA disk.
glibc seems much more difficult.
Sufficiently so that I gave up.
I've read multiple bugzilla items and mailinglist posts (often from you)
but it does not seem to have a conclusion.
The conclusion is that upstream has not even a slightest interest in not
breaking other architectures with their often buggy patches. As an
unsanctioned distro port community we can try to fix some of it (as
demonstrated by the patches listed on the wiki), but ultimately unless
we can muster a volunteer maintenance effort in the hundreds of man
hours I don't think we can hope to have the latest versions of
everything properly de-bodged, fixed and working all the time.
In fairness, however, there are very few packages that are this
problematic - the only ones that come to mind are the kernel, glibc, and
maybe OpenJDK.
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.
I'm not 100% sure. I think it was needed in the earlier builds but
stopped being required in later ones.
Regarding glibc, note that there is an additional code tarball required
(or at least it was) for some secondary arches, including ARM.
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.
Indeed, that is where the line between a remix and a fork starts to get
crossed.
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.
It depends on whether the changes are in the core distribution or
provided in a separate "extras" repository. That way the purists can
only use the core, and those slaving to version numbers can have the
later, non-upstream packages if they feel they really need them.
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?
Most, IIRC. I seem to recall that Firefox was among those that failed to
build, but I think the problem was more widespread. I have a feeling it
was due to some missing headers / atomics.
* 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.
Perhaps. I seem to recall, however, that EL build numbering is not
related to Fedora build numbering, so even though the number may be
bigger it doesn't necessarily mean it is a superseding version.
related question, do you have a guestimate for compile time of java?
Not off the top of my head.
* 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)
In a lot of packages there are flags that control whether the build is a
bootstrap build or a regular build. Bootstrap builds are more limited
with fewer dependencies, but they are usually only required when
bootstrapping from scratch. When you already have a complete working
distro it is less of an issue.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
