Re: Arm bof and raspbian.
On Tue, Sep 03, 2013 at 08:22:10PM +0100, peter green wrote:
> Michael Cree wrote:
> >I would presume though that to be hosted at debian-ports a new
> >architecture tag would be needed to avoid confusion with armhf.
> As I have said before i'm strongly against the idea of using a new
> architecture name for a mere change of minimum CPU requirements.
> While it may reduce confusion it would mean that packages that
> should be able to be mixed won't be able to be
Does not multiarch enable that to be done? I thought it was meant to
solve problems such as that.
> and it would also
> mean no upgrade path for existing raspbian users.
Yeah, that does pose a problem.
I'm not a DD, thus am no authority on these matters, nevertheless it
would surprise me to see an armv6 port being permitted on Debian-Ports
with the arch name 'armhf'.
> >do you get many bug reports that result from people having added in armhf
> >from Debian (or Ubuntu, etc.) into apt sources not realising it is not
> >compatible with the Pi?
> I can't think of any bug reports as such. I've seen the odd person
> on IRC and the forums who has broken their system by doing that but
> it doesn't seem terriblly common.
>
> One thing we do is deliberately exclude the debian archive keyring
> from our repository specifically to discourage people from
> installing packages from debian.
Ah, that's why you don't get many problems then.
> >And how do you detect armv7 specific cpu instructions when you build
> >on armv7 infrastructure?
> We use a script which extracts the package and runs readelf on the
> contents. It's not perfect and it can suffer from both false
> positives (when armv7 code is present in the package but not
> required for it to work or where a binary is tagged as armv7 even
> though it doesn't actually contain any armv7 code) and false
> negatives (when a binary is not properly tagged or when a jit
> generates code at runtime) but it mostly does the job.
Fascinating.
> > Or do you re-run test suites after successful builds on an actual Pi?
> No and I can't think of any way to do this within the framework
> debian provides.
Yeah, most builds do not package the test suites so they can't be run
except during building the package. Currently, to easily run the test
suites on a Pi would require re-running the build on a Pi.
I seem to recall seeing some discussion recently about whether it might be
feasible to build armel on armhf hardware (thus solving the problem of speed
and needing oodles of memory for some specific builds) and then rerun the
test suites on actual armel hardware. I can't remember what the outcome of
the discussion was.
So, it seems to me that your requirement that the arch is called 'armhf'
means that it is unlikely an armv6 port would be hosted on debian-ports,
and if an unstable build of Raspbian is not hosted on Debian-Ports I doubt
it would achieve much in the way of the original stated aim of reducing
the difference between unstable and Raspbian.
But if I surmise incorrectly, and it is decided to host a build for armv6
on Debian-Ports, then my offer to host and run a buildd (or two) stands.
Cheers,
Michael.
Reply to: