arm32 needs its cache cleared before booting the kernel.
This isn't the case anymore in u-boot since they use efi_start_image.
Add a local patch until I resolv the issue upstream.
These are fonts designed by the KDE community for use with
KDE Plasma (although Noto Sans is now the default).
Committed from the review with minor wording changes.
Submitted by: vishwin@vishwin.info
Approved by: tcberner
Differential Revision: https://reviews.freebsd.org/D19692
QQ for Linux is no longer supported. No updates almost for 10 years since
this port is added.
PR: 236519
Submitted by: ykla <yklaxds@gmail.com>
Approved by: maintainer timeout
- While it looked like everything was being static-linked, so that
cmark, libsodium and olm could be build-dep, they're linked in.
Then "pkg install" pulls them in, but "pkg autoremove" gets
rid of them again, leading to an unusable nheko. Fix the deps.
This options allows to disable at build time dependency on gsfonts and
ghostcript, to reduce the number of dependency for minimal setup.
Note that ghostscript and gsfonts are only needed at build time otherwise (mark
ghostscritp as such in any case now) and they are needed for some usage of
gropdf.
Reported by: Zeus Panchenko <zeus@ibs.dn.ua>
elasticsearch5 (this port) unnecessarily pins its urllib dependency to
< 1.23, which blocks updating urllib3 to 1.24 [1]:
./textproc/py-elasticsearch5: setup.py: 'urllib3<1.23,>=1.21.1',
The package had a history of issues/conflicts/bugs with the urllib3
dependency, ultimately resulting in the maximum version pin being
removed [2]:
https://github.com/elastic/elasticsearch-py/issues/807https://github.com/elastic/elasticsearch-py/issues/667https://github.com/elastic/elasticsearch-py/issues/634
This commit backports that change, a functional noop and sweeping change
in advance required for a urllib3 update, and adds TEST_DEPENDS and
a test target to support rigorous and confident QA. Switching to GitHub
sources was required as the PyPI sdist does not package tests.
The packages tests all pass with/against urllib3 1.24 installed, with an
intermittent and non-deterministic off-by-one failure in one test:
FAIL: test_all_chunks_sent (test_elasticsearch.test_helpers.TestParallelBulk)
The issue exists independent of urllib3 version. The flaky test issue was
reported upstream [3], but was not resolved.
[2] 4352e56174
[3] https://github.com/elastic/elasticsearch-py/issues/701
PR: 229322 [1]
Approved by: portmgr (blanket: framework compliance, runtime bugfix)
code needs some attention, and move macro definition behind other flags
- Fix the build against the LLD linker on i386 when using optimized assembly
routines by allowing relocations in read-only segments (normally, Quake II
builds its shared libraries with -fPIC and they link fine except these few
files written in assembly)
PR: 234866
Submitted by: emaste
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
GCC links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch makes 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
PR: 208120
Submitted by: tijl
MFH: 2019Q2 (important user visible improvement)
