See this upstream issue: https://github.com/ARMmbed/mbedtls/issues/2965 This is causing build failures in various packages-- so far I've tested only a few but found failures in media-sound/umurmur, dev-scheme/gauche, and games-emulation/dolphin. Also this is what's going on in bug 703280. I think we either need to mask 2.18+ or backport some kind of patch for the mbedtls build system.
(In reply to Ben Kohler from comment #0) > > I think we either need to mask 2.18+ or backport some kind of patch for the > mbedtls build system. I've masked 2.18.1 and 2.19.1 for now. It doesn't look like a patch is available yet. So we'll wait for either a bump with the fix or a patch.
(In reply to Anthony Basile from comment #1) > I've masked 2.18.1 and 2.19.1 for now. It doesn't look like a patch is > available yet. So we'll wait for either a bump with the fix or a patch. looks like this got committed in the meantime: https://github.com/Ionic/mbed-crypto/commit/de35f31091b7e6cb20ebc8d8c0afc3b20bc57098
(In reply to PaX Team from comment #2) > (In reply to Anthony Basile from comment #1) > > I've masked 2.18.1 and 2.19.1 for now. It doesn't look like a patch is > > available yet. So we'll wait for either a bump with the fix or a patch. > looks like this got committed in the meantime: > https://github.com/Ionic/mbed-crypto/commit/ > de35f31091b7e6cb20ebc8d8c0afc3b20bc57098 I've added the patch to mbedtls-2.18.1-r1.ebuild and mbedtls-2.19.1-r1.ebuild. Can you please test, and if it fixes it for you, close this bug.
(In reply to Anthony Basile from comment #3) > I've added the patch to mbedtls-2.18.1-r1.ebuild and > mbedtls-2.19.1-r1.ebuild. Can you please test, and if it fixes it for you, > close this bug. thanks, i can confirm that mbedtls and shadowsocks-libev build fine.
obs-studio-24.0.5 is still broken after this mbedtls update
(In reply to Kobboi from comment #5) > obs-studio-24.0.5 is still broken after this mbedtls update i don't know if it helps tracking dowb the remaining issues with config handling but adding #define MBEDTLS_X509_CRT_PARSE_C #define MBEDTLS_DHM_C #define MBEDTLS_SSL_SRV_C #define MBEDTLS_SSL_CLI_C to librtmp/rtmp_sys.h makes it compile at least. i guess it's a gross hack but perhaps will help someone figure out the root cause.
I figured out what went wrong in 703280, adding it here too. The upstream patch is for *mbed-crypto* but mbedtls-2.19.1-r1.ebuild applies it at the root of the worktree, which is *mbed*. It happens to apply correctly to the other CMakeLists... and thus does exactly the opposite of what it's intended to do, removing the good include files and leaving the bad ones in. The patch in portage needs to have its path changed to add /crypto/: diff --git a/crypto/include/CMakeLists.txt b/crypto/include/CMakeLists.txt index 02f924df4..92229a221 100644 --- a/crypto/include/CMakeLists.txt +++ b/crypto/include/CMakeLists.txt Then it works.
Created attachment 604728 [details, diff] un-pebcak-705038-wrong-file.patch (In reply to Hector Martin from comment #7) > I figured out what went wrong in 703280, adding it here too. > > The upstream patch is for *mbed-crypto* but mbedtls-2.19.1-r1.ebuild applies > it at the root of the worktree, which is *mbed*. It happens to apply > correctly to the other CMakeLists... and thus does exactly the opposite of > what it's intended to do, removing the good include files and leaving the > bad ones in. > > The patch in portage needs to have its path changed to add /crypto/: > > diff --git a/crypto/include/CMakeLists.txt b/crypto/include/CMakeLists.txt > index 02f924df4..92229a221 100644 > --- a/crypto/include/CMakeLists.txt > +++ b/crypto/include/CMakeLists.txt > > Then it works. ACK. Hopefully this comment makes things more clear (a serious possibility/concern under the circumstances...!) ebuild patched the wrong file: "${S}"/include/CMakeLists.txt. Upstream meant for us to patch "${S}"/crypto/include/CMakeLists.txt. Unfortunately, although the patch may be applied to both files, it is only correct to patch the latter of the two (and the ebuild only applied it to the former... see, crystal-clear! :P) The attached file makes this explicit (and perhaps more directly comprehensible) by reverting the misapplied patch, and then re-applying upstream's medicine to the correct patient. Obviously, sticking this into ${FILESDIR} as a second patch along with the bad patch (although it would work) would be pretty sloppy, the bad patch should probably get dropped or corrected as Hector suggests. In the meanwhile, it may be put in /etc/portage/patches/net-libs/mbedtls-2.19.1-r1 as a work-around for the current snafu, thus fixing breakage like folks are observing in obs-studio.
=games-emulation/dolphin-5.0 is also still broken against =net-libs/mbedtls-2.19.1-r1: In file included from ../../../../dolphin-5.0/Source/Core/Core/IPC_HLE/WII_Socket.h:54, from ../../../../dolphin-5.0/Source/Core/Core/Core.cpp:60: ../../../../dolphin-5.0/Source/Core/Core/IPC_HLE/WII_IPC_HLE_Device_net_ssl.h:64:2: error: ‘mbedtls_x509_crt’ does not name a type; did you mean ‘mbedtls_time_t’? 64 | mbedtls_x509_crt cacert; | ^~~~~~~~~~~~~~~~ | mbedtls_time_t ../../../../dolphin-5.0/Source/Core/Core/IPC_HLE/WII_IPC_HLE_Device_net_ssl.h:65:2: error: ‘mbedtls_x509_crt’ does not name a type; did you mean ‘mbedtls_time_t’? 65 | mbedtls_x509_crt clicert; | ^~~~~~~~~~~~~~~~ | mbedtls_time_t
(In reply to PaX Team from comment #2) > (In reply to Anthony Basile from comment #1) > > I've masked 2.18.1 and 2.19.1 for now. It doesn't look like a patch is > > available yet. So we'll wait for either a bump with the fix or a patch. > looks like this got committed in the meantime: > https://github.com/Ionic/mbed-crypto/commit/ > de35f31091b7e6cb20ebc8d8c0afc3b20bc57098 Am I being blind, or is this patch actually in the upstream code already? This seems to be the fork with the proposed (not yet accepted) patch.
(In reply to Greg Turner from comment #8) > Created attachment 604728 [details, diff] [details, diff] > un-pebcak-705038-wrong-file.patch I confirm, this patch makes mbedtls-2.19.1-r1 build for me.
(In reply to Dennis Schridde from comment #11) > (In reply to Greg Turner from comment #8) > > Created attachment 604728 [details, diff] [details, diff] [details, diff] > > un-pebcak-705038-wrong-file.patch > > I confirm, this patch makes mbedtls-2.19.1-r1 build for me. Thanks guys! I see what's going on now. I'll add this patch.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bdff0e5ea288b745e38ef08914fe141a127902c commit 9bdff0e5ea288b745e38ef08914fe141a127902c Author: Anthony G. Basile <blueness@gentoo.org> AuthorDate: 2020-01-29 14:21:46 +0000 Commit: Anthony G. Basile <blueness@gentoo.org> CommitDate: 2020-01-29 14:22:13 +0000 net-libs/mbedtls: fix wrong headers, bug #705038 Closes: https://bugs.gentoo.org/705038 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Anthony G. Basile <blueness@gentoo.org> .../mbedtls-un-pebcak-705038-wrong-file.patch | 50 ++++++++++++++++++++++ net-libs/mbedtls/mbedtls-2.18.1-r1.ebuild | 1 + net-libs/mbedtls/mbedtls-2.19.1-r1.ebuild | 1 + 3 files changed, 52 insertions(+)
*** Bug 705864 has been marked as a duplicate of this bug. ***
(In reply to Larry the Git Cow from comment #13) > The bug has been closed via the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=9bdff0e5ea288b745e38ef08914fe141a127902c > > commit 9bdff0e5ea288b745e38ef08914fe141a127902c > Author: Anthony G. Basile <blueness@gentoo.org> > AuthorDate: 2020-01-29 14:21:46 +0000 > Commit: Anthony G. Basile <blueness@gentoo.org> > CommitDate: 2020-01-29 14:22:13 +0000 > > net-libs/mbedtls: fix wrong headers, bug #705038 > > Closes: https://bugs.gentoo.org/705038 > Package-Manager: Portage-2.3.84, Repoman-2.3.20 > Signed-off-by: Anthony G. Basile <blueness@gentoo.org> > > .../mbedtls-un-pebcak-705038-wrong-file.patch | 50 > ++++++++++++++++++++++ > net-libs/mbedtls/mbedtls-2.18.1-r1.ebuild | 1 + > net-libs/mbedtls/mbedtls-2.19.1-r1.ebuild | 1 + > 3 files changed, 52 insertions(+) I suggest to revbump an ebuild so users cloud just upgrade their systems instead of finding out that they need to rebuild mbedtls manually.
*** Bug 705036 has been marked as a duplicate of this bug. ***
(In reply to Sergei Trofimovich from comment #15) > > I suggest to revbump an ebuild so users cloud just upgrade their systems > instead of finding out that they need to rebuild mbedtls manually. Yeah, you're right. I pushed the rev bump.
