**** BEGIN LOGGING AT Sat Apr 25 02:59:59 2020
Apr 25 03:53:04 <yocti> New news from stackoverflow: Facing issue in yocto zeus u-boot compilation [closed] <https://stackoverflow.com/questions/61411154/facing-issue-in-yocto-zeus-u-boot-compilation>
Apr 25 05:05:28 <roussinm> khem: lldb is not a target. That's why it wasn't that obvious to me.
Apr 25 05:05:43 <roussinm> well nothing RPROVIDES it.
Apr 25 06:03:14 <khem> moto-timo: tab completion pressed to quickly, wasnt looking for you
Apr 25 06:05:59 <khem> roussinm: buildhistory tells me its in clang package packages/aarch64-yoe-linux-musl/clang/clang/files-in-package.txt:-rwxr-xr-x root       root          3539240 ./usr/bin/lldb-server
Apr 25 06:06:39 <khem> perhaps we should create subpackages for lldb and related packages, so clang is not such a fat package
Apr 25 06:14:29 <roussinm> Maybe in master?
Apr 25 06:14:36 <roussinm> I am on zeus clang-9
Apr 25 06:14:49 <khem> the problem is on master too
Apr 25 06:15:13 <roussinm> ha!
Apr 25 06:15:31 <khem> I mean binary exists but its packaged into clang package
Apr 25 06:15:52 <roussinm> But I don't want clang inside my image, I want lldb :)
Apr 25 06:15:58 <khem> so if you want just lldb-server then you will get whole shebang
Apr 25 06:16:40 <khem> exactly, thats why I said we perhaps need to divide the PACKAGE part in clang recipe to have multiple packages
Apr 25 06:16:45 <roussinm> a lldb package seems reasonable, RRECOMMENDS with lldb-server?
Apr 25 06:16:47 <khem> perhaps you can send a patch :)
Apr 25 06:17:13 <khem> I think lldb-server should be a separate package lldb should be also seprate
Apr 25 06:17:27 <khem> e.g. for cross debugging you dont want lldb
Apr 25 06:17:33 <khem> just lldb-server is enough
Apr 25 06:17:37 <roussinm> right.
Apr 25 06:18:00 <roussinm> I'll look into this during weekend, much more free time now with covid-19.
Apr 25 06:18:06 <khem> so I would think create lldb and lldb-server at minimum
Apr 25 06:18:17 <khem> roussinm: good deal
Apr 25 06:18:48 <roussinm> I'll probable send it through github.com if that's fine with you?
Apr 25 06:20:19 <khem> roussinm: perhaps also seprate out liblldb into its own package
Apr 25 06:20:32 <khem> yes I prefer github
Apr 25 06:21:33 <roussinm> should I follow the same pattern  in clang_git.bb, ${PN}-lldb-server or lldb-server, I saw `libclang` as a package without the prefix ${PN}, which I think is not common?
Apr 25 06:23:20 <khem> yeah libraries usually start with lib
Apr 25 06:23:33 <khem> I think we should use lldb and lldb-server
Apr 25 06:23:51 <roussinm> Interesting I would of though that could cause some collision?
Apr 25 06:23:57 <khem> using ${PN} helps in multilib case
Apr 25 06:24:17 <roussinm> Ha! haven't looked at multilib much.
Apr 25 06:25:18 <roussinm> I know poky provides an llvm, wondering if that could cause problem is they build lldb too?
Apr 25 06:26:01 <khem> no it does not, its only providing libLLVM purely for mesa
Apr 25 06:26:24 <khem> and that too gets shadowed if you use meta-clang, then the version from meta-clang will be used
Apr 25 06:26:53 <roussinm> ha ok, we are not using mesa, so I guess it doesn't matter then..
Apr 25 06:27:12 <khem> it would not have matterred even if you used mesa
Apr 25 06:27:22 <roussinm> right.
Apr 25 06:28:31 <khem> now a days I am finding that package compiled fine with clang but has issues with gcc, which are gcc problems I guess tables have turned clang is massively used
Apr 25 06:28:57 <khem> was playing with openCV on RISCV
Apr 25 06:29:03 <roussinm> Right, but latest benchmarks indicated  that gcc as faster compile time on most cases now.
Apr 25 06:29:23 <roussinm> I don't remember about the runtime performances though...
Apr 25 06:29:43 <khem> yes, I think clang has got many optimizations perhaps more than gcc by now so more passes
Apr 25 06:29:49 <khem> to execute
Apr 25 06:30:00 <khem> it was fast when it did not do much optimizations
Apr 25 06:30:02 <khem> :)
Apr 25 06:30:42 <khem> I think runtime is neck to neck
Apr 25 06:30:43 <roussinm> One of the advantages I really like about clang/llvm architecture is all the tools that are derived from it.
Apr 25 06:31:05 <roussinm> tidy,include-fixer, etc.
Apr 25 06:31:09 <khem> exactly, I have a suite of inhouse tools too
Apr 25 06:31:48 <khem> things like reachability analyers which are critical for security
Apr 25 06:31:50 <roussinm> It's a learning curve, but documentation is plenty and code examples are pretty complete.
Apr 25 06:32:20 <khem> and sanitizers are quite useful
Apr 25 06:32:42 <roussinm> oh ya I haven't had time to convince my team to active sanitizers
Apr 25 06:32:57 <roussinm> It took me about 5-6 months to get clang-tidy into the CI pipeline :S
Apr 25 06:33:37 <khem> I guess compile speed is no more the reason to use clang, althogh I think it still is fast for spaghetti C++ code even today ( think of browsers )
Apr 25 06:34:08 <roussinm> if you use LTO builds? I guess that has a big impact on compilation speed...
Apr 25 06:34:09 <khem> good deal with clang-tidy
Apr 25 06:34:44 <khem> you can use thinLTO, its a good compromise fullLTO is slow as you say
Apr 25 06:35:15 <roussinm> Right, I am able to use fullLto on current builds, application is relatively small.
Apr 25 06:35:54 <khem> thats good, I think if you want to use distro-wide then I think thinLTO would be easier
Apr 25 06:36:23 <roussinm> How can I get it distro-wide?
Apr 25 06:37:08 <roussinm> I would need to build the whole distro with clang I guess right?
Apr 25 06:37:41 <khem> add 'thin-lto' to DISTRO_FEATURES
Apr 25 06:38:02 <roussinm> oh ok, ya that's already there.
Apr 25 06:38:16 <khem> thats right you need to set TOOLCHAIN = "clang" globally perhaps in local.conf
Apr 25 06:38:55 <khem> on arm64/rpi4 I get better framerate with a system built with clang btw.
Apr 25 06:39:07 <roussinm> hmmm interesting, Qt projects?
Apr 25 06:39:10 <khem> when doing webGL in Webkit
Apr 25 06:39:46 <khem> no QT is last decade .. its 20s now.
Apr 25 06:39:54 <khem> browsers are king
Apr 25 06:40:12 <roussinm> Last decade?! Are you going to run 60 fps applications in WebKit?
Apr 25 06:40:14 <khem> and web assembly is future
Apr 25 06:40:16 <roussinm> embedded*
Apr 25 06:40:41 <khem> roussinm: yep wpewebkit
Apr 25 06:40:58 <roussinm> well, this blows my mind...
Apr 25 06:41:03 <khem> easily can do 60fps
Apr 25 06:41:39 <roussinm> You continue to write c++ code, right?
Apr 25 06:41:45 <roussinm> or c...
Apr 25 06:41:53 <khem> I think even chromium can do it too
Apr 25 06:42:11 <roussinm> Chromium eats all the memory!
Apr 25 06:42:22 <roussinm> I only have 1G on my device.
Apr 25 06:42:23 <khem> no new code in c/c++, new code is golang or rust or nodejs
Apr 25 06:43:02 <khem> use wpewebkit, runs fine on a system with 512MB
Apr 25 06:43:13 <roussinm> I can't believe that golang/nodejs can go as fast as c++ code... in most cases.
Apr 25 06:43:22 <roussinm> rust, sure.
Apr 25 06:43:23 <khem> and has needed bits from blink
Apr 25 06:44:02 <khem> on the contrary, go is quite fast than tou would think
Apr 25 06:44:33 <roussinm> I have done some go, I really like it, mostly for web stuff.
Apr 25 06:44:37 <roussinm> Channels, right?
Apr 25 06:44:46 <khem> since most of bad code is written doing memory management and concurrency management, and go runtime takes care of this
Apr 25 06:44:57 <roussinm> C++ has smart pointers now :)
Apr 25 06:44:57 <khem> and that makes huge differnece
Apr 25 06:45:13 <khem> yeah facelift ;)
Apr 25 06:45:27 <roussinm> We are going to start a new project
Apr 25 06:45:39 <roussinm> I might have to pitch the wpewebkit idea.
Apr 25 06:45:46 <khem> use go, or rust you will thank me in 5-10 years
Apr 25 06:46:25 <roussinm> I mean none of the team members knows Go, I'm pretty sure they will be like, nop! I don't want to use web technologies, it's slow.
Apr 25 06:46:28 <khem> yes wpewebkit, is a good idea, perhaps using wayland if you dont care, use eglfs
Apr 25 06:46:45 <roussinm> We tryed using  wayland with our Xilinx SOC, and it's pretty bad.
Apr 25 06:47:05 <khem> go is not web alone
Apr 25 06:47:06 <roussinm> We are using the libMali propertary blob.
Apr 25 06:47:36 <roussinm> Go is not only web, but it's really good a web stuff.
Apr 25 06:48:26 <khem> learning go is surprisingly easy handful of constructs
Apr 25 06:49:16 <roussinm> And there is a package manager.
Apr 25 06:49:24 <khem> c++ programmers find it quite easy transition i would think
Apr 25 06:49:37 <roussinm> I found the transition pretty easy for pet projects.
Apr 25 06:49:42 <khem> yes go-dep,
Apr 25 06:50:30 <roussinm> I think their stdlib is lacking right?
Apr 25 06:50:48 <khem> btw for wpewebkit if you are interested https://github.com/YoeDistro/meta-yoe/blob/master/recipes-core/images/yoe-kiosk-image.bb
Apr 25 06:51:32 <khem> roussinm: I have it all sorted out in yoe-distro
Apr 25 06:51:59 <khem> what do you mean with stdlib is lacking ?
Apr 25 06:52:41 <roussinm> Missing a lot of basic stuff common operation, it's been a while since last I checked, so they might've put more stuff in it since.
Apr 25 06:55:28 <roussinm> khem: I'll checkout the repository, thanks!
Apr 25 06:59:03 <roussinm> 3am here, sooo I'm out, later!
Apr 25 07:04:35 <khem> gn
Apr 25 07:04:42 * khem -> sleep ()
Apr 25 07:53:49 <yocti> New news from stackoverflow: do_compile of GNU Hello World fails in simple yocto recipe <https://stackoverflow.com/questions/61422364/do-compile-of-gnu-hello-world-fails-in-simple-yocto-recipe>
Apr 25 09:20:07 <alexb3600> Hi, I want to add openss1.0.0 on my image but there is only a recipe for openssl1.1, does anybody have an idea?
Apr 25 09:54:09 <yocti> New news from stackoverflow: What happen if not use FILE in a recipe? <https://stackoverflow.com/questions/61423842/what-happen-if-not-use-file-in-a-recipe>
Apr 25 09:56:34 <Moh3N> Hi , when my image booting from nfs server , I find temporary filesystem with some MB size , I know thease partitions created in ram dynamically, is there any way to define its size staticly in yocto ???
Apr 25 09:57:28 <Moh3N> for example : devtmpfs 169M /dev
Apr 25 09:58:03 <Moh3N> tmpfs  208M /var/volatile
Apr 25 09:58:23 <Moh3N> ho to change these Ram partition in yocto ??
Apr 25 10:03:59 <Moh3N> khem thank you for your advice, using  IMAGE_ROOTFS_EXTRASPACE_append , it helps me very much
Apr 25 10:10:06 <RP> Looks like its the sysroot patch in -next which is breaking things. Need to ask the author what they were thinking...
Apr 25 10:15:48 <Moh3N> thank you, if we Imagine that they havent any patch and I want to see the result in emulator, how I can do this ??
Apr 25 10:16:28 <Moh3N> Imagine I want to test it with qemuarm machine
Apr 25 10:17:02 <RP> Moh3N: you need to override the mount options for those partitions, its less of a yocto issue and more of a general linux configuration issue
Apr 25 10:18:51 <Moh3N> ok, I want to it be as same as my opinion when my board boots up,so I must write an script to do this at startup ??
Apr 25 11:54:35 <yocti> New news from stackoverflow: BBCLASSEXTEND="native nativesdk" <https://stackoverflow.com/questions/61425186/bbclassextend-native-nativesdk>
Apr 25 15:23:10 <khem> RP: reminding you of the binutils/gcc patches
Apr 25 15:23:45 <khem> since they will need rebuilds so you might want to try them sooner, I am looking for them to be backported to dunfell soonish
Apr 25 15:25:13 <yocti> New news from stackoverflow: yocto kernel module recipe <https://stackoverflow.com/questions/61427670/yocto-kernel-module-recipe>
Apr 25 15:26:24 <RP> khem: aren't they in next?
Apr 25 15:29:06 <RP> khem: sorry, they're not. I really thought I'd pulled them
Apr 25 17:07:32 <kanavin_home> RP: I'm going to start sending the version updates in 15-piece chunks
Apr 25 17:07:52 <kanavin_home> RP: as much as I love my bombs, I think sending 63 pieces at once is too much :)
Apr 25 17:11:26 <RP> kanavin_home: if you have a poky branch with them in, what we could do is just run it on the AB?
Apr 25 17:12:45 <RP> kanavin_home: happy to do that
Apr 25 17:14:15 <kanavin_home> RP: there is a branch, but it's several weeks old at this point (the patches are not from AUH, but handcrafted where AUH couldn't update), so I am taking the 15 piece chunks, and update them to the current latest versions
Apr 25 17:14:35 <RP> kanavin_home: ok, fair enough. The offer is there if it makes sense
Apr 25 17:15:27 <kanavin_home> RP: I don't want to overwhelm you, or me really. The AB is certain to show issues. But the goal is still to bring the outdated recipes to a small handful, and try to keep it that way.
Apr 25 17:16:00 <RP> kanavin_home: I would hate to lose the position we've got to! :)
Apr 25 18:00:05 <JaMa> kanavin_home: I know py2 isn't supported by oe-core anymore, but shouldn't this: DEPENDS += "python3-cython-native" in .inc file still use ${PYTHON_PN}?
Apr 25 18:03:08 <JaMa> but on the other hand python-numpy disappeared completely (isn't in meta-python2) and the recipe I'm carrying isn't using this .inc file, so I guess I don't mind and the .inc file could be integrated into the .bb file
Apr 25 18:29:38 <kanavin_home> JaMa: numpy explicitly dropped py2 support a while ago
Apr 25 18:43:59 <BD24> Hi can anybody help me with a problem ??? i'm noob at yocto
Apr 25 18:45:07 <BD24> i want to build an image with zeus and i receive following message: Error: Transaction check error:
**** ENDING LOGGING AT Sun Apr 26 02:59:57 2020