[Raspbian-devel] Fw: Re: Cross-compiling debian packages for arm - an automated way? [Raspberry Pi and armhf]

[peter green]

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