The toolchain is built in a previous stage, but once the Serenity stage
has begun, we have to re-pull the toolchain from the Azure cache. There
is a timing window where a cache-busting change can be commited between
these steps; to alleviate the affect this has, pull the toolchain ccache
so that the build only takes a few minutes instead of a couple hours.
The configure script for `SDL2_mixer` was trying to find the shared
library for `libmodplug` in the wrong directories and with the wrong
filename. This installs the shared library as `libmodplug.so.1` and
symlinks to it from `libmodplug.so`, and instructs the `SDL2_mixer`
build to search for it in `/usr/local/lib`.
Fixes the build for ports Super-Mario, freeciv and dungeonrush.
This file apparently relies on the fact that `sys/wait.h` _may_ include
symbols from `signal.h`, but as we don't have that (and it isn't a
requirement), let's just add the include for `signal.h`.
These environment variables would linger after the `php` port was done
building. This would pose issues in the future if other ports depend on
this package, since these vars then leak into the build scripts.
Previously, man would only check if a path is not associated with a
manpage when no section was specified via the command line.
So `man gibberish` would fail with "no man page for gibberish", but `man
2 gibberish` would fail with a runtime error and still open a pipe to
the pager leading to a nasty crash.
Moving the check outside the "if (!section)" block fixes this.
Also: if a section is specified, the error message now echoes it back
(no manpage for foo in section bar).
I'm not even sure if this is a hack. However, we don't implement
memalign so it's necessary to tell GCC so it doesn't go looking for it
in their implementation of `new`
As it was pointed by Idan Horowitz, the rest of the method doesn't
assume we have any reserved ranges to allow mmap(2) to work on them, so
the VERIFY is not needed at all.
The previous implementation had some pretty short cycles and two fixed
points (1711463637 and 2389024350). If two keys hashed to one of these
values insertions and lookups would loop forever.
This version is based on a standard xorshift PRNG with period 2**32-1.
The all-zero state is usually forbidden, so we insert it into the cycle
at an arbitrary location.
The README previously described `depends` as a space-separated
string. This is now changed to an array, which seem to be the
correct type used in the other Ports.
We don't actually have a non-trivial vfork implementation, so just
call fork(). As a bonus, vfork() is deprecated in XCode 13.1 when
targeting macOS Big Sur, so this removes a blocker from updating our
macOS CI version.
In CI / or local testing when you run `serenity.sh tests`, the system
will boot itself in self test mode, and the test runner will be launched
by SystemServer. Previously we were setting up settings for that
environment in the `SystemServer.ini`. This makes reproducing CI
failures a bit confusing, as the system will behavior differently if you
run in self-test mode, vs running `run-tests-and-shutdown.sh` or
`run-tests` manually in a session.
This change moves the settings to `run-tests`, so no matter how you try
to run the test runner, it will always behave the same.
We often see PR's opened and then immediately closed because folks think
they did something bad, or don't know how to fix the situation. So lets
try to give them a few pointers.
The evaluation order of method parameters is unspecified in C++, and
so we couldn't rely on parse_statement() being called before
parse_escape() when building a MatchExpression.
With this patch, we explicitly parse what we need in the right order,
before building the MatchExpression object.
This fixes a CI flake we've been seeing lately in TestLibCoreStream.
The solution itself is somewhat of a stop-gap as there are more thorough
event loop threading improvements in the works.
We should only look at the framebuffer structure members if the
MULTIBOOT_INFO_FRAMEBUFFER_INFO bit is set in the flags field.
Also add some logging if we ignored the fbdev command line argument
due to either not having a framebuffer provided by the bootloader, or
because we don't support the framebuffer format.
This allows forcing the use of only the framebuffer set up by the
bootloader and skips instantiating devices for any other graphics
cards that may be present.
Use the same trick as SlavePTY and override unref() to provide safe
removal from the sockets_by_tuple table when destroying a TCPSocket.
This should fix the TCPSocket::from_tuple() flake seen on CI.
