On 2015-01-05 23:14, Jacco Ligthart wrote:
Hi all,
I just got my raspi to boot from Redsleeve 7 (armv5tel) for the first
time !
Let me be the first to say that I am impressed! Well done!
What I did was build everything in the buildsys-build goup against F18
with the bootstrap option. This caused some minor headache with
incompatible libraries, but in the end proved to be quite do-able.
My second goal was to build everything needed for a minimal install
(with all needed dependencies and build tools). This was quite a pain.
I
would never have guessed how many packages were needed for that and how
many circular references there are in the tree. But with some more
bootstrap builds against F18 and, if that not worked, some packages
from
F18 directly (or from C7 if they were "noarch") I now more-or-less
completed that stage.
As you have already discovered, there are circular build dependencies.
In theory, in all such cases, some packages should have the
--with bootstrap
build option that addresses that. In practice, I seem to recall that
there were cases where that alone wasn't sufficient and additional
manual intervention was required, often with using fedora packages
in the bootstrap build.
While I hope the situation has improved in F18/F19/EL7, it wouldn't
surprise me if a fair amount of manual intervention was still required.
I could not find a handy redhat srpm tree, so I started out with
centos.
I did not do much in the area of de-branding, except for a
redsleeve-release package. This work is therefore still to do.
I'll look into it in a couple of weeks when I'm home. I am traveling at
the moment and have foolishly not taken my Chromebook with me. :(
Generally rebuilding C7 is much easier than C6, as most packages do not
need any patching, they just build.
This is great news. It seems that bumping ARM to a primary arch has
been very beneficial as far as sorting the biggest issues upstream in
Fedora is concerned.
issue list:
- kernel: I found that the initial kernel package builds for arm. the
later ones have an arm incompatible patch (hmm, can't recall what it
was
exactly) also I needed a patch as described here:
https://lkml.org/lkml/2013/12/11/798 In the end my kernel for BCM2835
did not boot on the raspberry pi, I'm back to the binary kernel from
https://github.com/raspberrypi/firmware/
This has been the case before. Kernels up to 2.6.32-200 build and work
(with some manual intervention to build the uImage) for the Kirkwood
devices at least. Unfortunately, the patches introduced and backported
subsequently have been included without any care taken to ensure that
they don't break other architectures, and more concerningly, without
any care taken to ensure they don't introduce bugs in the primary arch
build, with any build option changes.
Some of the fairly eggregious examples of this include:
https://bugzilla.redhat.com/show_bug.cgi?id=773107
https://bugzilla.redhat.com/show_bug.cgi?id=773117
https://bugzilla.redhat.com/show_bug.cgi?id=773118
https://bugzilla.redhat.com/show_bug.cgi?id=773121
The appalling attitude upstream seems to be that they simply don't
care about bona fide bugs and clearly obvious backport mispatches
if the error is not obviously triggered, by pure luck, in the build
configuration they chose.
With other packages, we can at least push fixes upstream to the
project maintainers themselves. But with the PNAELV's messily
patchworked
kernel we have no hope because there is no other "upstream" for the mess
of backports and other patches that aren't in the upstream kernel.
This is half of the reason why the policy with RSEL6 has been to
use the kernel provided with the hardware device and ignore the
upstream EL6 kernel (the other half of the reason is that the base
kernel didn't support most ARM SoCs - at least that part is hopefully
different now).
- numactl: (needed for kernel build) I finally found how to patch for
arm: https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA
I guess this is something we may have to include if kernel builds
are now a workable option.
- mariadb: do not use the latest version, as it will break some build
deps for other packages:
https://bugzilla.redhat.com/show_bug.cgi?id=1166603
It appears there is a patch listed upstream at MariaDB. I think this is
worth including with a .0 package until EL7 includes the fix.
- these packages exclude arm from the available archs (and I do not
care
much as the system runs without): biosdevname, irqbalance,
dmidecode, microcode_ctl, grub2
Most of those aren't relevant on ARM. I'm not sure about irqbalance but
the rest don't seem to be applicable.
- a couple of other packages needed minor patches. most of them were
needed when building against F18 and not when building against RSEL7.
I'll report on those if I find the patches are still needed.
Be careful with this kind of thing - I seem to recall that, for example,
in EL6 there is a bug in the pth package that causes other packages
to segfault when built against it unpatched. I had a problem way back
during testing where I rebuilt pth without any patches (because it built
without any), and suddenly all the other packages that link against
it started segfaulting.
So be careful if patch requirements go away - such cases require
extra regression testing.
- atlas: has hardcoded references to a hard FPU. needs patching.
- qt4: fails to build. I now use the qt4 from F18 which is almost the
same version. this needs some more research
- java fails to build. (time is more than 10 years from present:
1104530400000;
http://mail-index.netbsd.org/pkgsrc-users/2014/12/30/msg020843.html) I
now use java from F18
- libreport fails to build ('json_object_object_get' is deprecated)
again I now use the one from F18
The next couple of days I will try to complete this stage (some more
builds and some install-time dependencies) and put it all online
somewhere. As it is already 5GB I think this will be too much for Al's
hospitality, so I'll probably host it at my home.
I have created you an account on the RS server. More details in
the off-list email.
Next step is then to move my odroid build system to RSEL 7, build
everything again and make some images.
Awesome stuff. :)
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
