linux/poky.git/bitbake/lib/bb/utils.py, branch yocto-4.0.12

bitbake: bin/utils: Ensure locale en_US.UTF-8 is available on the system

2023-04-26T14:03:21+00:00

Get rid of the duplicate code and add extra check that the locale en_US.UTF-8 is available on the system. This new helper method is now located right above the method filter_environment() which sets LC_ALL environment variable to 'en_US.UTF-8'. [YOCTO #10165] (Bitbake rev: 0c6f86b60cfba67c20733516957c0a654eb2b44c) Signed-off-by: Frank de Brabander Signed-off-by: Richard Purdie (cherry picked from commit a4ce040a6fd540a1cac52f808f909f9fcf8c961c) Signed-off-by: Steve Sakoman

bitbake: utils: Allow to_boolean to support int values

2023-03-14T15:05:30+00:00

Some variables may be set as: X = 1 as well the more usual X = "1" so add support to to_boolean to handle this case. (Bitbake rev: e7df13a61911b7431802af2b4d7472b2aaf346fa) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: utils/ply: Update md5 to better report errors with hashlib

2023-02-17T15:05:08+00:00

In the case where hashlib is not available, the try would fail and fall through resulting in a backtrace on the usage of the 'sig'. The backtrace itself was confusing and made it difficult to determine what went wrong. Update the import to be in it's own try block with an appropriate message to indicate what went wrong. Note, the current version of ply all of this code has been restructured so this is not applicable upstream. Additionally, some versions of hashlib don't appear to implement the second FIPS related argument. Detect this and support both versions. (Bitbake rev: d26ed38c233583b35ad1451e521f07d9c2329f4e) Signed-off-by: Mark Hatle Signed-off-by: Mark Hatle Signed-off-by: Luca Ceresoli (cherry picked from commit 484ab42f440070c0369b81f5c69da860fa47a798) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bb/utils: include SSL certificate paths in export_proxies

2023-01-30T08:40:24+00:00

bb.utils.export_proxies() is a poor-man's alternative for the environment setup code in bb/fetch2, but it's used in several places where recipes want to download manually (such as cve-update-db-native). Notably, export_proxies() doesn't pass on the SSL certificate paths from the original environment, so if SSL_CERT_FILE needs to be set (for example, in a buildtools environment) then proxies work but SSL doesn't. In an ideal world export_proxies and the same logic in fetch2 would merge, but until then we can add the SSL_CERT_ variables and duplicate the basic logic: check the datastore first and then the original environment for variables. Also remove the return value as nothing ever checked it. [ YOCTO #15000 ] (Bitbake rev: ed0dcc40f80c48839bac20298013d70043858a4e) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: siggen: Fix insufficent entropy in sigtask file names

2022-10-11T20:57:28+00:00

Signature generation uses mkstemp() to get a file descriptor to a unique file and then write the signature into it. However, the unique file name generation in glibc is based on the system timestamp, which means that with highly parallel builds it is more likely than one might expect expected that a conflict will occur between two different builder nodes. When operating over NFS (such as a shared sstate cache), this can cause race conditions and rare failures (particularly with NFS servers that may not correctly implement O_EXCL). The signature generation code is particularly susceptible to races since a single "sigtask." prefix used for all signatures from all tasks, which makes collision even more likely. To work around this, add an internal implementation of mkstemp() that adds additional truly random entropy to the file name to eliminate conflicts. (Bitbake rev: 63bb5591e833de0e7b552963ad9bc4b39e56fda9) Signed-off-by: Joshua Watt Signed-off-by: Luca Ceresoli (cherry picked from commit 97955f3c1c738aa4b4478a6ec10a08094ffc689d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bb/utils: movefile: use the logger for printing

2022-09-16T16:53:22+00:00

(Bitbake rev: a5fff68c8c83fed52dae0bdcf2c1713566a5a53e) Signed-off-by: Jose Quaresma Signed-off-by: Alexandre Belloni (cherry picked from commit 274b2d7a2fa0b43b0b542cb5471ff832e692ea93) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bb/utils: remove: check the path again the expand python glob

2022-09-16T16:53:22+00:00

When we call the remove with recurse=True we first check if the remove operation is safe in _check_unsafe_delete_path. But the check is been done on the path instaed of the expanded python glog. (Bitbake rev: 280ea5a776436eab7e664fccea2df2e7ce47e586) Signed-off-by: Jose Quaresma Signed-off-by: Alexandre Belloni (cherry picked from commit 7236488b898309ec5f1880936ddae22a28ccf5d3) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: utils: Pass lock argument in fileslocked

2022-09-02T10:45:32+00:00

Pass additional arguments in the fileslocked() context manager to the underlying lockfile() function. This allows the context manager to be used for any types of locks (non-blocking, shared, etc.) that the lockfile() function supports. (Bitbake rev: ce9fe70156e8f909a3a81da017b89ea61bc6fe38) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: utils: Fix lockfile path length issues

2022-03-24T17:45:28+00:00

If the path to bitbake.lock is in a deep directory, bitbake will hang. The reason was that the max file length limiting code (to 255 chars) was including the directory name and it should only act on the filename within the directory. Fix it to just use the base filename. [YOCTO #14766] (Bitbake rev: 89d70e7b71eecfe06592202f326e566c579ba01d) Signed-off-by: Richard Purdie

bitbake: utils/ply: Change md5 usages to work on FIPS enabled hosts

2022-03-02T00:20:50+00:00

hashlib.md5() is not permitted on a FIPS enabled host system. This is due to md5 not being an approved hash algorithm. Instead use: hashlib.new('MD5', usedforsecurity=False) This is allowed, as it's clear the hash is used for a non-security purpose. Note: utils.py version should never be used to verify file integrity, but instead be used to identify if the file may have changed. sha256 should be used for integrity purposes. (Bitbake rev: af866dd077867cba0129757bfcc689551445e9d7) Signed-off-by: Mark Hatle Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie