linux/poky.git/meta/classes/useradd-staticids.bbclass, branch morty-next

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

useradd-staticids.bbclass: Make sure opened files are closed

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

This avoids warnings about unclosed files with Python 3. (From OE-Core rev: 77adf8341694b76cf58b7a31dda18b85b3eb87a2) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Remove unnecessary spaces

2016-01-18T11:47:07+00:00

This removes unnecessary spaces inserted before semicolons in the modified USERADD_PARAM_${PN} and GROUPADD_PARAM_${PN} variables. This should not affect the handling of the variables as the only one that actually sees the semicolons is the code in useradd.bbclass that uses cut to split the variables at them, and any whitespace preceeding or following the semicolons will be properly ignored. (From OE-Core rev: acc17ef91a6f506e3cacdc0d4ebfa268b3f3affd) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Read passwd/group files before parsing

2016-01-18T11:47:06+00:00

Read and merge the passwd/group files before parsing the user and group definitions. This means they will only be read once per recipe. This solves a problem where if a user was definied in multiple files, it could generate group definitions for groups that should not be created. E.g., if the first passwd file read defines a user as: foobar::1234:::: and the second passwd file defines it as: foobar:::nogroup:The foobar user:/:/bin/sh then a foobar group would be created even if the user will use the nogroup as its primary group. (From OE-Core rev: 3149319ad997379a01d87f2b1b5d14f66541997f) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Simplify the logic for when to add groups

2016-01-18T11:47:06+00:00

The original code was near impossible to follow, and missed a couple of cases. For example, if one added the following line to the passwd file specified in USERADD_UID_TABLES: foobar:x:12345:nogroup::/:/bin/sh and then specified the user as: USERADD_PARAM_${PN} = "--system foobar" one would then assume that the foobar user would be created with the primary group set to nogroup. However, it was not (the primary group would be foobar), and the only way to get it correct was to explicitly add --gid nogroup to the USERADD_PARAM_${PN}. (From OE-Core rev: e98e98ce65cf9ffdef29462310a622ffddd1412b) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie