linux/poky.git/bitbake/lib/bb, branch krogoth-15.0.2

bitbake: fetch: copy files with -H

2016-11-08T23:47:15+00:00

When using a PREMIRROR with plain (non-unpack) files, a SRC_URI like SRC_URI = "file://devmem2.c" will cause devmem2.c to be a symlink in the WORKDIR pointing to the local PREMIRROR. Trying to apply a patch on this file will either modify the file on the PREMIRROR or will fail due to sanity checks: ERROR: devmem2-1.0-r7 do_patch: Command Error: 'quilt --quiltrc /cache/build-ubuntu/sysroots/x86_64-oe-linux/etc/quiltrc push' exited with 1 Output: Applying patch devmem2-fixups-2.patch File devmem2.c is not a regular file -- refusing to patch (Bitbake rev: e82862ba8fedb2c5cd478c731b3d259d16c6e3d8) Signed-off-by: Enrico Scholz Signed-off-by: Richard Purdie

bitbake: bb.event: fix infinite loop on print_ui_queue

2016-11-08T23:47:14+00:00

If bitbake ends before _uiready and bb.event.LogHandler was add to the bitbake logger it causes an infinite loop when logging something. The scenario is print_ui_queue is called at exit and executes the log handlers [2] one of them is bb.event.LogHandler this handler appends the same entry to ui_queue causing the inifine loop [3]. In order to fix a new copy of the ui_queue list is created when iterate ui_queue. [YOCTO #10399] [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10399#c0 [2] http://git.openembedded.org/bitbake/tree/lib/bb/event.py?id=41d9cd41d40b04746c82b4a940dca47df02514fc#n156 [3] http://git.openembedded.org/bitbake/tree/lib/bb/event.py?id=41d9cd41d40b04746c82b4a940dca47df02514fc#n164 (Bitbake rev: bb56a8957255999b9ffd1408d249cc5b715b5a3a) Signed-off-by: Aníbal Limón Signed-off-by: Richard Purdie

bitbake: event: prevent unclosed file warning in print_ui_queue

2016-11-08T23:47:14+00:00

Use logger.addHandler(), rather than assigning an array of Handlers to the loggers handlers property directly, to avoid a warning from Python 3 about unclosed files: $ bitbake Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. WARNING: /home/joshuagl/Projects/poky/bitbake/lib/bb/event.py:143: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/joshuagl/Projects/poky/build/tmp/log/cooker/qemux86/20161004094928.log' mode='a' encoding='UTF-8'> logger.handlers = [stdout] (Bitbake rev: 775888307dc2917ef4b52799cc1600a6b3a01abe) Signed-off-by: Joshua Lock Signed-off-by: Richard Purdie

bitbake: event.py: output errors and warnings to stderr

2016-11-08T23:47:14+00:00

All logging messages are printed on stdout when processing UI event queue. This makes it impossible to distinguish between errors and normal bitbake output. Output to stderror or stdout depending on log level should fix this. (Bitbake rev: c4029c4f00197804511fc71e1190d34eb120212a) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

bitbake: lib/bb/tests/fetch: remove URL that doesn't exist anymore

2016-09-13T15:19:46+00:00

The CUPS ipptool URL we were checking now redirects to github where the tarball isn't present, so remove it from the test suite. (Bitbake rev: e64564bcaa7331f505baa5209fef1f50dfda1469) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: fetch2: Safer check for BB_ORIGENV datastore

2016-06-29T18:36:02+00:00

BB_ORIGENV value on the datastore can be NoneType thus raising an AttributeError exception when calling the getVar method. To avoid this, a check is done before accesing it. [YOCTO #9567] (Bitbake rev: f368f5ae64a1681873f3d81f3cb8fb38650367b0) (Bitbake rev: 25859009b710cb35ac8f9ee9eb3a7305f9e13402) Signed-off-by: Leonardo Sandoval Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

bitbake: fetch2: export DBUS_SESSION_BUS_ADDRESS to support authentication agents

2016-06-02T20:14:31+00:00

Some users may want to use authenticated SSH connections with credentials stored in a keyring, such as gnome-keyring. These typically need a DBus session bus connection, so pass DBUS_SESSION_BUS_ADDRESS into the fetcher environment. To avoid the user needing to set it in their local.conf (which wouldn't be usable) or adding it to the environment-cleansing whitelist (which would potentially impact builds) allow the variables being passed to the fetchers to come from the data store (first) or the original environment (second). >From bitbake master rev: 20ad1ea87712d042bd5d89ce1957793f7ff71da0 (Bitbake rev: 26379ff2b686313c82af87a3a35b47adbc0183be) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: main: fix processing of BBEVENTLOG

2016-04-19T16:31:01+00:00

Fixed typo that caused incorrect processing of BBEVENTLOG environment variable. Even if variable is set it was ignored by bitbake. (Bitbake rev: 2705b5f59aef4a070e2df2752d27bd04ea747057) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

bitbake: lib/bb/utils: add docstring for contains()

2016-04-18T15:28:23+00:00

(Bitbake rev: e9174723ea6d0dff5f7f3042009761cf42284947) Signed-off-by: Richard Purdie

bitbake: providers: Add PREFERRED_RPROVIDER support

2016-04-15T05:59:44+00:00

Sometimes you can end up in a situation where you need to specify that a specific runtime entity should be provided by a specific entry. An example of this is bluez where you could end up in a situation where for example: NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez NOTE: multiple providers are available for runtime bluez-hcidump (bluez-hcidump, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match bluez-hcidump The only option here is to set something like PREFERRED_PROVIDER_bluez4 = "bluez4" which is clearly not very informative. I've actually held off adding RPROVIDER support for a long while as this does have sigificant potential for misuse. It doesn't for example allow multiple runtime providers of the same name to coexist, that simply isn't supported. It therefore doesn't replace some of the name mappings such as busybox verses coreutils that OE-Core faces as that is a different problem with different constraints. This mechanism is simply to provide bitbake with a hint to decide what the dependency tree should look like. Also, this allows us to stop printing a confusing message telling the user to set PREFERRED_PROVIDER when the setting needed would be rather ambiguous. [YOCTO #5044] (Bitbake rev: 62eb39d1474d024b204634689071700605c6095c) Signed-off-by: Richard Purdie