summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/pyinotify.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: bitbake: lib: Cleanup /usr/bin/env pythonRobert Yang2019-06-281-2/+1
| | | | | | | (Bitbake rev: cc712f3257904960247a7532cfc4611f3dccd36c) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Drop duplicate license boilerplace textRichard Purdie2019-05-041-17/+0
| | | | | | | | | | With the introduction of SPDX-License-Identifier headers, we don't need a ton of header boilerplate in every file. Simplify the files and rely on the top level for the full licence text. (Bitbake rev: 695d84397b68cc003186e22f395caa378b06bc75) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add initial pass of SPDX license headers to source codeRichard Purdie2019-05-041-0/+2
| | | | | | | | | | | | | | | | | This adds the SPDX-License-Identifier license headers to the majority of our source files to make it clearer exactly which license files are under. The bulk of the files are under GPL v2.0 with one found to be under V2.0 or later, some under MIT and some have dual license. There are some files which are potentially harder to classify where we've imported upstream code and those can be handled specifically in later commits. The COPYING file is replaced with LICENSE.X files which contain the full license texts. (Bitbake rev: ff237c33337f4da2ca06c3a2c49699bc26608a6b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake/pyinotify.py: Upgrade to py3 versionRichard Purdie2016-06-021-155/+101
| | | | | | (Bitbake rev: 5ee80d77bc278758e411048ed09551ab65b9e72d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add pyinotify to lib/Richard Purdie2015-01-141-0/+2416
We need inotify support within bitbake and pyinotify provides the best mechanism to add this. We have a few options: a) Depend on pyinotify from the system b) Add in our own copy c) Only use pyinotify in cases like the memory resident server For a), it would mean adding in dependencies, updating documentation and generally creating churn for users as well as having implications for things like the build-appliance recipe. It turns out that glibc has the C functionality we need from version 2.4 onwards (2006) and that we just need a single python file for b), there is no binary module needed. We therefore add in a copy of pyinotify 0.9.5 into the tree meaning we can depend on it simply and unconditionally. c) is unattractive as we need fewer possible code paths, not more. (Bitbake rev: d49004a4e247e3958a2f7ea9ffe5ec92794e1352) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>