Am 11.09.2018 um 11:57 schrieb Adrian Bunk: >> Basically libssl 1.1.1 (in whatever 1.1.1 version - my guess is >> 1.1.1~~pre9-1 from the changelog) >> changed the definition of TLS_MAX_VERSION from TLS1_2_VERSION to >> TLS1_3_VERSION, which will start to >> break all software in buster using that symbol, until libssl1.1 moves to >> buster. > > I'd say that at least for the SSL_CTX_ctrl() symbol the created > dependency has to be increased. > > Raising the severity of both bugs to RC to make the problem more visible, > and to avoid further duplicate bugs. > > Since the new OpenSSL won't enter buster anytime soon, the reasonable > short-term workaround for testing would be an upload to use > TLS1_2_VERSION instead of TLS_MAX_VERSION in qtbase-opensource-src.
Who will patch all the binary packages for buster? Everything in sid that builds against current libssl1.1 and uses TLS_MAX_VERSION will break buster. And if we start patching stuff, who will remember to rebuild and "unpatch" all the packages, once the final libssl11 migrates? IMHO libssl1.1 with the current codebase should move to experimental. For the ABI breakage even with a new package name, until we plan a transition. Otherwise libssl1.1 will probably block a lot of packages. Qt5 is just the first breaking package - I have no idea, how many packages use TLS_MAX_VERSION in their code. And symbol versioning also won't help, as it's no symbol in the shared library sense, but a definition in the header, which would need manual handling AFAIK. openssl-1.1.1~~pre9 $ rgrep TLS_MAX_VERSION | grep ".h:" include/openssl/dtls1.h:# define DTLS_MAX_VERSION DTLS1_2_VERSION include/openssl/tls1.h:# define TLS_MAX_VERSION TLS1_3_VERSION CU Jan-Marek
