umläute

hmm, it seems this is related to my own build-system hacks. at least, building both flext and externals with the "normal" flext-build system (`flext/build pd gcc`) appears to work fine.

i stand corrected again. building both flext and externals with the "normal" flext-build system will not result in a "Bus Error", but instead the external will hang Pd and consume...

the logs for building libflext can be accessed on https://buildd.debian.org/status/package.php?p=pd-flext and the logs for the test (which builds an external and links it with libflext) can be accessed on https://ci.debian.net/packages/p/pd-flext/...

that's because the tests are obviously run on an `arm64` CPU (which can execute `armhf` instructions, similar to an `x86_64` CPU which can also run `i386` binaries). however, I also...

Python2 is reaching EOL [in about 100 days](https://pythonclock.org/) from now. Debian is currently fading out all packages that still require Python2 (including [py](https://bugs.debian.org/937266)). Maybe it's time :-)

i became aware of the `python3` branch after i posted. but looking at it (and amending it to linux) i notice that porting is indeed not trivial... (so i decided...

for me, it has been crashing with python2.7 for a while. given that python2 is dead now, i wouldn't invest time in fixing it

@ahihi could you please allow issues in your fork? i think we should discuss all problems with the port in the fork (probably in multiple issues), rather than abusing this...

so there has already been a `0.5.1` release? i don't find a tag for this, but configure.ac mentions it (so i thought that this was upcoming)

the problem seems to be one of the [go mysql driver](https://github.com/go-sql-driver/mysql/issues/427), and the solution is pretty simple: put `tcp()` around the host:port part. as in: > MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:secret@tcp(db:5432)/mattermost?sslmode=disable&connect_timeout=10 took me only...