Mapping the same shared memory twice in one process is stupid, anyway.
Just disable the test on armel and armhf.
Correction: starting from ARMv7, this is supported. So the test can be
enabled for armhf (and arm64).
No, you have to test for the architecture being V7+, not for armhf.
That
On Thu, Feb 07, 2013 at 06:42:20PM +0100, martinwguy wrote:
Mapping the same shared memory twice in one process is stupid, anyway.
Just disable the test on armel and armhf.
Correction: starting from ARMv7, this is supported. So the test can be
enabled for armhf (and arm64).
No, you
Ben,
With Raspbian, we've done our best to maintain maximum compatibility with
Debian and deliver to the Raspberry Pi community a rich Debian experience
to a million+ new Linux users. As the decision for Armhf to support Armv7+
rather than Armv6 was made well before the Raspberry Pi existed
Ben Hutchings wrote:
The wilful incompatibility of Debian derivatives
Raspbian IS compatible with debian armhf in the sense that if your
hardware supports it you can mix debian armhf packages and raspbian
packages. In fact that is how raspbian was built in the first place.
Precedent both
On Thu, 07 Feb 2013 10:58:32 -0800, Mike Thompson wrote:
Preface: Please don't top-post.
Disclaimer: I'm reading this mail because it was CC'd to the
libipc-sharelite-perl maintainers; if there's something we can/should
do: fine. Besides that I have not much knowledge about architecture
specific
On 7 February 2013 19:58, Mike Thompson mpthomp...@gmail.com wrote:
On Thu, Feb 7, 2013 at 10:10 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Thu, Feb 07, 2013 at 06:42:20PM +0100, martinwguy wrote:
For example, the armv6 armhf port for the Raspberry Pi in armhf/V6.
The wilful
On Thu, Feb 07, 2013 at 09:33:54PM +0100, martinwguy wrote:
On 7 February 2013 19:58, Mike Thompson mpthomp...@gmail.com wrote:
On Thu, Feb 7, 2013 at 10:10 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Thu, Feb 07, 2013 at 06:42:20PM +0100, martinwguy wrote:
For example, the armv6
On Thu, Feb 07, 2013 at 09:33:54PM +0100, martinwguy wrote:
There is a way: for Debian armhf to re-target on v6 in a future release.
That would break none of the existing installations and make Debian
more Universal as per its manifesto. With hindsight it would have been
better for Debian
On Thu, Feb 7, 2013 at 12:55 PM, Steve Langasek vor...@debian.org wrote:
There is a way: for Debian armhf to re-target on v6 in a future release.
That would break none of the existing installations and make Debian
more Universal as per its manifesto.
Debian already has a perfectly good
gregor herrmann wrote:
As armhf really describes the ABI rather than the underlying CPU
architecture, it would make our jobs with Raspbian much easier if CPU
architecture dependent packages could test that the architecture is indeed
Armv7+ and not blindly assume armhf implicitly means the system
On Thu, 07 Feb 2013 21:48:24 +, peter green wrote:
Can this test be expressed in some easy terms to be used in
debian/rules?
DEB_HOST_GNU_TYPE ?=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
ARM_VERSION_NUMBER :=$(shell $(DEB_HOST_GNU_TYPE)-cpp -dM /dev/null | grep
-Po
gregor herrmann wrote:
On Thu, 07 Feb 2013 21:48:24 +, peter green wrote:
Can this test be expressed in some easy terms to be used in
debian/rules?
DEB_HOST_GNU_TYPE ?=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
ARM_VERSION_NUMBER :=$(shell $(DEB_HOST_GNU_TYPE)-cpp -dM
On Fri, 2012-06-29 at 06:05 +0100, Ben Hutchings wrote:
I've marked this wontfix, as it's a limitation of the ARM architecture.
Mapping the same shared memory twice in one process is stupid, anyway.
Just disable the test on armel and armhf.
Correction: starting from ARMv7, this is supported.
I've marked this wontfix, as it's a limitation of the ARM architecture.
Mapping the same shared memory twice in one process is stupid, anyway.
Just disable the test on armel and armhf.
Ben.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing
14 matches
Mail list logo
