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 and it would also mean no upgrade path
for existing raspbian users.
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.
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.
Is it possible to somehow limit a chroot to
trap on invalid armv6 instructions despite running on armv7?
Not that i'm aware of
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.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
