linux/poky.git/meta/classes/useradd-staticids.bbclass, branch 2.3_M2

useradd-staticids: Fix groupadd

2017-01-26T10:44:27+00:00

When a group name is duplicated between USERADD_PARAM and GROUPADD_PARAM, this class tries to add it twice which results in failure of the groupadd command. (From OE-Core rev: 5b84cc895500c28674d2a7b7c2dd618cf8fb30e9) Signed-off-by: David Vincent Signed-off-by: Richard Purdie

extrausers: Use static ids when available

2017-01-19T22:47:20+00:00

When creating users at the image level using extrausers class, the current behavior is to ignore the status of USERADDEXTENSION. This could lead to undefined behavior when static ids are expected but the system falls back to dynamic ones. (From OE-Core rev: 331140e892f84b70bced44a0b5d14f32ec95042e) Signed-off-by: David Vincent Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T10:23:23+00:00

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\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids.bbclass: catch missing uid/gid exceptions

2016-10-28T15:15:20+00:00

The change to get rid of FuncFailed exceptions changed the behavior of how missing uid/gid error are be handled. Instead of catching the exception and handling that via bb.parse.SkipPackage(), a fatal error was called. This won't work with recipes that are unused and therefore do not have UID/GIDs defined. The problem triggers when parsing all recipes (e.g., oe-selftest runs bitbake -p). The right way to handle this is to raise bb.parse.SkipPackage(). This will error correctly once the recipe is needed. (From OE-Core rev: 55384cfc743a12a78bef736ee08ed453b6a6a21e) Signed-off-by: Mikko Ylinen Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailed

2016-10-04T15:29:04+00:00

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: e507cb978fd52164beb28324933cb3d5e368c3ab) Signed-off-by: Ulf Magnusson Signed-off-by: Richard Purdie

useradd-staticids.bbclass: trigger reparsing when table files change

2016-08-01T10:47:13+00:00

This addresses (among others) the following problem: - USERADD_ERROR_DYNAMIC=error causes a recipe to get skipped because a static ID entry is missing - the entry gets added to the file - using the recipe still fails with the same error as before because the recipe gets loaded from the cache instead of re-parsing it with the new table content (From OE-Core rev: 799c93592a9aac571d6dc05529437c0eec7b08b8) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids: use map() instead of imap()

2016-07-12T22:12:00+00:00

In Python3 the itertools module's imap function has been migrated to the globalname space as map(). Calling itertools.imap() will fail because it no longer exists. (From OE-Core rev: da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6) Signed-off-by: George McCollister Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Allow missing UIDs/GIDs to generate warnings

2016-06-17T16:14:55+00:00

Previously when USERADD_ERROR_DYNAMIC was set to "1", an exception was raised if no numeric UID/GID could be determined for a user/group. Now it is possible to set it to either "error", which results in the old behavior, or "warn" in which case a warning is issued instead. For backwards compatibility reasons, it is still possible to set USERADD_ERROR_DYNAMIC to "1" and get an exception in case of failure. (From OE-Core rev: 58c82f79efee8e68fa63b96a32f54660afb15769) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Restore failure on missing UIDs/GIDs

2016-06-17T16:14:55+00:00

A regression was introduced with commit 3149319a whereby setting USERADD_ERROR_DYNAMIC no longer resulted in an error for users and groups that were missing numeric UIDs and GIDs but were not mentioned at all in any passwd or groups file. [YOCTO #9777] (From OE-Core rev: adc0f830a695c417b4d282fa580c5231e1f0afbe) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Avoid FutureWarning about split()

2016-06-12T22:47:19+00:00

This avoids the following warning with Python 3.5: /usr/lib64/python3.5/re.py:203: FutureWarning: split() requires a non-empty pattern (From OE-Core rev: a7a783c30cc58008f0e070dad39d40038e0a5eb5) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie