[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :(

Reply to: