3.6.9 is the latest security fix release of Python 3.6.
- Fixes: CVE-2018-20852, CVE-2019-9948, CVE-2019-9740, CVE-2019-5010
- Refreshed patches
- Removed a few backports patches
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
The Modules/getbuildinfo.c allows the use of DATE and TIME
macros to be defined via CFLAGS.
These vars, control the build date & time when the
interpreter is opened, and can be read via the
`platform._sys_version()` function.
So, a conversion from SOURCE_DATE_EPOCH to DATE & TIME
is required at build-time.
This is especially needed for `platform._sys_version()`
to work.
The installation of pip seems to rely on this.
The logic has been adapted from:
https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Makefile
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Re-worked patch `003-do-not-run-distutils-tests.patch`
to reduce patch-size.
Removed `011-fix-ncursesw-definition-colisions.patch`
it is fixed upstream.
Refreshed with `make package/python3/refresh`
Resetting PKG_RELEASE to 1.
This variable was never used for pip3 & setuptools, since
VERSION is specified in the package definitions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
See:
https://github.com/openwrt/packages/issues/5278
This should make Python & Python3 packages reproducible
when building.
In my local tests, I got the same sha256 for a sample
.pyc file, so likely this is the solution that should address
this.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If there is only Python bytecodes, then
the __init__.py script will be concatenated, and
the __init__.pyc as well.
This is becase this bit `path = os.path.join(path, '__init__'+extension)`
is iterated twice.
This is a bug in Python3, also because we ship bytecodes
instead of source code [ with Python & Python3 ].
Python is not affected.
Reported-by: Mirko Vogt <mirko@nanl.de>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I admit this may be be a bit aggressive, but the lang
folder is getting cluttered/filled up with Python, PHP, Perl,
Ruby, etc. packages.
Makes sense to try to group them into per-lang folders.
I took the Pythons.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
