The current version of our Python port (3.6.0) is over four years old by
now and has (or had, I haven't actually tried it in a while) some
limitations - time for an upgrade! The latest Python release is 3.9.1,
so I used that version. It's a from-scratch port, no patches are taken
from the previous port to ensure the smallest possible amount of code is
patched. The BuildPython.sh script is useful so I kept it, with some
tweaks. I added a short document explaining each patch to ease judging
their underlying problem and necessity in the future.
Compared to the old Python port, this one does support both the time
module as well as threading (at least _thread) just fine. Importing
modules written in C (everything in /usr/local/lib/python3.9/lib-dynload)
currently asserts in Serenity's dynamic loader, which is unfortunate but
probably solvable. Possibly related to #4642. I didn't try building
Python statically, which might be one possibility to circumvent this
issue.
I also renamed the directory to just "python3", which is analogous to
the Python 3.x package most Linux distributions provide. That implicitly
means that we likely will not support multiple versions of the Python
port at any given time, but again, neither do many other systems by
default. Recent versions are usually backwards compatible anyway though,
so having the latest shouldn't be a problem.
On the other hand bumping the version should now be be as simple as
updating the variables in version.sh, given that no new patches are
required.
These core modules to currently not build - I chose to ignore that for
now rather than adding more patches to make them work somehow, which
means they're fully unavailable. This should probably be fixed in
Serenity itself.
_ctypes, _decimal, _socket, mmap, resource, termios
These optional modules requiring 3rd-party dependencies do currently not
build (even with depends="ncurses openssl zlib"). Especially the absence
of a readline port makes the REPL a bit painful to use. :^)
_bz2, _curses, _curses_panel, _dbm, _gdbm, _hashlib, _lzma, _sqlite3,
_ssl, _tkinter, _uuid, nis, ossaudiodev, readline, spwd, zlib
I did some work on LibC and LibM beforehand to add at least stubs of
missing required functions, it still encounters an ASSERT_NOT_REACHED()
/ TODO() every now and then, notably frexp() (implementations of that
can be found online easily if you want to get that working right now).
But then again that's our fault and not this port's. :^)
Let's keep things consistent, .diff is the name we use pretty much
everywhere. Also tweak the glob in .port_includes.sh to be
'patches/*.patch' rather than just 'patches/*'.
* Add SERENITY_ARCH option to CMake for selecting the target toolchain
* Port all build scripts but continue to use i686
* Update GitHub Actions cache to include BuildIt.sh
This is a very WIP port bringing stress-ng to SerenityOS.
stress-ng is great at doing multi-workload stress testing, this allows it to
find unique and interesting intermixed pairs of stressful operations which cause bugs.
This initial port just rips out an non applicable functionality in order to get
the port to compile.
For now, only the non-standard _SC_NPROCESSORS_CONF and
_SC_NPROCESSORS_ONLN are implemented.
Use them to make ninja pick a better default -j value.
While here, make the ninja package script not fail if
no other port has been built yet.
Now that a "jq" port is available we can re-enable CPU name detection in
neofetch and don't need to use "read" for extracting values from
/proc/memstat anymore :^)
We don't really have a good way of parsing and processing JSON in the
shell yet, and the solution used for /proc/memstat (read) is very
limited and doesn't work for the more complex /proc/cpuinfo array. Let's
disable cpu detection in neofetch for now until we can come up with a
good solution.
- 1.8.2 for now, newer versions need high-res timestamp file APIs
which serenity doesn't have yet
- pselect() instead of ppoll() for now, same reason (depends on #2609)
- no good default for -j yet (see nproc.patch)
- `-l` probably doesn't work yet (see loadavg.patch), but I've never
used that anyways
- some minor include patches that I've also sent upstream
Other than that, this seems to work reasonably well. It currently
produces some spam on stdout from probably the shell.
This is very basic and doesn't support many features. Instead
of describing what it *doesn't* support, I'll describe what I
have tested:
1. Public key authentication (password is not supported)
2. Single command execution
3. PTY-less interactive bash shell (/bin/sh doesn't work)
4. Multi-user (i.e you can ssh as 'anon' as well as root)
