 Hello! When I build Qt5Core from Testing for i386, I get this `file` info:
[14:39] <lubot5> ```libQt5Core.so.5.10.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=..., for GNU/Linux 3.17.0, stripped```
 (Photo, 1183x688) https://i.imgur.com/I9tTGVE.jpg Compare to other libraries
 I have an older kernel, so the linker does not use this library, and all the Qt software fails
 This didn't happen before, any change that could trigger this?
 @ilyaishere, See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895718
 The previous LTS release has kernel 4.4 (without HWE updates) and I think this is the minimum kernel version we should support in Cosmic.
 So, upstream Qt now limits to 3.17...
 That's sad, it cuts a huge percentage of phones
[15:14] <bshah> o_O
 @ilyaishere, Unless you build it without getentropy support.
 > We can build Qt without the “getentropy” feature and that would lower the
[15:17] <lubot5> > required kernel version to 3.16:
[15:17] <lubot5> > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/minimum-linux_p.h#n64
 I seem to have missed a number of version bumps
 2 month ago I had no issues using 3.10
 I guess, some "renameat" config also has to be disabled...
 If I disable those two, will it break applications?
[15:20] <lubot5> * ilyaishere searches for a Halium device with kernel >= 3.17
 My device has kernel 3.18, but it's an armhf device.
 You're on the edge ;)
 They actually disabled it on Android: http://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/io/qfilesystemengine_unix.cpp?id=8eb3944dac81b8c51d7bac7784204d457551b50c
 Can't yet find the fallback they use
 It looks like they redefine libc functions; if they can't do so, libc functions are used instead
 I think we'll have to fork the packaging for Halium
 But it seems like they enable it anyway if host kernel supports it: http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qfilesystemengine_unix.cpp#n109
[15:57] <bshah> Probably question(s) for #qt
 (so also a patch)
 Yeah...
[15:57] <bshah> also it seems, only Debian is affected? I didn't hit this with 3.10 kernel and Ubuntu + arm?
[15:58] <bshah> [I didn't read bug report fully]
 Well, Ubuntu should be affected as well as long as they haven
 't disabled these syscalls
 Arch is affected FWIW
 @bshah, It doesn't seem to be disabled in the KDE Neon packaging as far as I can see.
 bshah: is build machine kernel newer than 3.16?
 Also, does docker maybe prevent detecting the kernel features? (in case the neon ci uses docker)
[16:10] <bshah> @ilyaishere: to answer your question, that machine would be using 4.4 or 4.8(?) kernel depending on which slave it uses
 Ok. To clarify, the idea right now is that neon rootfs works because the kernel renameat feture is not detected: http://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/io/qfilesystemengine_unix.cpp?id=6eef81ee1c82f934e14d47047d8b6103b8755321
[16:40] <tsimonq2> So, with 5.11.1 being in cosmic-proposed, I'm going to hunt it down a little bit more.
[16:40] <tsimonq2> Otherwise I'm starting the preparation of 5.9.6 for Bionic: https://bileto.ubuntu.com/#/ticket/3329
[16:41] <tsimonq2> I plan on doing everything but qtwebengine in that PPA, and once all the packages are updated and we're ready, I'll manually upload to the queue to make it easier to review.
[16:42] <tsimonq2> As I discussed with @mitya57, I'm going to revert the commit changing the internal version to 5.9.6, so we don't have to no-change rebuild rdeps of the private headers.