License-Update: year updated to 2022.
Changelog:
=========
The NumPy 1.22.1 is maintenance release that fixes bugs discovered after
the 1.22.0 release. Notable fixes are:
Fix f2PY docstring problems
Fix reduction type problems
Fix various typing bugs.
The Python versions supported for this release are 3.8-3.10.
(From OE-Core rev: 7e42e8bbe4eb97316201640b43cafbbaf916e6e5)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
6.35.0 - 2022-01-08¶
This release disallows using typing.ClassVar with from_type() and register_type_strategy().
Why? Because ClassVar can only be used during class definition. We don’t generate class attributes.
It also does not make sense as a runtime type on its own.
6.34.2 - 2022-01-05¶
This patch updates our vendored list of top-level domains, which is used by the provisional domains() strategy.
(From OE-Core rev: 836cec0b8096f157ae7051d34efbe637ff211617)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 9985b17a30bb ("go: correctly set debug-prefix-map and build
directory") has changed CGO_LDFLAGS to the manually crafted version of
LDFLAGS to strip out DEBUG_PREFIX_MAP contents.
However this manually crafted version includes ${SECURITY_LDFLAGS}.
If security_flags.inc is not included, the variable is not defined, thus
CGO_LDFLAGS will include the '${SECURITY_LDFLAGS}' literally. When
building the recipe, the build would break with the follwing message:
aarch64-linaro-linux-gcc: error: ${SECURITY_LDFLAGS}: No such file or directory
So, instead of manually specifying variable contents, perform the
expected action: filter offending arguments out of LDFLAGS.
Cc: Alexander Kanavin <alex.kanavin@gmail.com>
(From OE-Core rev: e7d2d68679c1980d9e889d96c3eab49589f5b832)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Turn on "link external modules statically" option
as otherwise ruby installer tries to do additional
building inside installed module directories in do_install
which fails horribly.
License-Update: additional MIT/BSD items
(From OE-Core rev: 4d4485442830bb52b152f0419f4ff9f1d581d46a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pthread has been merged into the main libc library
(and was never separate in musl), so separate linking
for it is no longer needed.
I ran the reproducing sequence on qemux86, qemux86_64 and same targets with musl,
and it went fine:
root@qemux86:~# python3
Python 3.10.0 (default, Oct 4 2021, 17:55:55) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> pool_sema = multiprocessing.BoundedSemaphore(value=1)
>>> pool_sema.acquire()
True
>>> pool_sema.release()
>>>
(From OE-Core rev: 2eabd3b611f4afa5eafa4490b6b0ef7578b742de)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream dropped the now deprecated distutils:
18995d65 Remove distutils which are deprecated in python3.10 (RhBug:1950229)
Usage was replaced with sysconfig, which is in python3-core
[YOCTO #14610]
(From OE-Core rev: 93e9b006007ef1afc79c45b48fd92c9e384ff6cb)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
No longer depend on python3-distutils, current versions of setuptools
vendor as _distutils.
[YOCTO #14610]
(From OE-Core rev: 2b6735f648744c42484afec6edab6d5e130111e2)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While building GCC it checks whether the include directory exists,
if it doesnt it throws an error and exits:
| The directory that should contain system headers does not exist:
| tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-riscv32/
11.2.0-r0/recipe-sysroot/usr/include/
| make[1]: *** [Makefile:3257: stmp-fixinc] Error 1
Even though for the baremetal toolchain not having this directory
does make sense.
We overcame this by removing the --with-sysroot=/not/exist argument
for baremetal toolchains (via TARGET_OS override), however, the
newlib toolchain does have headers and an includedir, hence by fixing
the baremetal toolchain we broke the newlib one since it uses the same
TARGET_OS as baremetal, causing for example (on newlib):
/sdk/sysroots/x86_64-pokysdk-linux/usr/lib/riscv32-poky-elf/gcc/
riscv32-poky-elf/11.2.0/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
| # include_next <stdint.h>
^~~~~~~~~~
compilation terminated.
By creating a dummy includedir, and removing the previous fix we
allow GCC to be built the same way, unifying the cross compiler
for all targets.
After this fix both TCLIBC=baremetal and TCLIBC=newlib SDKs work
properly.
(From OE-Core rev: 08ff7c87efdf373f1874fcccd9a2a73fc0efef30)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "gcc: Fix compile of gcc plugins" patch had a typo making it a noop.
This was due to a rework to make it specific to the linux64.h header.
(From OE-Core rev: 5f0f00f0988c02d7fe0fa62edf3e4901ce9941a6)
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The issue is reported upstream:
https://bugs.ruby-lang.org/issues/18456
Otherwise I do not feel that further investigation of rdoc's parser to find
out the source of non-determinism is worth the time.
(From OE-Core rev: 208021f7212a8a790c350ccca720695c5bcbb1ca)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the tranisiton to perl-cross occured, the threading define
seems to have been missed. The perl tests for threading where
simply skipped, so there was no direct failures. This was verified
by running perl ptest before and after the change to see PASS vs SKIP
results of threaded related tests.
NOTE: Perl officially discourges the use of threads, so this
functionality maybe depercated in the future [0][1]
v2: adds the usethreads to native and nativesdk. This was tested by
builing postresql and rrdtool which use perl and automake.
[0] https://perldoc.perl.org/5.34.0-RC2/threads#WARNING
[1] https://perldoc.perl.org/perlpolicy#discouraged
(From OE-Core rev: b9fd7cd319a1d8f0ddf5ea60710b015e9afb588c)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, compiling gcc plugins will fail with an error similar to:
[...]
fatal error: ./config/i386/linux64.h: No such file or directory
[...]
In Yocto, we set up compiling gcc-cross out of tree. Which in turn makes
the generated headers end up in B. The tm.h header will include
generated headers that are expected in plugin/include/config/*.
For example, the linux64.h header, when generating gcc-cross for x86-64,
will end up in tm.h header as:
include "./config/i386/linux64.h"
On the other hand, the make rule `install-plugin` in gcc/Makefile.in
will install the linux64.h assuming that it is generated in the sources
directory and because this is not the case in our setup, the Makefile
ends up installing it in plugin_includedir/`basename $$path` which ends
up installing the header in [..]plugin/include as opposed to
[..]plugin/include/config/i386 (as expected by the generator of tm.h).
The included patch modifies the Makefile rule to match the assumption of
gcc-cross being compiled out of tree.
(From OE-Core rev: 92167f8e02bb6fbbe1ee6a6678525a0ae27b00a5)
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Go has its own system for creating temporary build
sub-directories with randomized names, and setting
up debug-prefix-map on the fly to prevent those
directories leaking into target binaries. OE's own
settings were clashing with it, so this change
carefully avoids the two stepping on each other.
Additionally, the top level build directory cannot
be named 'go-something'.
(From OE-Core rev: 9985b17a30bb9b9f1bc82a44662687db5cead66e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
go writes build-specific ids into binaries it produces
and has a custom system for calculating them from
file hashes, environment variables and other inputs
(not that dissimilar to sstate cache, actually). This can
go wrong :) in various ways (for purposes of reproducibility
in particular), so this enables useful logs to see what
happens and why.
(From OE-Core rev: a587be1d18fc55fe57d1aa5aa7c9e26af887109e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
==========
Bugs fixed for this release <https://github.com/numpy/numpy/pull/#####>
#20357: MAINT: Do not forward __(deep)copy__ calls of _GenericAlias...
#20462: BUG: Fix float16 einsum fastpaths using wrong tempvar
#20463: BUG, DIST: Print os error message when the executable not exist
#20464: BLD: Verify the ability to compile C++ sources before initiating...
#20465: BUG: Force npymath to respect npy_longdouble
#20466: BUG: Fix failure to create aligned, empty structured dtype
#20467: ENH: provide a convenience function to replace npy_load_module
#20495: MAINT: update wheel to version that supports python3.10
#20497: BUG: Clear errors correctly in F2PY conversions
#20613: DEV: add a warningfilter to fix pytest workflow.
#20618: MAINT: Help boost::python libraries at least not crash
(From OE-Core rev: 956d6811ed0ae6db759a663866eed4977f994ad8)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In qemu, they merged the 32 and 64 bit riscv variants into one target for meson
purposes but this isn't officially supported by upstream meson. In normal builds
this would just be a warning but in OE, this is fatal.
Avoid the fatal errors for now and build as qemu intended whilst this is resolved
by the upstreams.
(From OE-Core rev: 7c1356e762d357dad95decf7b1d6147a2efae174)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk-rpm build is also affected by the stray /var/tmp
created during the rpm install. Remove it to fix QA Issue:
nativesdk-rpm installs files in /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/volatile, but it is expected to be empty [empty-dirs]
(From OE-Core rev: 28dd1e1a0965646c5736e3de91aad830311a797b)
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were warnings about non-existent files when there was
a duplicate in the remove-for-aarch list and the non-deterministic lists
so check if the files still exists before trying to deal with it.
Also restore the tests in the opposite order that they were hidden.
(From OE-Core rev: 2e1dc5782dcb879410d535f937c633edea484d11)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The drd/tests/boost_thread test passes when run interactively on qemuarm64
but fails for most runs when run in qemu on an arm worker such as ubuntu1804-arm-1
from the Yocto autobuilder cluster. Skip the test until we fix the problem.
(From OE-Core rev: 9a36983f9681f215aa2f59bfcb16343fe0a819cd)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The valgrind ptest script warns about tests such as:
mv: cannot stat 'drd/tests/bar_bad_xml.vgtest': No such file or directory
Since these tests were either in both remove-for-* lists or
were not installed since they fail everywhere as noted in:
85a0d61025 valgrind: fix the remaining ptest failures
984ffe3ab4 valgrind: Disable leak_cpp_interior test
remove them from the remove-for-aarch64 list
(From OE-Core rev: 9492cdc43b830ebf0d02ccaae342f33c826d8a01)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
