Hi All, We'd like to get the first 3.1 point release Dunfell LTS out soon. There is one issue we need to resolve first.
meta-arm has recently been established and the hope is to avoid duplication of a set of recipes in multiple BSP layers, a goal which I believe is in everyone's interests. As with any new layer there are a few growing pains like the removal of python2 dependencies and its made good progress but there is an issue we didn't foresee. Two of the key components that BSPs need from there (tf-a and optee) which are needed for handling boot crypto have dependencies on pyelftools and pycryptodome which were in meta-python in meta- openembedded. In master we moved them to core: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d52929ee35d043211cb012e1b86409599a8b53c6 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1e327abcc92d6575df5c1871e6e1284987b74b87 and upgraded them to the latest versions: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cb94d9019b4d1ce32ad9196cb9c22236631e8781 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7ebe299c00ec309cd46905ad40036d937fe609d7 For master that is easy, problem solved. For Dunfell, I've already seen complaints that using any of the BSPs means adding meta-arm which means adding meta-python which pulls in other chunks of meta-oe. Using a BSP shouldn't require pulling in large numbers of other layers and this defeats what we're trying to achieve with a granular layer model. Had we realised sooner, we likely would have taken this change into dunfell before release but sadly we didn't. The LTS policy is quite clear we now shouldn't make a change like this. Equally, we're early in Dunfell's development, we have an unforeseen issue which is causing users real world pain. Our options are: a) Do nothing b) Move the recipes c) Move the recipes and take the upgrades Given the impact on end users and the desire to have good user experience with our first LTS, as the layer maintainer and having discussed this with others and on the tech call yesterday, I am strongly leaning to b or c. I think this issue isn't one Steve as LTS maintainer or I as OE-Core maintainer can make alone and I'm therefore referring to the TSC. Which TSC is a good question. LTS is owned by YP, the layers by OE. As such I've cc'd both sets of TSC members. I've put it to the architecture list so everyone can see why we're considering this and any discussion on it. Considering the potential regressions, if a user upgrades both layers with these changes things are fine. If the user upgrades meta-python but not OE-Core, they get a build error which is also fine and straightforward to debug. If the user upgrades OE-Core but not meta- python, there is the possibility they could see old versions being used due to layer priority (assuming we upgrade the versions) but this isn't known to cause real world issues. We have the option of the patch to increase the OE-Core version and then bumping the version requirement in meta-python to further improve the user experience. I'm conscious there has already been talk of "favouritism". I would stress this issue has actually been raised by end users and that is the driving factor here. The fact there are interested member companies of YP does actually help in some ways too since it means there are people available to help handle any issues should there be unexpected fallout from this change. If we do this, I would say as a TSC member that we'd do it without setting any precedent, this is being discussed based on the situation at hand, in the future other situations would have to be looked at on a case by case basis. I did quickly sound out the YP TSC at a meeting yesterday and I believe on balance they're in favour of b/c, two of the OE TSC members on the tech call yesterday were also in favour in principle. Whilst that is a majority, that does leave a couple of TSC members who haven't seen the discussion and everyone probably benefits from this having been written down. Does anyone object to doing this? If we do it, do we upgrade the recipes or not? I'm probably leaning towards upgrading too as up to date crypto components are probably better than not updated and some kind of parity with master now will probably catch more potential issues. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1085): https://lists.openembedded.org/g/openembedded-architecture/message/1085 Mute This Topic: https://lists.openembedded.org/mt/74646262/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
