**** BEGIN LOGGING AT Sun Feb 24 02:59:56 2019 Feb 24 04:05:26 Tofe: you'd need Qt patch... give me moment Feb 24 04:06:52 Tofe: https://codereview.qt-project.org/#/c/242412/ Feb 24 04:06:58 JaMa: ^^ Feb 24 06:30:21 our glibc should be new enough in thud https://github.com/meta-qt5/meta-qt5/commit/2d1d8078156d050994a6cf46298d836b357df15c https://github.com/meta-qt5/meta-qt5/commit/95d64ea67e804a43dc829ffd3ebdac427312ffd7 Feb 24 06:32:18 JaMa: it's not glibc, it's more like kernel version which is at issue ^^ Feb 24 06:32:27 (If I understand this correctly) Feb 24 06:33:31 this qtbase patch is included in qtbase we're using in meta-qt5 Feb 24 06:33:41 but you're right, I misunderstood it at first Feb 24 06:34:35 Hm okay. Tofe: what kernel version is this? Feb 24 06:45:41 bshah: This is on Xiaomi Tissot (A1) which has 3.18.x kernel Feb 24 06:46:05 3.18 should be enough :/ Feb 24 06:50:16 3.18.31 Feb 24 06:50:21 To be exact Feb 24 09:02:27 Morning Feb 24 09:02:57 bshah: notice that the aforesaid syscall isn't renameat nor statx, if I've checked correctly Feb 24 09:09:06 mmh the syscall table isn't necessarily the same for all archs? Feb 24 09:26:02 so... it might be the "recv" syscall. But I'm not that sure. Feb 24 09:28:58 ... or it might be statx. I'm lost :p Feb 24 09:36:10 Tofe: https://marcin.juszkiewicz.com.pl/2019/02/18/three-years-of-system-calls-table/ might help Feb 24 09:36:17 just what I've read 3 days ago :) Feb 24 09:37:01 statx for arm64 Feb 24 09:37:57 but you didn't say it's from qt, right? might be some other components using syscall 291 directly instead of glibc wrapper which should call the right implementation Feb 24 09:38:25 Tofe: it might be better if I switch unstable back to sumo which is iirc older glibc (less likely anything else using statx already) Feb 24 09:38:45 and we should get sumo working first anyway, because of kernel issues with gcc8 in thud Feb 24 11:02:16 Maybe yes Feb 24 11:08:13 I've triggered another unstable build on jenkins to update sstate with latest thud, then I'll switch it to sumo and restart Feb 24 11:15:19 Tofe: I'm looking at that busybox change you mentioned before https://git.busybox.net/busybox/commit/?h=1_28_stable&id=37277a23fe48b13313f5d96084d890ed21d5fd8b Feb 24 11:15:59 I wanted to apply it in 1.27.2 used in sumo, but there were quite a few conflicts and first line says "This mostly reverts commit bc9bbeb2b81001e8731cd2ae501c8fccc8d87cc7" Feb 24 11:16:10 and this commit was applied in 1.28.0 Feb 24 11:17:08 so the version in sumo shouldn't be affected (unless someone activelly backported this from 1.28.0 in oe-core, I'll check) Feb 24 11:18:45 ./meta/recipes-core/busybox/busybox/CVE-2011-5325.patch Feb 24 11:19:04 it's the backport of bc9bbeb2b81001e8731cd2ae501c8fccc8d87cc7 :) Feb 24 11:19:22 ok; otherwise there would be another way of fixing it, if needed Feb 24 11:19:57 like adding EXTRACT_UNSAFE_SYMLINKS=1 in our initrd script Feb 24 11:20:40 but still, it's even better if busybox doesn't have this -- which I would call a regression Feb 24 11:21:51 applying CVE-2011-5325.patch first might help with cherry-picking 37277a23fe48b13313f5d96084d890ed21d5fd8b on top of that, trying it now Feb 24 11:22:02 just 3 conflicts now Feb 24 11:22:03 both modified: archival/libarchive/data_extract_all.c Feb 24 11:22:03 both modified: archival/libarchive/unsafe_symlink_target.c Feb 24 11:22:03 both modified: archival/unzip.c Feb 24 11:25:51 JaMa: you know, I *could* PR the initrd script change; patching busybox seems quite a hassle Feb 24 11:29:18 Tofe: if I am not reading sources wrong syscall 291 is statx for arm64... Feb 24 11:30:41 bshah: yes, it took me a while but I agree :) Feb 24 11:30:47 but then you seem to have the patch (which helped me) in your qt already so :shrug: Feb 24 11:31:04 try gdb maybe? Feb 24 11:31:57 bshah: will try yes Feb 24 11:32:16 JaMa: if you get bored of patching busybox, this should work: https://github.com/webOS-ports/meta-webos-ports/commit/38d2676d17fcf0aded469276482bff734dedf59b Feb 24 11:33:38 bshah: ^ a similar thing directly in Halium's script could be a good idea, if you stumble on the wrong versions of busybox... Feb 24 11:34:08 Tofe: I'm testing busybox patch now (might be useful for other people as well), but we should fix initrd as well just in case Feb 24 11:34:59 bshah: Tofe: the syscall table I've linked before is generated from kernel sources and shows statx as well Feb 24 11:35:15 JaMa: yes, it's a very useful table Feb 24 11:54:41 statx call from luna-next: https://paste.ubuntu.com/p/XTzDJVtWMN/ Feb 24 11:57:05 strange and you have 5.11.3 Feb 24 11:58:14 can you show me which patch you have applied to qtbase? Feb 24 11:58:27 Tofe: might be recipes-qt/qt5/qtbase/0014-Check-glibc-version-for-renameat2-statx-on-non-boots.patch Feb 24 11:58:53 link please? Feb 24 11:58:55 bshah: https://github.com/meta-qt5/meta-qt5/tree/thud/recipes-qt/qt5/qtbase Feb 24 11:59:00 okay Feb 24 11:59:50 hm Feb 24 12:00:00 well, patch I linked there is not included? Feb 24 12:00:09 it's already in 5.11.3 Feb 24 12:00:49 ah right.. we made jump from 5.11.2 to 5.12 right Feb 24 12:01:15 so you're right maybe 0014 patch is conflicting ... Feb 24 12:01:17 dunno Feb 24 12:02:48 bshah: but b7887f9b4faad2227691a2af589e9d7680d6ae08 is also included in 5.12.0, so you shouldn't see the issue with 5.12 as well Feb 24 12:03:00 or were you seeing it only with 5.11.2 and then it was ok with 5.12? Feb 24 12:04:00 yeah I was seeing it with only 5.11.1 and .2 and then with Thiago's patch it worked fine ^^ Feb 24 12:04:20 (Thiago's patch is last commit which touched this code IIRC) Feb 24 12:04:36 then there was related commit but affected only android Feb 24 12:05:59 I think the meta-qt5 0014 patch is now just useless Feb 24 12:12:07 so... we lack some glibc patch or config ? Feb 24 13:01:55 https://github.com/meta-qt5/meta-qt5/commit/2d1d8078156d050994a6cf46298d836b357df15c introduced that patch and before that I had https://github.com/meta-qt5/meta-qt5/commit/539e4f09f749f024d6e157a49559e5ad7f51470a Feb 24 13:15:52 JaMa: but there's nowhere in the source code referencing these macros now with 5.11.3 -- it always uses glibc, which (in our case) should use the placeholder function and not the syscall, but doesn't. Feb 24 13:18:59 Hello people, I know this may sound like a stupid question here, as I wasn't able to find another channel where to ask this, but could someone explain me the flashing process of Lune for my RedMi 5 rosy? Feb 24 13:20:46 Tofe: aha, I see Feb 24 13:24:59 SantX27: It's basically the exact same process as for most other devices: Install a recovery (via fastboot), and flash LuneOS image from within recovery Feb 24 13:25:59 I'm not sure we detailed which recovery should be used for rosy in our documentation Feb 24 13:26:14 I tried following as close as possible this guide (https://webos-ports.org/wiki/Install_LuneOS_for_Hammerhead) but without success, I don't even see the LuneOS logo Feb 24 13:26:35 SantX27: which steps did you do so far? Feb 24 13:27:40 Unlock my phone bootloader, install TWRP recovery, download and install the stable version of Lune from the website Feb 24 13:29:06 SantX27: one important detail: we use Android 7.1-based drivers, which rely on that version of the firmwares (for gps, radio, etc); so flashing a 7.1 ROM (the stock one is fine) is required before flashing LuneOS Feb 24 13:29:49 So I have to start from a Nougat ROM, I see Feb 24 13:31:58 SantX27: also I still have some important issues to solve on that device; for instance the virtual keyboard sometimes doesn't want to show up Feb 24 13:32:40 We have a similar issue for all our xiaomi targets, though it's most annoying on rosy Feb 24 13:34:29 Sure, I know the implications that arise from detaching from Android Feb 24 13:41:31 I suspect the issue comes from the touchscreen kernel driver, somehow -- good news is, rebuilding it is easy. Bad news is, it's quite a complex code to analyze... Feb 24 13:42:37 it could be also that we don't use it the way it's intended to, as Android doesn't seem to have that issue Feb 24 13:46:37 If there's some way I can help as a code inexpert like testing and reporting I would be really happy to give a hand Feb 24 14:12:19 Tofe: https://github.com/webOS-ports/meta-webos-ports/pull/311#event-2160116670 ? Feb 24 14:12:49 should I cherry-pick it to sumo and rebase thud? Feb 24 14:22:51 ah, yes, sorry... Feb 24 14:36:01 done Feb 24 14:43:09 JaMa: Thanks ! I forced the use of placeholder statx in glibc; it helped with the kernel errors, but didn't improve startup. In the end, the main error is "QSGRenderThread[5355]: unhandled level 2 translation fault (11) ", not sure yet what it is Feb 24 14:44:06 still building thud? Feb 24 14:44:11 yes Feb 24 16:31:06 am i right that we have this statx issue because tissot kernel is old, but we build system using recent kernel headers? shouldn't we use old headers then? Feb 24 17:48:01 nizovn: I think glibc should respect oldest kernel variable to decide which syscalls are available, not the kernel headers Feb 24 17:48:48 and OLDEST_KERNEL in sumo is: Feb 24 17:48:50 meta/conf/bitbake.conf:OLDEST_KERNEL = "3.2.0" Feb 24 17:48:50 meta/conf/bitbake.conf:OLDEST_KERNEL_aarch64 = "3.14" Feb 24 17:48:50 meta/conf/bitbake.conf:OLDEST_KERNEL_nios2 = "3.19" Feb 24 17:48:50 meta/conf/bitbake.conf:OLDEST_KERNEL_riscv32 = "4.15" Feb 24 17:48:52 meta/conf/bitbake.conf:OLDEST_KERNEL_riscv64 = "4.15" Feb 24 17:49:27 which should be fine on tissot with 3.18.31 Feb 24 17:50:17 JaMa: thanks, good to know Feb 24 18:10:11 JaMa: but if does a #ifdef __NR_statx in statx.c, does that take into account the kernel version?... Feb 24 19:28:40 Tofe: git grep minimum_kernel in glibc doesn't show many results, so maybe I was mistaken and it uses this only to report that kernel is too old for glibc (not for testing the actual syscalls) Feb 24 19:36:58 JaMa: I saw some kernel version tests here and there, but directly based on KERNELVERSION (iirc), not minimum version Feb 24 19:47:16 there is also __LINUX_KERNEL_VERSION Feb 24 19:47:36 and __ABI_TAG_VERSION Feb 24 19:47:50 used quite a bit in Changelog and for some syscalls as well, but maybe not all Feb 24 19:48:45 e.g. Feb 24 19:48:45 * sysdeps/unix/sysv/linux/kernel-features.h Feb 24 19:48:45 [__LINUX_KERNEL_VERSION >= 0x040B00] (__ASSUME_STATX): Define. Feb 24 19:48:48 in Changelog Feb 24 19:49:13 and Feb 24 19:49:13 #if __LINUX_KERNEL_VERSION >= 0x040B00 Feb 24 19:49:14 # define __ASSUME_STATX 1 Feb 24 19:49:14 #endif Feb 24 19:53:05 but the code in sysdeps/unix/sysv/linux/statx.c seems to check only __NR_statx first and then __ASSUME_STATX only to ignore possible ENOSYS and then run generic version Feb 24 19:53:45 so if I read it correctly it might still call the syscall, it will fail and be shown in the log, but then it calls statx_generic which works Feb 24 19:54:54 and the NR_statx is indeed defined in the headers Feb 24 19:54:56 include/uapi/asm-generic/unistd.h:#define __NR_statx 291 Feb 24 20:30:36 isn't there a "return" statement just after the failure of the syscall ? Feb 24 20:32:20 ah no, I see, you're right Feb 24 20:32:33 it explains why it still kind-of works Feb 24 20:39:56 compared with renameat2 it works similarly (renameat2 is a bit more complicated because it will fallback to renameat as well) but it also tries to call it first Feb 24 21:03:53 ok **** ENDING LOGGING AT Mon Feb 25 02:59:57 2019