Following a discussion on bugs.python.org:
* https://bugs.python.org/issue29708
* https://bugs.python.org/msg313384
It seems that setting a fixed value to PYTHONHASHSEED guarantees that
the bytecodes are generated consistently/in a reproducible manner.
Hopefully, this is the last bit to make Python3 build reproducible.
Tested this locally on a few files [that were not reproducible without
this change].
The PYTHONHASHSEED is only assigned to the host Python/Python3 during
compilation of byte-codes [from python source].
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
PHP comes with a bundled version of libpcre which is then statically
linked. However, we already depend on the packaged library, so we
can reduce the footprint when linking to it dynamically.
This saves around 200-300 kB (this depends on other configuration).
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Required by Authen::SASL to have actual plug-ins to handle the
protocol.
Uses Devel::CheckLib which doesn't work with cross-compilation with
the current perlmod.mk machinery.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
It requires either hardware or software emulated fpu, otherwise program
can fail with SIGILL for fp instructions emitted by the JIT compiler
See #1937, #2633, #2442, FS#1257 for details
From code snippet at deps/v8/src/mips/constants-mips.h
#elif(defined(__mips_soft_float) && __mips_soft_float != 0)
// This flag is raised when -msoft-float is passed to the compiler.
// // Although FPU is a base requirement for v8, soft-float ABI is used
// // on soft-float systems with FPU kernel emulation.
// const bool IsMipsSoftFloatABI = true;
[1] https://bugs.chromium.org/p/v8/issues/detail?id=4704
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
In Perl the 'do' construct has some odd side-effects regarding $@,
$!, and return values (i.e. 'do'ing a file which evaluates to undef
can be a little ambiguous).
Instead, generate a preamble to the Makefile.PL and execute it as
stdin.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Because nonexistent aarch64.config the build of perl will fail for ARM
64-bit targets. Fix it by adding mentioned config. Fixes#2963.
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Upstream was a little premature on asking for a change and not
vetting it. Here is the currently proposed fix.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Depending on which version of libiconv you're using, php_iconv_string()
doesn't always null out *out as part of its initialization. This
patch makes that behavior invariant.
Submitted upstream as https://github.com/php/php-src/pull/3037 where
it's approved and waiting a merge.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
musl-libc doesn't define _XOPEN_REALTIME as it doesn't implement the
full set of the realtime operations. However, it _does_ implement
POSIX_TIMERS, which is what luaposix _should_ be checking for in the
posix.time module.
I've filed https://github.com/luaposix/luaposix/issues/295 to track this
upstream, but this is a simpler, verified fix for our older version of
luaposix.
This restores functions like posix.time.clock_gettime(CLOCK_MONOTONIC)
for instance, which was available with pre-musl builds of luaposix.
Signed-off-by: Karl Palsson <karlp@etactica.com>
There have been some new dependencies added in recent versions of
Twisted (mostly internal classes that have been spun out into their own
libraries):
* constantly (#5453), since 16.5.0
* incremental (#5454), since 16.5.0
* Automat (#5456), since 17.1.0
* hyperlink (#5455) since 17.5.0
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
For python `src` packages we should clear out the DEPENDS
to prevent recursive deps from happening.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
Automat is a library for concise, idiomatic Python expression of
finite-state automata (particularly deterministic finite-state
transducers).
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
Hyperlink provides a pure-Python implementation of immutable URLs. Based
on RFC 3986 and 3987, the Hyperlink URL makes working with both URIs and
IRIs easy.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
Incremental is a small library that versions your Python projects.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This is a new requirement for the Twisted package.
From the readme:
A library that provides symbolic constant support. It includes
collections and constants with text, numeric, and bit flag values.
Originally twisted.python.constants from the Twisted project.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
python3 variant
Renaming the package is needed to allow for a Python 3 variant
(python3-zope-interface). Packages that depend on this (only twisted)
also have their dependencies adjusted.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This guarantees for the package feeds that
the mk files will always be available for all packages.
Will need to see about external-feed Python packages
a bit later.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The only difference just a parameter for Python3
[ -b to compile bytecodes in legacy mode ].
No need to keep 2 almost identical files now
that they're exported.
I'm a bit scared of that param, since it may get
removed at some point.
But let's see until then.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 & 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.
This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.
Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.
For now we limit this to this feed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The .mk snippets are not really usable at the moment, as they cannot be
considered for metadata collection (package DUMP) when included through
include_mk. Python packages do not use include_mk anymore for this reason,
so the install commands can be removed as well.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Marko Ratkaj
Alexandru Ardelean
Michael Heimpold
Gergely Kiss
Laurent Papier
Kimmo Vuorinen
Philip Prindeville
Yousong Zhou
Tomasz Maciej Nowak
Karl Palsson
Jeffery To
Matthias Schiffer