Re: [gentoo-dev] [RFC] subprofiles for ARM architecture
On Saturday, August 13, 2011 01:41:54 Arun Raghavan wrote: On 7 August 2011 17:20, Raúl Porcel wrote: With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. I think this makes sense. What would the policy be on initial keywords if upstream doesn't explicitly specify what sub-arches are supported? Just enable on all till someone says it doesn't work or test on all of them first or ...? we arent talking diff keywords ... there will still be just arm. the simplest approach is probably fine: don't worry about masking unless someone complains or the dev in question feels like digging into things. it's not like having the package generally available will cause people any additional problems ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] subprofiles for ARM architecture
On Sunday, August 07, 2011 07:50:42 Raúl Porcel wrote: The problem is that during the history of the ARM architecture(according to the wikipedia, the architecture was introduced back in 1981) there has been some subarchitectures(the most available are armv4, armv4t, armv5t, armv6j and armv7-a) which include new functions that is not available on the previous subarchitecture. Something like SSE, SSE2, SSE3, etc... but in arm is called SIMD, NEON, etc... Apart from that, there are some apps that only work in one subarchitecture because it uses some capabilities only available on that subarchitecture and newer. Which is the case of valgrind. It only works with armv7-a. Also there's www-client/chromium, which later versions only work on =armv6j. With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. We build stage3s for the armv4t, armv5te, armv6j, armv7a subarchitectures, and we'll make them use the profiles. makes sense to me -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] subprofiles for ARM architecture
On Sun, Aug 07, 2011 at 01:50:42PM +0200, Raúl Porcel wrote: With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. I suggest you go and look at the solution that was in place for MIPS subarches as well to take that into consideration. I think it still exists in: mips-sources, arcboot, arcload. The latter two being bootloaders that need to be specifically configured for the subarch else they just don't work. I think the PPC64 folk also experimented for a while with something for the Cell chip. In general, +1 on the subprofile, but not so much on the masking, unless cross-compile isn't an option at all. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [RFC] subprofiles for ARM architecture
On Sat, Aug 13, 2011 at 7:21 AM, Robin H. Johnson robb...@gentoo.org wrote: On Sun, Aug 07, 2011 at 01:50:42PM +0200, Raúl Porcel wrote: With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. I suggest you go and look at the solution that was in place for MIPS subarches as well to take that into consideration. I think it still exists in: mips-sources, arcboot, arcload. The latter two being bootloaders that need to be specifically configured for the subarch else they just don't work. We did have that, but I removed it because the profiles weren't maintained. On MIPS, the purpose was to simply prevent things like arcload from being installed on systems where arcload doesn't work/isn't useful, which is only minimally useful itself. ARM seems to have a much better reason for doing this -- packages won't even compile on some subarchs. Matt
Re: [gentoo-dev] [RFC] subprofiles for ARM architecture
On 7 August 2011 17:20, Raúl Porcel armi...@gentoo.org wrote: [...] With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. I think this makes sense. What would the policy be on initial keywords if upstream doesn't explicitly specify what sub-arches are supported? Just enable on all till someone says it doesn't work or test on all of them first or ...? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
[gentoo-dev] [RFC] subprofiles for ARM architecture
Hi, The other day Markus(maekke) found an issue i encountered two years ago. An app supports only a subarchitecture of the ARM architecture. For those that don't know the ARM architecture, its an architecture which is mostly used on embedded and/or mobile devices(cell phones, mostly), also there's now some stuff called smartbooks(Efika MX smartbook, Asus Transformer, etc...) and smarttops(Efika MX smarttop). The problem is that during the history of the ARM architecture(according to the wikipedia, the architecture was introduced back in 1981) there has been some subarchitectures(the most available are armv4, armv4t, armv5t, armv6j and armv7-a) which include new functions that is not available on the previous subarchitecture. Something like SSE, SSE2, SSE3, etc... but in arm is called SIMD, NEON, etc... Apart from that, there are some apps that only work in one subarchitecture because it uses some capabilities only available on that subarchitecture and newer. Which is the case of valgrind. It only works with armv7-a. Also there's www-client/chromium, which later versions only work on =armv6j. With subprofiles we could keyword such packages, mask them globally on arm and unmask it on the subprofile of the subarchitecture that supports it. We build stage3s for the armv4t, armv5te, armv6j, armv7a subarchitectures, and we'll make them use the profiles. Thanks
