**** BEGIN LOGGING AT Wed Sep 19 03:00:00 2018 Sep 19 03:58:08 armpit: mali is not working in xu4 ? Sep 19 03:58:20 armpit: is that a regression Sep 19 03:59:08 it never worked Sep 19 03:59:26 in later kernels I should say Sep 19 03:59:39 the device tree is not upstream Sep 19 04:00:31 4.18 Sep 19 04:18:24 armpit: yeah I think we can get it going soon Sep 19 04:19:07 we should keep hardkernel 4.14 recipes Sep 19 04:23:11 that is such a painful thought Sep 19 04:26:19 4.14 is LTS Sep 19 04:32:31 4.19 will be the next one and no sign hardkernel is moving there.. Sep 19 04:33:16 * armpit like I provide support on this layer Sep 19 04:35:14 khem, are you suggesting the default should be 4.14 ? Sep 19 04:39:23 armpit: I think there should be an option to use linux-hardkernel_4.14 Sep 19 04:39:42 I am not hard bound to have it default Sep 19 11:02:00 hi Sep 19 11:07:41 I am struggling a bit, trying to update from Yocto 2.0.2 to Yocto 2.5.1, how does one correctly handle the removal of image_types_uboot.bbclass ? Sep 19 11:08:16 I should remove it from IMAGE_FSTYPES and add to IMAGE_CLASSES? Sep 19 11:09:33 with my old config in place poky/meta/classes/image.bbclass keeps trying to inherit stuff that is not there Sep 19 11:12:09 see poky e18cec750b51267d9c130b395c7a53585f4ae7ac Sep 19 11:12:18 basically, just remove all mention of it Sep 19 11:14:53 actually this is exactly the commit I have been looking at Sep 19 11:16:32 see how everything in it just moves Sep 19 11:17:20 well, I see it moves away from IMAGE_TYPES Sep 19 11:17:54 all the explicit variations are not needed because we can change them now Sep 19 11:18:01 so just set IAMGETYPES to what you want Sep 19 11:19:52 hm ok let me try that Sep 19 11:22:09 so I renamed IMGAE_FSTYPES= to IMAGE_TYPES= but it still tries to inherit that removed uboot class Sep 19 11:24:23 I must be missing or misunderstanding something Sep 19 11:24:30 or both :) Sep 19 11:24:38 just remove all mention of image-tyes-uboot Sep 19 11:24:55 and you can probably remove IMAGE_CLASSES in your distro Sep 19 11:26:10 wel, I do not have any image_types_uboot string in my layer, but we do want a .uboot image Sep 19 11:26:23 just set IMAGE_FSTYPES as required Sep 19 11:27:42 damn the patchtest is picky about Upstream-Status: Submitted format.. another rebuild of the world in progress Sep 19 11:27:59 JaMa: yeah patchtest is overly picky Sep 19 11:28:12 don't worry too much Sep 19 11:29:00 rburton: I really hope so :) Sep 19 11:29:12 hmm, I think the uboot stuff is getting pulled in by some other ways, because now that I look at it again, my IMAGE_FSTYPES do not list any .uboot thing at all, at the same time thre is no image_types_uboot in my layer when I grep, I wonder how it gets in there... will check other layers that I depend on Sep 19 11:36:53 we're building an initramfs and it seems that meta-freescale tries to inherit that class Sep 19 11:40:55 Hello all, I am really lost with RDEPENDS and DEPENDS, the python package(https://github.com/wbolster/plyvel) binding for leveldb needs cython for building. I have tried to mention cython RDEPENDS_${PN} = "python3-cython" but still as I try to compile recipe I get | cython --version make: cython: Command not found ... Sep 19 11:41:44 baali: DEPENDS is for build-time dependencies Sep 19 11:41:54 if the build wants to *run* something then you need the native form Sep 19 11:42:01 DEPENDS=python3-cython-native Sep 19 11:42:19 and inherit python3native to use the native py3 and not the host py3 Sep 19 11:43:13 aahh.... got it... this is the recipe I have so far.. https://pastebin.com/E5NHHexy thanks rburton, I am trying python3-cython-native.... Sep 19 11:52:03 rburton: so there's one class in meta-freescale that sets IMAGE_FSTYPES = "cpio.gz.u-boot" which then somehow results in poky/meta/classes/image.bbclass:181: Could not inherit file classes/image_types_uboot.bbclass which as I understood you - should not happen anymore? Sep 19 11:54:34 or am I still missing something? Sep 19 11:55:30 the image.bbclassin poky does: Sep 19 11:55:32 IMAGE_CLASSES += "image_types" Sep 19 11:55:34 inherit ${IMAGE_CLASSE Sep 19 11:55:45 S} :) sorry mispasted Sep 19 11:56:28 so I can only assume that IMAGE_FSTYPES with the .uboot stuff in them somehow get translated to image_types and get added to IMGAE_CLASSES and then the inherit fails... Sep 19 11:56:35 but I dont quite understand how its actually supposed to work... Sep 19 12:09:01 Lots of messages from patchwork.openembedded.org were identified as spam in the past. Sep 19 14:14:39 armpit: khem: what about doing something like what meta-freescale does https://lists.yoctoproject.org/pipermail/meta-freescale/2017-March/020284.html Sep 19 14:16:23 khem: armpit: choose one as the default (in meta-freescale's case they chose the vendor stuff as default i.e. with blobs) and if the user wants mainline (i.e. without blobs) then it's a simple matter of adding 'MACHINEOVERRIDES .= ":use-mainline-bsp"' to conf/local.conf Sep 19 14:24:43 tlwoerner, interesting idea. thanks Sep 19 14:55:30 yes this seems a good idea Sep 19 15:56:38 khem: how are things these days with mixing c++ libraries linked against libstdc++ with ones built with clang and linked against libc++, does that work? Sep 19 15:57:16 khem: the libc++ page is a little vague Sep 19 16:11:13 I am looking for the opcontrol binary, it was not isntalled by the oprofile package Sep 19 16:12:00 or something else that allows me to profile an app by sampling stack traces Sep 19 16:37:32 armpit: khem: i've been trying to get this class added to oe-core so all BSPs can use it, but nobody merged it :-( Sep 19 16:37:50 some people said "i want to think about it more" but nothing happened Sep 19 16:37:59 http://lists.openembedded.org/pipermail/openembedded-architecture/2017-July/000662.html Sep 19 16:38:15 http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139974.html Sep 19 16:40:54 heeen: use perf instead? Sep 19 16:49:06 perf ++ Sep 19 17:04:16 is there a way to make a recipe version dependent on a kernel? armin suggested RDEPENDS but i can't find the magic incantation Sep 19 17:04:48 oops, that should have read... Sep 19 17:04:59 is there a way to make a recipe version-dependent on a kernel Sep 19 17:05:14 i.e. this recipe needs a kernel >= 4.15 Sep 19 17:06:12 RDEPENDS_${PN} = "kernel (>= 4.15)" Sep 19 17:06:34 but it doesn't seem to work (with rpi anyway) -> what's the package name for virtual/kernel? Sep 19 17:13:41 hmm, is meta-freescale a replacement for meta-fsl-arm or are they both supposed to coexist? Sep 19 17:17:37 Jin^eLD: yes, meta-freescale is a replacement for meta-fsl-arm Sep 19 17:17:54 meta-fsl-arm hasn't seen a commit since Oct 2016 Sep 19 17:18:45 meta-fsl-arm and meta-fsl-ppc were merged -> meta-freescale Sep 19 17:19:21 thank you! Sep 19 17:19:52 tlwoerner: btw I am not aware that you can RDEPEND on certain versions Sep 19 17:19:57 http://freescale.github.io/#main-section Sep 19 17:20:08 Jin^eLD: neither was i until armin suggested it! Sep 19 17:20:40 I know that opkg was capable of that, but I did not know that it was possible to pass this dependency to it from OE :) Sep 19 17:21:26 https://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#qa-issue-dep-cmp Sep 19 17:22:44 wow, nice, was not aware of that either, but then again - I am just now in the process of updating for 2.0.2 to 2.5.1, so I missed quite a lot ;) Sep 19 19:22:03 hmm, can I somehow enforce a prbump when using prserv? I'm trying to recover from something... Sep 19 19:25:59 ok never mind, I think I can do it via bitbake-prserv-tool Sep 19 19:28:59 khem: https://github.com/VSCodium/vscodium Sep 19 19:32:13 for prserv... the checksum of which task is being stored? Sep 19 19:37:01 and how does the import work? I can't import anything that I exported, I get ParserError: not a BitBake file Sep 19 19:37:08 any hints? Sep 19 19:37:32 curently looking at this documentation https://wiki.yoctoproject.org/wiki/PR_Service Sep 19 19:39:26 ok, sorry for bothering ;) thx to google... its supposed to have a .conf extension... Sep 19 19:41:12 but which task exactly is being checksumed, that I did not figure out yet Sep 19 19:56:33 Jin^eLD: e.g. these 2 from prserv.sqlite PRMAIN_nohist tables: Sep 19 19:56:34 linux-yocto-4.18.5+gitAUTOINC+7341720391_71799edb8a-r0|qemux86|93759b759b6f9d151f8d0863e7221475|4 Sep 19 19:56:37 linux-yocto-4.18.5+gitAUTOINC+7341720391_71799edb8a-r0|qemux86|8763994acab1e22e8770ddcc0706bf83|5 Sep 19 19:56:44 match with do_package and do_deploy tasks in linux-yocto Sep 19 19:56:57 4.18.5+gitAUTOINC+7341720391_71799edb8a-r0.do_package.93759b759b6f9d151f8d0863e7221475 Sep 19 19:57:05 4.18.5+gitAUTOINC+7341720391_71799edb8a-r0.do_deploy.8763994acab1e22e8770ddcc0706bf83.qemux86 Sep 19 19:59:40 ah, do_package and do_deploy.. thank you Sep 19 20:00:00 linux-yocto isn't best example and you can change the key with PRAUTOINX variable Sep 19 20:01:10 I somehow ran into a problem with recipe XX is trying to install files into a shared area when those files already exist. Sep 19 20:01:34 so now fighting my way around but trying to keep the feed updateable (i.e. need to prevent PR going back in case I clean something) Sep 19 20:02:51 and this is your only problem with PRserv? then you're lucky :) Sep 19 20:04:07 well, we are finally switching to rootfs-based updates, i.e. flashing whole image instead of rolling opkg updates Sep 19 20:04:18 so hopefully prserv won't be such an issue any longer... Sep 19 20:04:39 that's what we do as well (not ideal, but better than fighting with PRserv) Sep 19 20:04:46 one OE core with PR_INC control over .bbappends and each package having a fixed PR it worked fine Sep 19 20:04:55 s/one/on/ Sep 19 20:05:11 yeah, both have pros and cons, opkg update was at times faster due to the smaller diff Sep 19 20:05:31 but the newer opkg versions in yocto proved to have a lot of issues Sep 19 20:05:42 and then the prserv stuff was not easy to handle as well Sep 19 20:05:53 did you report those opkg issues? Sep 19 20:06:14 we were on an older opkg branch because we were using libopkg which got dropped in the later version Sep 19 20:06:23 so - our own fault for using old stuff Sep 19 20:06:37 I don't have much issues with opkg, but with PRserv every opkg update was almost as slow as reflash of whole rootfs Sep 19 20:06:54 e.g. small update in zlib causes almost everything to rebuilt with different PRAUTO Sep 19 20:07:07 and then upgrading *everything* with opkg is much slower than reflash Sep 19 20:07:31 we were stuck on quite a buggy opkg branch, so was also no point to report anything because we were on a too old version and we could not switch to the new one because we had tools depending on libopkg Sep 19 20:07:42 + opkg upgrade everything usually fails because of lack of disk space on the target Sep 19 20:07:53 IC Sep 19 20:07:57 yes, that I noticed, sometimes too many packages got rebuilt and then if you have 400 packages to update - then a reflash is faster Sep 19 20:08:46 and partial diff of rootfs might be even smaller/faster, because a fix in zlib usually doesn't change much in everything else which somehow depends on zlib Sep 19 20:08:56 what do you use to flash images? swupdate? Sep 19 20:09:30 proprietary inhouse thing Sep 19 20:10:10 swupdate isn't bad if you set up a user data partition to persist stuff and ideally dual-partition so you're alternating the rootfs when you update Sep 19 20:10:16 * kergoth has used it a bit Sep 19 20:10:56 we came up with a rescue system and we use it for updates as well, but we decided against a pure data partition Sep 19 20:11:07 so we backup configurations that need to be backed up Sep 19 20:11:19 then reflash and restore the config Sep 19 20:11:30 * kergoth nods, not a bad way to go Sep 19 20:12:10 we were considering the alternation as well but not all of our targets have enough space to support that and we wanted to have maximum unification between the various platforms - easier maintenance Sep 19 20:12:58 we have 55 partitions for different usecases including sort of A/B for recovery Sep 19 20:13:32 55? wow... Sep 19 20:13:46 must be fun to maintain :) Sep 19 20:14:47 aye. the safety of a/b is nice, but nto alwyas viable Sep 19 20:15:07 btw I saw that NI did a better job than us getting the mulple kernel thing merged Sep 19 20:15:14 :) Sep 19 20:34:05 morning folks Sep 19 20:34:16 Jin^eLD: yeah, it took quite a bit of wrangling but it's in :) Sep 19 20:34:43 there's still some missing bootloader integration for completeness (platform-dependent though of course) Sep 19 20:36:29 hi bluelightning Sep 19 20:37:54 well, I remember it was quite an intrusive change, so no wonder it took a while to come up with something that wouldnt break everything :) Sep 19 21:06:43 smurray: mixing libc++ and libcstc++ are API compatible but not ABI compatible Sep 19 21:09:25 so you can load both libraries into a process but dont pass symbols across library boundary Sep 19 21:11:15 nite Sep 19 21:12:06 khem: hmm, Sep 19 21:12:31 khem: okay. I’ll have to see if that works for this customer’s codebase Sep 19 21:12:43 khem: thanks! Sep 20 01:41:44 smurray: yeah its hard to tell with out looking at what the code might be doing Sep 20 01:53:45 khem: yeah, lots of potential gotchas **** ENDING LOGGING AT Thu Sep 20 03:00:01 2018