Re: Fw: Re: Cross-compiling debian packages for arm - an automated way? [Raspberry Pi and armhf]
Note: I wasn't originally planning to send this to debian-arm when I thought it was just a question about gnuradio but there is actually a lot more in it than that which I want to answer in a place the arm porters can see it.
Andrew M.A. Cater wrote:
Raspberry Pi came at the wrong time for Wheezy and just at the wrong time for the agreement we'd made with Fedora, Ubuntu and OpenSUSE as to
where armhf would cut in. No one could see that Raspberry Pi would be this big.
mmm, I expected it to be big but nowhere near this big.
Raspberry Pi is _painful_ when compared with Debian when there are no packages made. This is not to decry the efforts of Peter Green and others
who have worked manfully to do their best. We also have the armhf confusion where the two don't interoperate.
Rasbian packages and debian armhf packages should work together. Of
course you can't run the mixture on a Pi because you don't have a
sufficient CPU. This is not unique to raspbian though, the same applies
to say debian i386 vs ubuntu i386.
The real problem is that debian has no good way of handling the case of
ports that are compatible but with different minimum CPU requirements.
Jessie has not yet been built for Raspberry Pi in full.
There are some packages that either failed to build, are being blocked
up because their build-dependencies are not in testing yet or where I
have been unable to fix armv7 contamination issues (atlas) but it's a
fairly small proportion of the whole. Last I looked (admittedly with
wheezy) we actually had better coverage than the official debian arm ports.
Of course someone coming from i386 or amd64 to any arm port (official or
otherwise) will see reduced package availability. That is just the way
things are and will remain unless the arm ports in general get far more
manpower. Mono is a particular sore point for both debian armhf and
raspbian. Chromium is a massive sore point for all debian arm ports.
We follow testing because we felt following both testing and unstable in
the same repo would be difficult (for example what happens if you build
something in your derivative of unstable and due to timings it picks up
a dependency that is not available in testing while the corresponding
package in debian didn't pick up that dependency) and we wanted to be
able to have stable versions available.
Can we suggest a closer working relationship to Raspberry Pi. Debian will produce a
port with armrpi extension or similar and Raspbian can become a Debian Pure Blend or similar.
I don't think introducing yet another arm port will be popular with the
ftpmasters. I also think that using a new port name is the wrong soloution.
Kali - built on the Caixeda multicore server - builds an image for Raspberry Pi - can we do the same for them.
Building images is the easy bit, I presume kali's raspberry pi images
are based on raspbian.
We can and do use armv7 hardware for building raspbian because armv6
hardware is not available with sufficient CPU and ram. I did look at the
calexeda stuff and dismissed it as "nice but prohibitively expensive" (I
was quoted $10K for a basic machine with one CPU card carrying four
SoCs). Currently raspbian wheezy is being built on imx53 based hardware
and while raspbian jessie is being built on imx6 based hardware.
ISA marking is a good technical solution. Producing an rpi build tagged as rpi would at
least show that "our" armhf standard is common across Fedora/SUSE etc.
Yeah, ISA marking would be nice and if someone implements it i'll take a
look at integrating into raspbian. Of course even with the tags an armv6
using the armhf port name can't live in the official archive without
major changes on that side too (unless it replaces the current armhf
port but I don't think that is a very popular option, the debian armhf
port seems to be run by people who are heavilly bought into armv7).
Try doing something they haven't built yet - like Gnuradio :(
There are a couple of issues with gnuradio. One of which is totally
unrelated to whether raspbian is within debian or outside and the other
is only loosely related to it
The first is that gnuradio's arm assembler port has very high CPU
requirements. Too high for raspbian and indeed too high even for debian
armhf. I submitted a patch to make it do a generic build (the same as it
would do on an unknown architecture) and it was accepted so when it hits
testing that should get the package in to raspbian too. Whether it's
performance will be usable is another matter. This is really something
that needs upstream attention if people are going to seriously use
gnuradio on the Pi.
The second is that the gnuradio maintainer doesn't seem to be doing a
very good job of fixing issues that are preventing his package migrating
to testing. It hasn't seen a testing migration since the wheezy release.
The problem is that the Raspberry Pi design committed to using something
that didn't fit with the way the rest of us were going
They wanted low cost and I understand why, it's much easier to convince
yourself or your parents (for a kid) to buy a £30 "toy" than a £120
"toy". Some of them were also broadcom guys and that made it much easier
for them to use broadcom than anything else.
- and then built a user base of millions :(
mmm
Reply to: