umläute

as of frei0r-1.8, `autotools` is still (or: again?) broken, as it references a non-existing file `TODO`.

ah, i just noticed that there's ee21d097b3cab27202aa15ecec785462dbde25ff right after `v1.8.0`, which fixes this. it would be fantastic if the build-systems were tested *before* doing a release (probably using a CI;...

i obviously don't have any such overview. however, i have a data point: as the maintainer for the Debian packages, that universe (including Ubuntu, Mint, ...) is in my responsibility...

I just discovered that the proposed fix (replacing `__MACH__` with `__APPLE__`) is **not** enough to make the code build on the Hurd. I'll try to find a real solution in...

after a bit more investigation, i found that there are two occurences of `__MACH__` in that file, both of which ought to be replaced by `__APPLE__`. Here's the [Debian patch](https://sources.debian.org/src/assimp/4.1.0%7Edfsg-3/debian/patches/fix-hurd-FTBFS.patch/)...

just to explain the `setuid` stuff: _Pd_ (aka _puredata_, the source package for `puredata-dev`) is a real-time audio processing system. as such it is often run with higher-than-normal privileges. in...

is this real? *Ubuntu 14.04 (trusty)" had `puredata-0.45`. i can't remember which Ubuntu version had `puredata-0.43` (it was released in 2012).

not really Python3 related, but there also seem to be some problems with Pd's (?) escaping of whitespace (presumably in the `[stdout]` object), that makes the result-strings compare as false.

i think there will always be reasons for problems. that's the nature of a complex piece of software. i'm mainly arguing that the error-message as presented to the user could...

Another workaround [i just found](https://patchwork.ozlabs.org/patch/674113/), is setting the `QMAKE_CFLAGS_ISYSTEM` variable to an empty string, which forces qmake to use `-I` instead of `-isystem` and thus making the build succeed: ~~~bash...