What about enabling ASSUME_PROVIDED functionality also for nativesdk- components?
Andrej On 08/23/2017 09:00 PM, Khem Raj wrote: > On 8/23/17 5:44 AM, Richard Purdie wrote: >> On Wed, 2017-08-23 at 14:07 +0200, Andrej Valek wrote: >>> I have found out that even master with HOSTTOOLS does not fix my >>> problem. >>> We use ASSUME_PROVIDED for ca-certificates-native due to corporate >>> environment CAs. >>> Since nativesdk-ca-certificates depends on ca-certificates-native >>> whichis not built, so it could not be found. Unfortunately adding >>> update-ca-certificates to HOSTTOOLS is not working, since build user >>> does not have permissions to modify system CAs and also is in >>> /usr/sbin/ which is not in usual system path. >>> >>> Therefore I think that this patch applies for master branch, too. >>> Possible improvement would be also removing ca-certificates-native >>> from DEPENDS of class-nativesdk. >>> >>> Solution of installing corporate CAs within OE recipe does not seem >>> to be ideal, because the CAs have short expiration date. So using >>> system CAs assures reachability of resources over https. >>> We had to do this because svn fetcher uses https without option to >>> ignore errors (unlike wget which ignores certificates by default). >> >> Reading this made me realise this is a pretty complex issue. In general >> we cannot assume that we can execute nativesdk binaries. Since ca- >> certificates is allarch and we're executing an sh script, this is less >> of an issue in this very specific case. There is a binary involved, >> c_rehash and we do need to make sure there are the right -native >> dependencies to get that. > > > c_rehash comes from openssl-native in this case. > >> >> There is a further complication with regard to the paths used, ca- >> certificates-native will use one set of paths, nativesdk-ca- >> certificates will use a different set and target ca-certificates a >> differnt set again. >> >> I suspect you're right and the ca-certificates-native dependency may be >> incorrect and the certs installed into sdks may be broken too. If the >> native sysroot and target sysroot layouts don't match, that would cause >> an additional source of errors. >> >> So some changes in this area does appear to be needed... >> >> Cheers, >> >> Richard >> >> > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
