mirror of https://git.yoctoproject.org/poky synced 2026-01-29 21:08:42 +01:00

Go to file

Wang Mingyu 674b2c8b77 python3-typing-extensions: upgrade 4.5.0 -> 4.6.2

Changelog:
============
-  Fix use of @deprecated on classes with __new__ but no __init__.
-  Fix regression in version 4.6.1 where comparing a generic class against a
   runtime-checkable protocol using isinstance() would cause AttributeError to
   be raised if using Python 3.7.
-  Change deprecated @runtime to formal API @runtime_checkable in the error message.
-  Fix regression in 4.6.0 where attempting to define a Protocol that was generic
   over a ParamSpec or a TypeVarTuple would cause TypeError to be raised.
-  typing_extensions is now documented at https://typing-extensions.readthedocs.io/en/latest/.
-  Add typing_extensions.Buffer, a marker class for buffer types, as proposed
   by PEP 688. Equivalent to collections.abc.Buffer in Python 3.12.
-  Backport two CPython PRs fixing various issues with typing.Literal:
   python/cpython#23294 and python/cpython#23383. Both CPython PRs were originally,
   and both were backported to Python >=3.9.1, but no earlier.
-  A side effect of one of the changes is that equality comparisons of Literal
   objects will now raise a TypeError if one of the Literal objects being compared
   has a mutable parameter. (Using mutable parameters with Literal is not
   supported by PEP 586 or by any major static type checkers.)
-  Literal is now reimplemented on all Python versions <= 3.10.0.
-  Backport CPython PR 26067, ensuring that isinstance() calls on protocols raise
   TypeError when the protocol is not decorated with @runtime_checkable.
-  Backport several significant performance improvements to runtime-checkable protocols
   that have been made in Python 3.12 (see python/cpython#74690 for details).
-  A side effect of one of the performance improvements is that the members of a
   runtime-checkable protocol are now considered "frozen" at runtime as soon as the
   class has been created. Monkey-patching attributes onto a runtime-checkable
   protocol will still work, but will have no impact on isinstance() checks comparing
   objects to the protocol. See "What's New in Python 3.12" for more details.
-  isinstance() checks against runtime-checkable protocols now use inspect.getattr_static()
   rather than hasattr() to lookup whether attributes exist (backporting python/cpython#103034).
-  Backport the ability to define __init__ methods on Protocol classes, a change
   made in Python 3.11 (originally implemented in python/cpython#31628
-  Speedup isinstance(3, typing_extensions.SupportsIndex) by >10x on Python <3.12.
-  Add typing_extensions versions of SupportsInt, SupportsFloat, SupportsComplex,
   SupportsBytes, SupportsAbs and SupportsRound. These have the same semantics as
   the versions from the typing module, but isinstance() checks against the
   typing_extensions versions are >10x faster at runtime on Python <3.12.
-  Add __orig_bases__ to non-generic TypedDicts, call-based TypedDicts, and call-based NamedTuples.
-  Add typing_extensions.get_original_bases, a backport of types.get_original_bases,
   introduced in Python 3.12 (CPython PR python/cpython#101827, originally
-  This function should always produce correct results when called on classes
   constructed using features from typing_extensions.
-  Constructing a call-based TypedDict using keyword arguments for the fields
   now causes a DeprecationWarning to be emitted. This matches the behaviour
   of typing.TypedDict on 3.11 and 3.12.
-  Backport the implementation of NewType from 3.10 (where it is implemented as
   a class rather than a function). This allows user-defined NewTypes to be pickled.
-  Fix tests and import on Python 3.12, where typing.TypeVar can no longer be subclassed.
-  Add typing_extensions.TypeAliasType, a backport of typing.TypeAliasType from PEP 695.
-  Backport changes to the repr of typing.Unpack that were made in order
   to implement PEP 692 (backport of python/cpython#104048).

(From OE-Core rev: a37154b9166323d05cca970ebb37bee0d5250893)

Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

2023-06-02 15:16:36 +01:00

bitbake

bitbake: runqueue: Pass hashfn in taskdep data

2023-06-01 08:08:33 +01:00

contrib

contrib/git-hooks: add a sendemail-validate example hook that adds FROM: lines to outgoing patch emails

2020-12-30 14:01:07 +00:00

documentation

migration-guides: release-notes-4.0.4.rst: fix typo

2023-05-26 17:32:51 +01:00

README.md

Poky

Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.

Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.

As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.

The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/

OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.

Contribution Guidelines

The project works using a mailing list patch submission process. Patches should be sent to the mailing list for the repository the components originate from (see below). Throughout the Yocto Project, the README files in the component in question should detail where to send patches, who the maintainers are and where bugs should be reported.

A guide to submitting patches to OpenEmbedded is available at:

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

There is good documentation on how to write/format patches at:

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Where to Send Patches

As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:

OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):

Git repository: https://git.openembedded.org/openembedded-core/
Mailing list: openembedded-core@lists.openembedded.org

BitBake (files in bitbake/):

Git repository: https://git.openembedded.org/bitbake/
Mailing list: bitbake-devel@lists.openembedded.org

Documentation (files in documentation/):

Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
Mailing list: docs@lists.yoctoproject.org

meta-yocto (files in meta-poky/, meta-yocto-bsp/):

Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
Mailing list: poky@lists.yoctoproject.org

If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.