| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use bitwise operators to manipulate the received event mask in
_ProcessEvent.
Also minor clarification & clean up of the related comments.
(Bitbake rev: 2ab60c7be124d928d304ab1fb73f0dbff29964ae)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The kernel inotify code can set more than one of the bits in the mask,
fsnotify_change() in linux/fsnotify.h is quite clear that IN_ATTRIB,
IN_MODIFY and IN_ACCESS can arrive together. We don't care about two
of these from a bitbake perspective but it probably explains why in
real world builds, we've seen:
pyinotify.ProcessEventError: Unknown mask 0x00000006
This module code assumes only one mask bit can be present. Since we
don't care about two of these events, just mask them out for now.
The "upstream" code is unmainained since 2015.
(Bitbake rev: 7fb93c2ce6dacd9b53fc3a227133a3493e6a6a1d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When build with nativesdk-python3 (3.10) from buildtools:
/path/to/bitbake/lib/pyinotify.py:55: DeprecationWarning: The asyncore module is deprecated. The recommended replacement is asyncio
The pyinotify.py's upstream didn't have any update in recent 7 years:
https://github.com/seb-m/pyinotify
And bitbake doesn't use the asyncore module, so remove the related code.
(Bitbake rev: 58fbb01c3e2111bef4f79f88e1aac1827350c82a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
amend the code to handle singleton comparisons properly so it only checks
if they only refer to the same object or not, and not bother
comparing the values.
(Bitbake rev: b809a6812aa15a8a9af97bc382cc4b19571e6bfc)
Signed-off-by: Frazer Clews <frazer.clews@codethink.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
| |
(Bitbake rev: cc712f3257904960247a7532cfc4611f3dccd36c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 rev: 5ee80d77bc278758e411048ed09551ab65b9e72d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
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>
|
