**** BEGIN LOGGING AT Thu Nov 28 02:59:58 2019
Nov 28 07:10:23 <Domin1k> I have problems using the cmake class from poky warrior. Within my CMakeLists i have some install rules that use "copy_directory" to install some resources. For this i need the Installation Path. Within a bitbake environment this should be something like "build/tmp/work/core2-64-miipoky-linux/myapp/1.0.1-r0/image". I would expect to get this Path
Nov 28 07:10:23 <Domin1k> form the env-var: "DISTDIR". My problem is that DISDIR isn't set at the first time when the do_install task is running. If i force a second do_install DISTDIR was set correctly. E.g. something ike: "bitbake myapp -c install && bitbake myapp -f -c install" works. Does someone has any idea what is going wrong here? I had a look at
Nov 28 07:10:24 <Domin1k> "poky/meta/classes/cmake.bbclass" within "cmake_do_install()" i see a "DESTINST='${D}'"
Nov 28 07:12:37 <Domin1k> i mean cmake_do_install does "DESTDIR='${D}'
Nov 28 07:15:42 <Domin1k> Within my CMakeLists.txt i use:set(DEST_INSTDIR "$ENV{DESTDIR}")install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory ${RESOURCE_PATH} ${DEST_INSTDIR}${DEST_RESOURCEDIR})")
Nov 28 07:45:58 <mckoan> good morning
Nov 28 07:47:17 <mckoan> Domin1k: I am working on the same problem. I'm trying to figure out what to write into CMakeLists.txt to install a minimal helloworld in CMake into a recipe
Nov 28 07:53:56 <mckoan> Domin1k: https://pastebin.com/DGXLEH7g
Nov 28 08:14:27 <Domin1k> mckoan: Something like this should work for you: set(DEST_APPDIR "/opt/app") install(TARGETS hello RUNTIME DESTINATION "${DEST_APPDIR}" COMPONENT Binaries)
Nov 28 08:35:20 <LetoThe2nd> Domin1k: mckoan i've got an example that is extremely minimal but should work as an example for autotools, cmake and meson: https://github.com/LetoThe2nd/this_is
Nov 28 08:36:21 <LetoThe2nd> i used it during the live coding session #4 or #5, not quite sure, so it at least worked back then. :)
Nov 28 08:37:59 <mckoan> LetoThe2nd: thanks :-)
Nov 28 08:38:17 <mckoan> LetoThe2nd: does it use/need autotools too?
Nov 28 08:47:18 <LetoThe2nd> nope
Nov 28 08:47:53 <LetoThe2nd> you should be able to build it three ways. 1) inherit autotools 2) inherit cmake 3) inherit meson
Nov 28 08:48:23 <LetoThe2nd> any multiconfig specialist around i can poke?
Nov 28 08:48:27 <LetoThe2nd> RP: ^^^^^^^
Nov 28 08:49:07 <LetoThe2nd> we're seeing weird build dependency problems when sstate is being used after a change
Nov 28 08:58:39 <Domin1k> LetoThe2nd: You're minimal cmake example does not cover my issue. Within my CMakeLists.txt i have some install rules that use "copy_directory" to install some resources. For this i need the Installation Path. Within a bitbake environment this should be something like "build/tmp/work/core2-64-miipoky-linux/myapp/1.0.1-r0/image". I would expect to
Nov 28 08:58:39 <Domin1k> get this path form the env-var: "DESTDIR". My problem is that DESTDIR isn't set at the first time when the do_install task is running. If i force a second do_install DESTDIR was set correctly. E.g. something ike: "bitbake myapp -c install && bitbake myapp -f -c install" works. I had a look at "poky/meta/classes/cmake.bbclass" within
Nov 28 08:58:42 <Domin1k> "cmake_do_install()" i see a "DESTDIR='${D}'"
Nov 28 09:01:08 <mckoan> LetoThe2nd: your example doesn't work into a recipe though
Nov 28 09:01:30 <LetoThe2nd> mckoan: i'm pretty sure it worked in a recipe :) what breaks now?
Nov 28 09:02:14 <LetoThe2nd> Domin1k: i see. no idea, sorry.
Nov 28 09:03:48 <mckoan> LetoThe2nd: nevermind I needed to run cleansstate
Nov 28 09:04:44 <LetoThe2nd> mckoan: kay
Nov 28 09:08:29 <mckoan> LetoThe2nd: next step, how to build a shared library used by my hello app
Nov 28 09:08:46 <mckoan> here thinghs looks more complicated
Nov 28 09:09:36 <LetoThe2nd> mckoan: actually its not that complicated, but i don't have a stripped down example that i can just hand out
Nov 28 09:09:53 <mckoan> ERROR: studentlib-0.1-r0 do_package_qa: QA Issue: -dev package contains non-symlink .so: studentlib-dev path '/work/armv5e-poky-linux-gnueabi/studentlib/0.1-r0/packages-split/studentlib-dev/usr/lib/libtestStudent.so' [dev-elf]
Nov 28 09:10:15 <mckoan> libtestStudent.so is created but not installed
Nov 28 09:10:50 <LetoThe2nd> mckoan: because the library target needs its own install directive in cmake
Nov 28 09:11:23 <LetoThe2nd> mckoan: my general approach is that i have a subdirectoy with its own CMakeLists.txt that builds/installs the lib
Nov 28 09:18:56 <GeneralStupid> I need to write a patch for u-boot to support a new board? (RAM settings; "fancy ;)" boot layout)
Nov 28 09:20:27 <mckoan> GeneralStupid: usually you have two options: 1. manage a new u-boot repo 2. patch an existing one
Nov 28 09:20:50 <mckoan> GeneralStupid: I prefer 1
Nov 28 09:23:08 <GeneralStupid> mckoan: I come from bare metal development... So maybe this sounds stupid but do you update uboot on the devices you create?
Nov 28 09:23:18 <GeneralStupid> Or is uboot "uncritical"
Nov 28 09:25:17 <mckoan> GeneralStupid: your bootloader needs to be customized for your HW, particularly DRAM and storage
Nov 28 09:27:07 <LetoThe2nd> GeneralStupid: usually once you got a working setup that suits your needs, u-boot is mostly left untouched.
Nov 28 09:27:09 <jofr> GeneralStupid: Do you mean "out in the real world"? I don't update u-boot. But I have implemented a mechanism that updates the u-boot-environment from our (custom) update-system.
Nov 28 09:27:47 <LetoThe2nd> GeneralStupid: it depends a bit on your boot strategy and mitigation strategy for forced HW changes, but it is certainly something that is mostly left alone once it works well enough
Nov 28 09:28:57 <GeneralStupid> thanks, that makes the decission a bit easier
Nov 28 09:29:30 <qschulz> GeneralStupid: u-boot is rarely updated. See it as a BIOS basically. Do you often update the BIOS of your PC? Only for very bad bugs and security fixes.
Nov 28 09:29:49 <GeneralStupid> or never...
Nov 28 09:29:50 <jofr> Sidenote: I don't recommend doing a custom update-system, though. I'm doing it merely due to compatibility reasons with pre-existing (barebones) systems.
Nov 28 09:30:16 <GeneralStupid> The company i worked before we also rarely updated the bootloader. (even during development)
Nov 28 09:30:19 <qschulz> and if you mess up the upgrade, your board is a brick until you get someone to pick up the device and reflash it manually (or some clever A/B updates if the BootROM supports it)
Nov 28 09:30:38 <LetoThe2nd> whoever thinks rolling a custom update system these days fully deserves the pains it causes.
Nov 28 09:31:17 <jofr> LetoThe2nd: Second that.
Nov 28 09:31:30 <GeneralStupid> LetoThe2nd: but on the other hand: if you put a network connection to your device you need to ship updates when needed
Nov 28 09:31:36 <LetoThe2nd> we actually make sure we can update the whole boot chain in field these days, but rarely do so.
Nov 28 09:31:42 <LetoThe2nd> GeneralStupid: nope.
Nov 28 09:32:17 <GeneralStupid> LetoThe2nd: i dont talked about uboot, i meant the linux system itself... You dont think so?
Nov 28 09:32:20 <LetoThe2nd> GeneralStupid: none of our usecases would accept us shipping updates through a network connection.
Nov 28 09:33:07 <LetoThe2nd> we have to *provide* updates, thats the point. we do not have to ship them to the devices, and especially not through a network connection.
Nov 28 09:33:44 <qschulz> GeneralStupid: for U-Boot, you might be interested in a talk I gave ~2y ago: https://www.youtube.com/watch?v=5E0sdYkvq-Q https://elinux.org/images/2/2a/Schulz-how-to-support-new-board-u-boot-linux.pdf
Nov 28 09:34:03 <GeneralStupid> Is some of you copying a zipped image into a ramdisk? Or do you run from nand or nor flash?
Nov 28 09:34:18 <LetoThe2nd> GeneralStupid: depends (TM)
Nov 28 09:34:19 <qschulz> GeneralStupid: porting U-Boot to imx6 boards, it's very high level (no real code involved, just "put stuff here and there")
Nov 28 09:34:40 <GeneralStupid> qschulz: haha, i googled your slides already yesterday!!!
Nov 28 09:35:23 <GeneralStupid> qschulz: looked very helpful but iam unsecure about patching or forking ...
Nov 28 09:35:46 <qschulz> GeneralStupid: we use SWUpdate here, a little bit customized though.
Nov 28 09:36:01 <GeneralStupid> and i had the idea to put the environment on two different partitions to be able to switch if one is broken
Nov 28 09:36:04 <qschulz> GeneralStupid: Well, you'll have to get your hands dirty or else the board won't be supported :D
Nov 28 09:36:31 <GeneralStupid> qschulz: actually till now yocto saved a lot of time, so this is where it begins to get funny
Nov 28 09:36:47 <qschulz> GeneralStupid: U-Boot supports this already. Look up for CONFIG_ENV_.*_REDUND
Nov 28 09:37:47 <qschulz> e.g. CONFIG_ENV_OFFSET_REDUND (but not only, you need other variables)
Nov 28 09:38:01 <Emantor> qschulz: Porting barebox to imx6 boards is also really easy, I wrote a blog post about it https://www.pengutronix.de/de/blog/2019-05-14-barebox_ccimx6ulsbcpro.html
Nov 28 09:38:08 <GeneralStupid> i will dig into the custom board file... Then i will ask some more stupid questions :D
Nov 28 09:39:04 <qschulz> GeneralStupid: good luck :)
Nov 28 09:39:09 <GeneralStupid> qschulz: thanks
Nov 28 09:39:15 <qschulz> Emantor: never had the chance to work on Barebox, thanks for the link
Nov 28 09:39:54 <Emantor> Give it a try, the user experience is much nicer. But I am biased ofc ;-)
Nov 28 09:41:01 <qschulz> Emantor: former colleague of mine was fond of it as well but the project is suffering from U-Boot popularity :/
Nov 28 09:41:51 <Emantor> Yes, it is how it is, everybody reaches to U-Boot by default.
Nov 28 09:51:06 <hyper_dave> Has anyone got EGLFS with tslib touchscreen working?
Nov 28 10:09:57 <LetoThe2nd> hyper_dave: you're much more likely to get an answer if you can actually ask a question about the specific point where you are stuck
Nov 28 10:11:22 <hyper_dave> I got EGLFS working and tslib working with ts_test.. It is calibrated. now when I run a Qt application with -plugin tslib I can't get the calibration working
Nov 28 10:11:51 <hyper_dave> I have set environment variables set for tslib
Nov 28 10:15:25 <LetoThe2nd> so it actually boils down to: "my qt application ignores tslib calibration." right?
Nov 28 12:11:42 <hyper_dave> LetoThe2nd: I pinged out.. Anything new?
Nov 28 12:12:08 <hyper_dave> Also how do i add x11 and xinit to an image?
Nov 28 12:32:45 <RP> If anyone has some time, https://bugzilla.yoctoproject.org/show_bug.cgi?id=13663 is a nice self contained easy to reproduce bug
Nov 28 12:32:45 <yocti> Bug 13663: normal, High, ---, ross.burton, NEW , oeqa doesn't handle skipped classes of tests correctly
Nov 28 12:34:36 <RP> you don't even need to run builds! :)
Nov 28 12:40:58 <rburton> hyper_dave: copy core-image-x11 if you want a base X environment
Nov 28 12:44:43 <LetoThe2nd> hyper_dave: why anything new, i'm still trying to understand your actual problem.
Nov 28 12:44:49 <LetoThe2nd> 10:15 < LetoThe2nd> so it actually boils down to: "my qt application ignores tslib calibration." right?
Nov 28 12:45:06 <hyper_dave> yes
Nov 28 12:45:51 <LetoThe2nd> hyper_dave: in that case, please put your application start script / environment into as pastebin so we can look at it.
Nov 28 12:46:59 <tgamblin> RP: Sorry, guess you had that bug buttoned up before I got to the fix myself
Nov 28 12:56:01 <RP> tgamblin: right, I got so far with it and then the fix became clear. There is the other one if you're interested though!
Nov 28 12:56:30 <tgamblin> RP: sure
Nov 28 12:57:51 <RP> tgamblin: I've probably got other things I need to see to next, that one is in a decent place or someone else to pick up
Nov 28 13:18:31 <LetoThe2nd> RP: can i get your input on this - 1) build an image that depends on another mc-image. 2) change something in a recipe that affects the mc-image, to something that is already in sstate cache 3) bitbake image. effect is: the mc-image gets rebuilt, but not image. then rerun bibtake image: mc-image doesn't get rebuit, image does
Nov 28 13:24:29 <tgamblin> RP: which other bug are you referring to?
Nov 28 13:26:37 <hyper_dave> LetoThe2nd: https://hastebin.com/sesawepewe.js
Nov 28 13:37:23 <LetoThe2nd> hyper_dave: and you have verified that all those files exist and can be read by the applicaiton?
Nov 28 13:37:49 <hyper_dave> yes. ts_test works fine
Nov 28 13:42:04 <LetoThe2nd> no, thats not what i said
Nov 28 13:44:41 <LetoThe2nd> i was thinking about users and rights
Nov 28 13:44:53 <LetoThe2nd> you might also want to strace your applicatoin startup
Nov 28 13:47:24 <hyper_dave> LetoThe2nd: I am running it as root
Nov 28 13:54:27 <LetoThe2nd> hyper_dave: i'd still veify through stracing that there are no errors left. then have a deeper dive at the qt startup process, maybe also ask them if there's additional magic needed.
Nov 28 14:01:18 <RP> tgamblin: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13663
Nov 28 14:01:19 <yocti> Bug 13663: normal, High, ---, ross.burton, NEW , oeqa doesn't handle skipped classes of tests correctly
Nov 28 14:02:29 <tgamblin> alright, thanks
Nov 28 14:15:35 <qschulz> hyper_dave: I remember Qt being very quiet even when failing. I found export QT_LOGGING_DEBUG=1 and export QT_LOGGING_RULES="*.debug=true" back then
Nov 28 14:16:04 <qschulz> I think I did a QT_LOGGING_RULES="qt.*=true" or something like that. Gave me a ton of information that I didn't have otherwise
Nov 28 14:22:40 <milloni> did trace-cmd get removed http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-kernel/trace-cmd/trace-cmd_git.bb?h=bernard ?
Nov 28 14:36:03 <rburton> milloni: commit faa46ac06bf1624d0120f1fcfb00b5ad31948b44
Nov 28 14:36:03 <rburton> Author: Ross Burton <ross.burton@intel.com>
Nov 28 14:36:05 <rburton> Date:   Thu Jun 14 14:31:08 2018 +0100
Nov 28 14:36:05 <rburton>     trace-cmd: remove
Nov 28 14:36:07 <rburton>     Perf is superior in most ways and is preferred.
Nov 28 14:36:19 <rburton> use perf
Nov 28 15:14:40 <rburton> whoa how did i not know about the ncurses bitbake ui
Nov 28 15:26:11 <armpit> we wont hold it against you
Nov 28 15:29:27 <RP> rburton: heh, been years since that was touched
Nov 28 15:42:17 <yocti> New news from stackoverflow: Yocto / OE : recipe with CMake install a shared library .so <https://stackoverflow.com/questions/59091938/yocto-oe-recipe-with-cmake-install-a-shared-library-so>
Nov 28 16:00:48 <mcfrisk> puzzled: packagegroup RDEPENDs on foo-tests, recipe foo provides the binary package and RPROVIDES foo-tests, but bitbake parses complains "ERROR: Nothing PROVIDES foo-tests" but lists close matches foo and says foo RPROVIDES foo-tests.
Nov 28 16:48:16 <rburton> PROVIDES != RPROVIDES
Nov 28 16:49:02 <rburton> ah no i can't read. yeah thats odd something isn't right.  i'd be bitbake -e'ing to check the exported deps
Nov 28 16:58:28 <LetoThe2nd> *le sigh* ileExistsError: [Errno 17] File exists: 'python2' -> '/local/build/tmp/hosttools/python'
Nov 28 16:58:53 <LetoThe2nd> ubuntu 18.04 - what am i missing?
Nov 28 17:02:02 <rburton> well easy fix is to delete your tmp
Nov 28 17:03:19 <rburton> LetoThe2nd: does the error have any class/line numbers?
Nov 28 17:12:31 <yocti> New news from stackoverflow: Integrating Python monorepo application into Yocto <https://stackoverflow.com/questions/59093345/integrating-python-monorepo-application-into-yocto>
Nov 28 17:14:25 <LetoThe2nd> rburton: full log: https://pastebin.com/6wJaXdxr
Nov 28 17:15:21 <rburton> hm did you add python to HOSTTOOLS manually?
Nov 28 17:15:36 <LetoThe2nd> not explicitly. naked poky clone, tired master and zeus
Nov 28 17:15:50 <rburton> blank tmpdir when starting?
Nov 28 17:16:00 <LetoThe2nd> completely blank
Nov 28 17:16:02 <rburton> wtf
Nov 28 17:17:01 <LetoThe2nd> bitbake core-image-full-cmdline
Nov 28 17:17:04 <rburton> presumably  '/local/build/tmp/hosttools/python' does in fact exist
Nov 28 17:17:14 <rburton> and how about python2 in the same directory?
Nov 28 17:17:22 <LetoThe2nd> naked ubuntu 18.04, added only the package list from the qs
Nov 28 17:17:28 <rburton> python should point at python2, and python2 should point at /usr/bin/python2
Nov 28 17:19:21 <rburton> kergoth: so i did a hack and now cmd-b in vscode asks me what i want to build, it fires bitbake for those targets, and reports errors in the footer
Nov 28 17:19:24 <armpit> RP, so what are we going to do about 3.0.1-rc3
Nov 28 17:19:40 <LetoThe2nd> rburton: http://paste.ubuntu.com/p/7BKdgrR62g/
Nov 28 17:20:23 <LetoThe2nd> rburton: (SIGFAMILY, back in ~2hrs or such)
Nov 28 17:20:32 <rburton> kergoth: https://pastebin.com/TBKxhuwQ is my .vscode/tasks.json. very prototype and hardcodes the env script etc but sort of works
Nov 28 17:20:55 <rburton> LetoThe2nd: so why is it trying to rebuld that lot this makes no sense
Nov 28 17:21:11 <rburton> ooo
Nov 28 17:21:34 <armpit> RP, nm.. it went into QA
Nov 28 17:25:24 <rburton> LetoThe2nd: ah huh
Nov 28 17:25:48 <rburton> LetoThe2nd: where is your python2 entry
Nov 28 17:25:55 <rburton> LetoThe2nd: should have make a python2 alongside the python2.7
Nov 28 17:42:36 <yocti> New news from stackoverflow: Trouble building u-boot for gumstix overo on yocto "thud" release <https://stackoverflow.com/questions/59093849/trouble-building-u-boot-for-gumstix-overo-on-yocto-thud-release>
Nov 28 18:10:16 <RP> nrossi: confirmed as much as I can its your patch. Not 100% isolated but I think you'll need to look into it
Nov 28 18:10:34 <RP> nrossi: mail on the list, I'm going to drop from -next for now
Nov 28 18:53:58 <kergoth> rburton: nice
Nov 28 18:54:10 <kergoth> rburton: thanks, i'll have to play with that
Nov 28 19:20:40 <rburton> kergoth: feel free to share any improvements.  want to try and figure out a way of telling it where the builddir is, i guess that means a new extension though
Nov 28 19:21:10 <kergoth> hmm, would be nice to be able to reference something in the workspace settings, but i don't know if tasks support that
Nov 28 19:21:20 <rburton> well there's already a bitbake extension so maybe thats easy to extend?
Nov 28 19:21:30 <rburton> my working model is my poky clone has about 10 build dirs in...
Nov 28 19:22:14 <kergoth> ah yes, would need to prompt on exec in a case like that, but it'd be nice to have a nice selection interface rather than having to type the path
Nov 28 19:23:20 <rburton> hm could have one of those tasks that persists, first time asks for the build dir and then just re-calls bitbake
Nov 28 19:34:52 <kergoth> huh, thats a good idea if you can pull it off, could even run a memres as long as the task is going
Nov 28 20:23:47 <rburton> right
Nov 28 20:26:07 * RP would love to see more use of memres
Nov 28 20:27:41 * armpit has dos flash backs to creating memory resident drives
Nov 28 21:06:57 <RP> armpit: and himem problems
Nov 28 21:07:21 <RP> JPEW: I found another bug in my patch during testing, looks like I'll have to retest
Nov 28 21:14:43 * RP just made reproducibility the default for poky
Nov 28 21:15:17 <RP> which removes one piece of delta from my testing and hopefully puts me on a path to sanity. Relatively anyway.
Nov 28 21:15:17 <kergoth> nice
Nov 28 21:15:28 <RP> we should perhaps do it for nodistro too
Nov 28 21:17:44 <RP> armpit: Just FYI I stopped the existing -next builds as once was broken and I had all the info I needed from the other. I've started a new -next to test hashequiv
Nov 28 21:18:17 <RP> armpit: the scheduled master run in a few hours should test everything else we need
Nov 28 22:51:31 <rburton> RP: fired a ross/next to chase your builds.  *should* be all green.
Nov 28 23:33:40 <tlwoerner> wow, this is a noodle scratcher... i have a PackageB building using cmake which DEPENDs on PackageA
Nov 28 23:34:41 <tlwoerner> it *looks* like the cmake of PackageB is using an absolute path to the recipe-sysroot of PackageA
Nov 28 23:35:48 <tlwoerner> PackageA had been cleaned or removed or something, then later when PackageB tried to build it couldn't find the link because PackageA had simply been re-instated from sstate (so recipe-sysroot was missing)
Nov 28 23:36:09 <tlwoerner> yet the dependencies in the recipe look fine, and the file it's looking for is found in its own recipe-sysroot
Nov 28 23:37:07 <tlwoerner> oh, this is Warrior
Nov 28 23:40:58 <tlwoerner> oh wait... somehow ninja is involved, and it's ninja that's messing up (apparently)
Nov 28 23:58:22 <tlwoerner> and deeper i go... even if i switch cmake away from ninja (and use regular unix makefiles, i.e. OECMAKE_GENERATOR = "Unix Makefiles") i still get the error, same problem: PackageB depends on a library from PackageA and even though the recipe-sysroot for PackageB includes the required file, the make/ninja system is looking for the file in PackageA's recipe-sysroot
Nov 29 00:03:44 <bluelightning> tlwoerner: presumably that path is being encoded into a file that gets installed by PackageA, and PackageB's configure step picks it up
Nov 29 00:04:24 <tlwoerner> bluelightning: let me check...
Nov 29 00:08:38 <tlwoerner> bluelightning: yes! found it
Nov 29 00:09:05 <tlwoerner> PackageA-dev/usr/lib/PackageA-targets.cmake
Nov 29 00:10:32 <tlwoerner> this doesn't *appear* to be a mistake in the recipe, but rather something that's part of cmake (or maybe how we're using cmake?)
**** ENDING LOGGING AT Fri Nov 29 02:59:58 2019