| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Upstream: https://github.com/gambit/gambit/pull/809
|
|
This patch reverts Node MR 43714[1], which broke time64 on pmmx.
[1]: https://github.com/nodejs/node/pull/43714
Fixes: #935
|
|
|
|
Note that the checksums remain the same.
Also removes a hard-coded version number.
|
|
|
|
|
|
|
|
Commit e8adedc8d15b9b11e780df8bda2d7431c23d627f did not restore
the original -j1 as in be1bb0240206f8fec1bd44f95d0130856e753c07.
|
|
Unfortunately V8 does not support ppc and seemingly has no interest in
adopting a port. In the future we will look for alternative JS runtimes
for running workloads on ppc.
We may also be able to package Node 12 since it has ppc support, with
the caveat that it is not well-supported upstream and will stop
receiving security updates. This is still useful for some workloads
(Firefox builds, internal Homebridge, and such), perhaps.
Closes: #837
|
|
These are no longer required in the system/ repository.
|
|
The tools need libraries that should not be pulled into system/.
Additionally, since c-ares needs CMake now, it causes a dep cycle.
Fixes: #936
|
|
Estimated penalty, based on N=2 samples:
* -j8: ~0-2 minutes
* -j1: ~4-9 minutes
|
|
|
|
|
|
|
|
* The worker-stdio test no longer raises RangeError on 32-bit Intel.
* The sigint test is no longer flaky (backported from 18 branch).
* The C++ Environment handler no longer segfaults when /proc is
unmounted. (Submitted upstream.)
Fixes: #795
|
|
These packages don't work right now. Hopefully we can work with
upstream to fix them on musl systems.
Closes: #872
|
|
The Devel::MAT pod is broken on 32-bit musl systems. It is listed as a
'recommended' package, not 'required', and it works fine without it.
Additionally, it was only listed in makedepends; if we were using it, it
would need to be a runtime dependency.
Ref: #872
|
|
This fixes the drop-messages-interval test in rtpjitterbuffer.
Issue: #924
|
|
Previous commits erroneously mentioned issue #924.
|
|
|
|
|
|
Additionally, the 'max-gcse-memory' parameter was updated
to safely accommodate the ~512M threshold needed by Gambit
on some platforms.
|
|
|
|
|
|
This patch reverts upstream a7cdcdc77b8efef239d9b06e857a64e490d1a81b
which caused a build failure on musl.
Additionally, 32-bit architectures (ppc in particular) may fail to
link due to address space limitations. Adjust link flags to mitigate.
|
|
|
|
This patch is not intended to be upstreamed as written.
|
|
|
|
The patch fixes #853 (libs_gstnetclientclock).
The glib-2.72.4 update is actually what fixed #874, as futex was broken
on 32-bit architectures. It was affecting PowerPC harder because the
MSB was what the kernel was seeing, but in 2038 the other arches would
have started seeing the same failures.
Fixes: #853, #874
|
|
This contains a needed fix for time64 on 32-bit architectures.
|
|
This only showed up in tests on ppc, but would eventually hit all of
them. The code already correctly handled SIZEOF_TIME_T being 8, but
this was cased on _WIN32. Removed that specialisation and now it works.
Fixes: #877
|
|
This is pending merge upstream and fixes the deadlock in the gst_gstbin
test which causes it to timeout on builders sometimes.
Ref: #807, #853
|
|
The Interpreter unit-test is already disabled on AIX, so it is likely
ABI-related. The other Interpreter test needs R_PPC_REL24 to be
implemented in the LLVM RuntimeDyld to work.
The DirectoryWatcher tests are all broken for unknown reasons, but don't
affect actual compilation so we just skip them for now.
Fixes: #848
|
|
Our ppc builder is running on P8/P9 hardware which cannot run Valgrind
in 32-bit mode. This skips those tests on that hardware.
It would be nice to re-enable these tests, if Valgrind grows ISA 3.0
support in 32-bit mode, or if our builders age up.
Closes: #876
|
|
Modern GCC (8.x) doesn't need a special builtins file for PPC. Let's
remove the old workaround and build natively.
Fixes: #869
|
|
No clue why they were special-casing detection like this.
Fixes: #870
|
|
Fixes: #906
|
|
Fixes: #895
|
|
This corrects an issue where Horizon media may boot to a black screen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It turns out we *have* to specify signedness or we have incorrect results
on systems with signed-char by default (aka x86).
Tested on ppc64 and x86_64 and both pass tests now.
Fixes: #911
|
|
|
|
|
|
|
