summaryrefslogtreecommitdiffstats
path: root/meta/conf/multilib.conf
AgeCommit message (Collapse)Author
2019-09-11conf/multilib.conf: Add ovmf to NON_MULTILIB_RECIPESrbt/mlibRobert Yang
Fixed: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" $ bitbake ovmf lib32-ovmf [snip] ERROR: ovmf-edk2-stable201905-r0 do_deploy_setscene: The recipe ovmf is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /buildarea1/lyang1/rebase-work/test_cc/tmp-glibc/deploy/images/qemux86-64/OvmfPkKek1.key (matched in manifest-qemux86_64-lib32-ovmf.deploy) [snip] Add it NON_MULTILIB_RECIPES to fix the problem since it is a firmware, build multilib for it doens't make much sense. Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
2018-10-20Revert "os-release: avoid multilib expand"Richard Purdie
This reverts commit 591a11ba58ce3c2c147bb1f8202bc6a0092b70eb. This is not needed after the recent os-release fix.
2018-10-03os-release: avoid multilib expandKai Kang
Add os-release to NON_MULTILIB_RECIPES in multilib.conf that do not do multilib expand for os-release. Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-10-01multilib: avoid expanding grub and grub-efi to multilibRobert Yang
It doesn't make much sense to expand them to multilib, and there is an error on qemuarm64 since grub-efi supports arm64, but doesn't support armv7a or armv7ve: * Fixed: MACHINE = "qemuarm64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" MACHINE_FEATURES_append = " efi" $ bitbake lib32-core-image-minimal Also introduced a variable NON_MULTILIB_RECIPES in multilib.conf, so that we can easily add other recipes, such as syslinux if needed. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-23Switch to Recipe Specific SysrootsRichard Purdie
This patch is comparatively large and invasive. It does only do one thing, switching the system to build using recipe specific sysroots and where changes could be isolated from it, that has been done. With the current single sysroot approach, its possible for software to find things which aren't in their dependencies. This leads to a determinism problem and is a growing issue in several of the market segments where OE makes sense. The way to solve this problem for OE is to have seperate sysroots for each recipe and these will only contain the dependencies for that recipe. Its worth noting that this is not task specific sysroots and that OE's dependencies do vary enormously by task. This did result in some implementation challenges. There is nothing stopping the implementation of task specific sysroots at some later point based on this work but that as deemed a bridge too far right now. Implementation details: * Rather than installing the sysroot artefacts into a combined sysroots, they are now placed in TMPDIR/sysroot-components/PACKAGE_ARCH/PN. * WORKDIR/recipe-sysroot and WORKDIR/recipe-sysroot-native are built by hardlinking in files from the sysroot-component trees. These new directories are known as RECIPE_SYSROOT and RECIPE_SYSROOT_NATIVE. * This construction is primarily done by a new do_prepare_recipe_sysroot task which runs before do_configure and consists of a call to the extend_recipe_sysroot function. * Other tasks need things in the sysroot before/after this, e.g. do_patch needs quilt-native and do_package_write_deb needs dpkg-native. The code therefore inspects the dependencies for each task and adds extend_recipe_sysroot as a prefunc if it has populate_sysroot dependencies. * We have to do a search/replace 'fixme' operation on the files installed into the sysroot to change hardcoded paths into the correct ones. We create a fixmepath file in the component directory which lists the files which need this operation. * Some files have "postinstall" commands which need to run against them, e.g. gdk-pixbuf each time a new loader is added. These are handled by adding files in bindir with the name prefixed by "postinst-" and are run in each sysroot as its created if they're present. This did mean most sstate postinstalls have to be rewritten but there shouldn't be many of them. * Since a recipe can have multiple tasks and these tasks can run against each other at the same time we have to have a lock when we perform write operations against the sysroot. We also have to maintain manifests of what we install against a task checksum of the dependency. If the checksum changes, we remove its files and then add the new ones. * The autotools logic for filtering the view of m4 files is no longer needed (and was the model for the way extend_recipe_sysroot works). * For autotools, we used to build a combined m4 macros directory which had both the native and target m4 files. We can no longer do this so we use the target sysroot as the default and add the native sysroot as an extra backup include path. If we don't do this, we'd have to build target pkg-config before we could built anything using pkg-config for example (ditto gettext). Such dependencies would be painful so we haven't required that. * PKDDATA_DIR was moved out the sysroot and works as before using sstate to build a hybrid copy for each machine. The paths therefore changed, the behaviour did not. * The ccache class had to be reworked to function with rss. * The TCBOOTSTRAP sysroot for compiler bootstrap is no longer needed but the -initial data does have to be filtered out from the main recipe sysroots. Putting "-initial" in a normal recipe name therefore remains a bad idea. * The logic in insane needed tweaks to deal with the new path layout, as did the debug source file extraction code in package.bbclass. * The logic in sstate.bbclass had to be rewritten since it previously only performed search and replace on extracted sstate and we now need this to happen even if the compiled path was "correct". This in theory could cause a mild performance issue but since the sysroot data was the main data that needed this and we'd have to do it there regardless with rss, I've opted just to change the way the class for everything. The built output used to build the sstate output is now retained and installed rather than deleted. * The search and replace logic used in sstate objects also seemed weak/incorrect and didn't hold up against testing. This has been rewritten too. There are some assumptions made about paths, we save the 'proper' search and replace operations to fixmepath.cmd but then ignore this. What is here works but is a little hardcoded and an area for future improvement. * In order to work with eSDK we need a way to build something that looks like the old style sysroot. "bitbake build-sysroots" will construct such a sysroot based on everything in the components directory that matches the current MACHINE. It will allow transition of external tools and can built target or native variants or both. It also supports a clean task. I'd suggest not relying on this for anything other than transitional purposes though. To see XXX in that sysroot, you'd have to have built that in a previous bitbake invocation. * pseudo is run out of its components directory. This is fine as its statically linked. * The hacks for wayland to see allarch dependencies in the multilib case are no longer needed and can be dropped. * wic needed more extensive changes to work with rss and the fixes are in a separate commit series * Various oe-selftest tweaks were needed since tests did assume the location to binaries and the combined sysroot in several cases. * Most missing dependencies this work found have been sent out as separate patches as they were found but a few tweaks are still included here. * A late addition is that extend_recipe_sysroot became multilib aware and able to populate multilib sysroots. I had hoped not to have to add that complexity but the meta-environment recipe forced my hand. That implementation can probably be neater but this is on the list of things to cleanup later at this point. In summary, the impact people will likely see after this change: * Recipes may fail with missing dependencies, particularly native tools like gettext-native, glib-2.0-native and libxml2.0-native. Some hosts have these installed and will mask these errors * Any recipe/class using SSTATEPOSTINSTFUNCS will need that code rewriting into a postinst * There was a separate patch series dealing with roots postinst native dependency issues. Any postinst which expects native tools at rootfs time will need to mark that dependency with PACKAGE_WRITE_DEPS. There could well be other issues. This has been tested repeatedly against our autobuilders and oe-selftest and issues found have been fixed. We believe at least OE-Core is in good shape but that doesn't mean we've found all the issues. Also, the logging is a bit chatty at the moment. It does help if something goes wrong and goes to the task logfiles, not the console so I've intentionally left this like that for now. We can turn it down easily enough in due course. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-06meta/scripts: Various getVar/getVarFlag expansion parameter fixesRichard Purdie
There were a few straggling expansion parameter removals left for getVar/getVarFlag where the odd whitespace meant they were missed on previous passes. There were also some plain broken ussages such as: d.getVar('ALTERNATIVE_TARGET', old_name, True) path = d.getVar('PATH', d, True) d.getVar('IMAGE_ROOTFS', 'True') which I've corrected (they happend to work by luck). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-16meta: remove True option to getVar callsJoshua Lock
getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-09-30multilib.conf: Ensure sstate checksums don't change when using this includeRichard Purdie
When enabling multilib.conf, the world was rebuilding due to changes in the pkg-config search path. This doesn't matter so exclude it from the checksums. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-10-01multilib.conf: Ensure MACHINE doesn't change target sigsRichard Purdie
Sysroot paths (which happen to contain MACHINE) should not cause the signatures to change every time MACHINE changes so exclude this from them. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-28multilib: Add TARGET_VENDOR to saved variables listRichard Purdie
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-08-24multilib: let pkg-config find architecture-independent .pc filesRoss Burton
If a multilib package depends on an allarch recipe that installs an architecture-independent .pc file it will not be able to find the .pc file as the recipe gets installed into the MACHINE sysroot but pkg-config looks in the MLPREFIX-prefixed sysroot. Solve this by extending PKG_CONFIG_PATH in multilib environments to include the architecture-independent path in the MACHINE sysroot (sysroots/MACHINE/usr/share/pkgconfig/). Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-10-30multilib.conf: set MULTILIB_GLOBAL_VARIANTS conditionallyPeter Seebach
It is not entirely obvious that all reasonable configurations will have multilib.conf strictly before the file which might want to set MULTILIB_GLOBAL_VARIANTS. The x86-ish values here look like reasonable default guesses, but shouldn't override an explicit setting. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-13bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific ↵Richard Purdie
directory Currently we have a hierarchy of pkgdata directories and the code has to put together a search path and look through each in turn until it finds the data it needs. This has lead to a number of hardcoded paths and file globing which is unpredictable and undesirable. Worse, certain tricks that should be easy like a GL specific package architecture become problematic with the curretn search paths. With the modern sstate code, we can do better and construct a single pkgdata directory for each machine in just the same way as we do for the sysroot. This is already tried and well tested. With such a single directory, all the code that iterated through multiple pkgdata directories and simply be removed and give a significant simplification of the code. Even existing build directories adapt to the change well since the package contents doesn't change, just the location they're installed to and the stamp for them. The only complication is the we need a different shlibs directory for each multilib. These are only used by package.bbclass and the simple fix is to add MLPREFIX to the shlib directory name. This means the multilib packages will repackage and the sstate checksum will change but an existing build directory will adapt to the changes safely. It is close to release however I believe the benefits this patch give us are worth consideration for inclusion and give us more options for dealing with problems like the GL one. It also sets the ground work well for shlibs improvements in 1.6. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-04-13multilib.conf: Workaround opkg multilib issuesRichard Purdie
Multilib with opkg hasn't worked since the --force-overwrite option was dropped in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=88a9f6db3482623c9cb54fb03db1045051cec9f6 Since we merged the libexecdir changes, we also need the --force-maintainer flag to avoid conf file conflicts. Both these changes are suboptimal however the alternative is completely broken and these changes only affect people who have multilibs enabled and use opkg. [YOCTO #3453] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-02-01multilib.conf: add TARGET_ARCH & TARGET_SYS to MULTILIB_SAVE_VARNAMEConstantin Musca
(From OE-Core rev: 81f3dd49693a7ad2e98c182896c98fc71b01592f) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-02-01multilib.conf: Use BASELIB to set baselib, not hardcode the valueRichard Purdie
(From OE-Core rev: 1a97cab9d4856e8948025ce6f406c76a2732ec36) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-12-31multilib: fix allarch/kernel/module-base multilib issuesConstantin Musca
- skip the non-packagegroup allarch recipes in multilib_virtclass_handler - extend PROVIDES/RPROVIDES for allarch recipes which are not packagegroups - use variants from MULTILIB_GLOBAL_VARIANTS (lib32 lib64 libx32) to create additional pkgdata files for multilib allarch: ${pkgdatadir}/${variant}-${PN} and ${pkgdatadir}/runtime/${variant}-${pkg} - use variants from MULTILIB_VARIANTS to create additional pkgdata files for multilib kernel/module-base recipes - add a sanity check to determine if the current multilib is in MULTILIB_GLOBAL_VARIANTS [YOCTO #2918] [YOCTO #3440] [YOCTO #3565] [YOCTO #3568] Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-10-02multilib: Move redefinition of STAGING_DIR_KERNELMark Hatle
If the STAGING_DIR_KERNEL is set in the multilib.conf, then it may be set incorrected. The evaluation happens before TMPDIR and LIBC are defined in other components. Moving the definition process to the multilib.bbclass ensures that everything has been loaded before it is set. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-08-02Complete recipe enablementBogdan Marinescu
RP: The list of recipes in multilib.conf needs to go away and we need to just be able to extend all recipes with the multilib class. Tested by building and running lib32-core-image-sato-sdk. [YOCTO #1563] Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-07-27gobject-introspection: Drop the recipe, it has never worked and if it does ↵Richard Purdie
cross compile, we can add it back Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-07-27eds-tools: Drop this recipe, its inapproriate in OE-CoreRichard Purdie
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-07-19Multilib build fixesBogdan Marinescu
1. STAGING_KERNEL_DIR was getting an invalid MLPREFIX. Fix this by forcing the expansion in multilib.conf. 2. Added multilib rule for 'perf'. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-07-19eggdbus: remove, nothing uses itRoss Burton
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-07-10libgsmd - removePaul Eggleton
This project has been unmaintained for some time, and even the OpenMoko project is not using it any more (in favour of FSO). Since we have ofono in OE-Core which replaces and surpasses its functionality, we can remove libgsmd. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-29build-appliance-image: rename from self-hosted-imageValentin Popa
(-) renamed self-hosted-image to build-appliance-image (-) replaced build-appliance-image description [YOCTO #2636] Signed-off-by: Valentin Popa <valentin.popa@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-15multilib.conf: Add the support of multilib for lsbinitscriptsXiaofeng Yan
Add the multilib support for this package to multilib.conf because error will appear when building an lib32-core-image-lsb without this patch. [YOCTO #2571] Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-18multilib.conf: Added multilib support for kmod.Lianhao Lu
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-26evolation-data-server: Rename from eds-dbusSaul Wold
[YOCTO #2316] Signed-off-by: Saul Wold <sgw@linux.intel.com>
2012-03-08multilib: extend all recipes in multilib.confDongxiao Xu
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-07task-core-tools: Divide it into 3 recipesKhem Raj
task-core-tools-debug, task-core-tools-profile, task-core-tools-testapps otherwise if we choose one through PACKAGE_GROUPS all packages are built since they are in same recipe. Signed-off-by: Khem Raj <raj.khem@gmail.com>
2012-01-11multilib.conf: Clean up file and add missing entries for various dependenciesRichard Purdie
This patch adds in various missing dependencies to ensure the set of recipes listed for multilib support can be cleanly built. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-12-21multilib.conf: Enable shadow-sysroot and libffiRichard Purdie
Enable these two core dependencies for multilib builds, fixing multilib build failures that were occurring. I've checked and the recipes are multilib capable. [YOCTO #1835] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-11-30clutter-box2d: drop unbuildable clutter-box2d-1.6_0.10.0Joshua Lock
It's very old at this point and doesn't build with recent clutter Signed-off-by: Joshua Lock <josh@linux.intel.com>
2011-11-30multilib.conf: remove clutter-1.6 and add clutter-1.8Joshua Lock
clutter-1.8 is the future here. Signed-off-by: Joshua Lock <josh@linux.intel.com>
2011-11-10gconf: add upstream GNOME gconf 3.2.3 and drop gconf-dbusJoshua Lock
The D-Bus backend has been integrated into upstream GConf so we can switch to upstream and drop gconf-dbus. I've gone for a release in the 3.2 series as we disable Gtk+, and therefore are not impacted by the gtk+3 changes, and the D-Bus backend was unstable before this release. Signed-off-by: Joshua Lock <josh@linux.intel.com>
2011-10-11xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-liteMartin Jansa
* xserver-xorg is closer to upstream naming and that's how it's named in OE-classic and meta-oe? It would make meta-oe transition easier and better to do it now then convert meta-oe to xserver-xf86 and then rename it back later. Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
2011-09-28multilib: remove the multilib handling to allarchDongxiao Xu
currently we have allarch type of recipes, which may still have architecture dependency, like x11-common. So we need to drop the handling to allarch in multilib case. Also remove the PV postfix in python-pygobject DEPENDS, since multilib code will treat a native package multilib capable. [YOCTO #1497] [YOCTO #1498] Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
2011-09-15task-core: split into task-core-console and task-core-x11Paul Eggleton
[YOCTO #1481] Since tasks are referred to almost exclusively via RDEPENDS, and bitbake will build an entire task recipe when only one of its task packages are actually needed, building a console-only image that uses task-core-apps-console (or less directly, has apps-console in its IMAGE_FEATURES) will cause a build of a whole list of X11 applications that aren't needed. Splitting the task-core recipe into X11 and console portions prevents this issue. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2011-09-13multilib: Remove recipe from multilib.conf that inherits allarchDongxiao Xu
Recipes like update-rc.d and qemu-config inherit "allarch", thus we shouldn't add multilib BBCLASSEXTEND for them in multilib.conf. Besides, we need to add multilib packages as the RPROVIDER contents for those recipes, in order to avoid the NoProvider error when parsing. [YOCTO #1471] Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-07multilib: Remove the multilib extension for linux-yoctoDongxiao Xu
Kernel should be unique in a multilib system, so we remove the linux-yocto's extension in multilib.conf Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-02multilib: Only build one kernelRichard Purdie
For a given system we only want one kernel to be built. This change makes the main kernel recipe provide all of the provides of the various enabled multilibs hence allowing it to fulfil all the appropriate dependencies. To make this work a global multilib class file needed to be created. This patch also enables this multi provider functionality for "allarch" packages. [YOCTO #1361] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-02multilib: extend multilib prefix for libsdlDongxiao Xu
libsdl is required by sato image, so extend it for multilib. Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
2011-09-02multilib: Using different sysroot for multilib recipesDongxiao Xu
Thinking of the senario that, if we already built out a 64bit image along with the full toolchain bootstrapped, then we need to build some 32bit libraries, which needs lib32 versions of gcc and eglibc. These toolchain recipes will bootstrap again in the same sysroot, resulting that lib32-gcc-cross-initial will find some macros owned by eglibc have already been defined and thus it includes non-existed headers that provided by later lib32-eglibc. The solution for the above issue is to use different sysroot for multilib recipes, here we add ${MLPREFIX} in front of the machine specific sysroot directory name. [YOCTO #1372] Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
2011-08-15utils.bbclass/multilib.class: Added misc supporting functions.Lianhao Lu
1. Added variable MULTILIB_VARIANTS to store all the instance variants for multilib extend. 2. Added function all_multilib_tune_values to collect the variable values for all multilib instance. 3. multilib bbclass handler will save the orignal value of all variables defined in MULTILIB_SAVE_VARNAME. Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
2011-08-08multilib.conf: Supported multilib extend in more recipes.Lianhao Lu
Added more recipes supporting multilib extend. Signed-off-by: Lianhao Lu <lianhao.lu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-07-27multilib: Add support for compiling recipes against multiple ABIsRichard Purdie
This patch adds the core multilib class which can be used along with a parameter specifying the mutlilib to use in BBCLASSEXTEND. The MLPREFIX variable is added and can be used in cases where its too difficult to dynmaically work out where a mutltilib prefix is needed to be added to a variable. This includes: * SHLIBSDIR and PACKAGE_ARCH fixes from Lianhao Lu. * PACKAGE_DYNAMIC mapping from Yu Ke * PACKAGE_INSTALL mapping from Yu Ke * RPROVIDES mapping from Yu Ke * TARGET_VENDOR fix from Mark Hatle * Ignorning *-native-runtime dependnecies as well as *-native from Yu Ke * Map PKG and ALLOW_EMPTY from Dongxiao Xu * Ensure RCONFLICTS and PKG field dependencies are remapped (from Dongxiao Xu) * Ensure PN and MLPREFIX are set at the same time to ensure consistent BPN values (Yu Ke) Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com> Signed-off-by: Lianhao Lu <lianhao.lu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>