linux/poky.git/meta/classes/useradd-staticids.bbclass, branch 4.2_M3

classes: Add SPDX license identifiers

2022-08-12T10:58:01+00:00

As stated in our top level license files, the license is MIT unless otherwise stated. Add SPDX identifers accordingly. Replace older license statementa with the standardised syntax. Also drop "All Rights Reserved" expression as it isn't used now, doesn't mean anything and is confusing. (From OE-Core rev: 081a391fe09a21265881e39a2a496e4e10b4f80b) Signed-off-by: Richard Purdie

classes: Add copyright statements to files without one

2022-08-12T10:58:01+00:00

Where there isn't a copyright statement, add one to make it explicit. Also drop editor config lines where they were present. (From OE-Core rev: 880c1ea3edc8edef974e65b2d424fc36809ea034) Signed-off-by: Richard Purdie

classes/lib/useradd: The option -P is deprecated

2022-02-12T17:05:35+00:00

This is also covered in documentation since: https://git.yoctoproject.org/yocto-docs/commit/?id=3f3e5574ac9801ad92940168b61b532e0bd53a80 [YOCTO 14605] (From OE-Core rev: 3f9153986e4e6f667b4bbe97613ec0b279665a97) Signed-off-by: Daiane Angolini Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

useradd-staticids: print exception after parse_args() error

2019-05-07T09:12:53+00:00

Without this, the user has no idea what went wrong. (From OE-Core rev: c1d887d63f098a10c7d6286399801d89fd3ebdb0) Signed-off-by: Max Kellermann Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: remove True option to getVar calls (again)

2019-01-14T11:35:56+00:00

A couple have still been missed in the past despite multiple attempts at doing so (or simply have re-appeared?). Search & replace made using the following command: sed -e 's|$d\.getVar \?$( \?$[^,()]*$, \?True)|\1(\2)|g' \ -i $(git grep -E 'getVar ?$ ?([^,()]*), ?True$' \ | cut -d':' -f1 \ | sort -u) (From OE-Core rev: 9f551d588693328e4d99d33be94f26684eafcaba) Signed-off-by: André Draszik Signed-off-by: Richard Purdie

classes/recipes: Convert SkipPackage -> SkipRecipe

2018-01-26T13:09:09+00:00

The new name is much more consistent with what this actually means. We put the pieces in place to rename everything a while back but looks like we forgot to actually do it! Fix that now. (From OE-Core rev: af9612f5d6b848fceea22d10ee964437299be776) Signed-off-by: Richard Purdie

useradd-staticids: explain how to fix the the problem

2017-11-08T22:24:03+00:00

When a distro uses useradd-staticids.bbclass and some developer unfamiliar with the static ID mechanism tries to add a recipe which needs new IDs, the resulting error or warning is typically not something that the developer will understand. Even experienced developers do not get enough information. They first must find out whether the missing ID is for a system user or group, then locate the file(s) in which the ID could be added. Both of this is now part of the message: ERROR: .../meta/recipes-extended/cronie/cronie_1.5.1.bb: cronie - cronie: system groupname crontab does not have a static ID defined. Add crontab to one of these files: /.../conf/distro/include/my-distro-group The case that no file was found is also handled: ERROR: .../meta/recipes-extended/cronie/cronie_1.5.1.bb: cronie - cronie: system groupname crontab does not have a static ID defined. USERADD_GID_TABLES file(s) not found in BBPATH: files/group It would be nice if the error message could also list the range in which a new ID needs to be allocated, but /etc/login.defs isn't available at the time of creating the message, so that part is still something that a developer needs to know. (From OE-Core rev: 883bfc2bbb4d2120dbad6b0f2056503b012b1a2b) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids: skip recipes without static IDs

2017-11-08T22:24:03+00:00

When enabling useradd-staticids.bbclass, one has to define static IDs for all recipes in a world build, otherwise those without static IDs generate parse errors or warnings, depending on USERADD_ERROR_DYNAMIC. Defining unused IDs is a lot of work and clutters the passwd/group file of a distro. Distros which want to avoid this can now set USERADD_ERROR_DYNAMIC = "skip" and recipes which would have triggered a message then silently get disabled. Only trying to build them shows the error message: $ bitbake apt ... ERROR: Nothing PROVIDES 'apt' ERROR: apt was skipped: apt - apt: username _apt does not have a static ID defined. (From OE-Core rev: 9113928cea88c2187e8640ac489671cb81f58103) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids: don't create username-group if gid is specified

2017-09-25T13:14:17+00:00

Adding distcc to an image, and having staticids enabled, doesn't work as it causes a a superfluous 'distcc' group being added using a conflicting GID, thus failing the build: | ERROR: distcc-3.2-r0 do_prepare_recipe_sysroot: distcc: groupadd command did not succeed. Compared to other recipes, the distcc recipe only specifies --gid for the primary group, and doesn't specify --no-user-group, but when --gid is given, it doesn't make sense to create a matching username-group in addition, even if --no-user-group was not specified, and 'useradd' actually complains if --gid and --user-group are given both. If only --gid is given, the current code in here effectively behaves as if --user-group was specified, taking the group-id of the username-group from the --gid parameter. This causes the error above, as we try to add a new group (distcc) with an existing group-id (nogroup). This is contrary to the comment in this file just above, contrary to what useradd can do, contrary to behaviour without the useradd-staticids bbclass, and non-intuitive. Change the code such that a username-group is only created - if a primary group using --gid was not specified, or - if --no-user-group was not specified To be in line with useradd, if gid is not given, and --no-user-group is given, we add the user to the group 'users', which mimics useradd's behaviour. (From OE-Core rev: fc3a86ae68919cec72c1a8ae0f9ba1f98ae13f0d) Signed-off-by: André Draszik Signed-off-by: Richard Purdie