**** BEGIN LOGGING AT Thu Mar 26 03:04:32 2020
Mar 26 05:31:21 <sj634> thanks armpit, I can see that my dtb is coming from meta-xilinix kate ./meta-xilinx-bsp/conf/machine/microzed-zynq7.conf but now I am still struggling to find how dts is compiled to dtb here?
Mar 26 05:41:51 <sj634> I don't think it is using meta-class since I get the following error messages - $bitbake virtual/dtb -c compile -f
Mar 26 05:41:52 <sj634> core layer names it is compatible with.
Mar 26 05:41:52 <sj634> |######################################################################################################################################################################| Time: 0:00:00
Mar 26 05:41:54 <sj634> virtual/dtb but was skipped: incompatible with machine microzed-zynq7 (not in COMPATIBLE_MACHINE)
Mar 26 05:50:25 <sj634> I don't have device-tree.bb so I am not sure what rule is it using to generated dtb
Mar 26 05:53:04 <sj634> Found this file -  ./meta/classes/kernel-devicetree.bbclass but I don't know how to amend this file so that it generates the __symbol__  so that overlay can work.
Mar 26 05:53:29 <sj634> Is there any bitbake command to just generate the dtb file?
Mar 26 07:43:55 <mcfrisk> sigh, list server change. googling no longer works. https://lists.openembedded.org/pipermail/openembedded-core/2018-May/151097.html -> 404 page not found
Mar 26 08:42:17 <qschulz> sj634: most likely the kernel is building it for you. You have to patch both dtc and the makefile used by the kernel or write a yocto recipe for building a dtb with a dts on your own.
Mar 26 08:43:13 <qschulz> sj634: I remember doing that for Atmel: https://github.com/QSchulz/linux-at91/commit/deff47fd469863f301b452a6c853fb803af7170d and https://github.com/QSchulz/linux-at91/commit/c1ddbd31090bc8d82d5df38af2a12e8c053bb01f
Mar 26 10:07:48 <Ninic0c0> Hello guys! What is the best way to set a variable from a python function (in a bbclass) with an other varibale value in order to use this variable in other function inside the same bbclass file ? https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#functions-you-can-call-from-within-python explain just with string
Mar 26 10:07:49 <Ninic0c0> :S
Mar 26 10:11:20 <qschulz> d.setVar("MYVAR", d.getVar("MYOTHERVAR"))?
Mar 26 10:11:47 <qschulz> but variables aren't shared between tasks
Mar 26 10:12:47 <qschulz> Ninic0c0: your question is actually hard to understand. What exactly do you want to do?
Mar 26 10:22:59 <mabnhdev> Hi all.  I'm working in Zeus.  I want to downgrade lvm2/libdevmapper back to the versions used in Sumo.  I copied sumo's recipes-support/lvm2 to my custom layer.  Added PREFERRED_VERSION_lvm2 and PREFERRED_VERSION_libdevmapper to my conf file.  When bitbake parses, it complains "preferred version 2.02.171 of lvm2 not available (for item
Mar 26 10:22:59 <mabnhdev> libdevmapper) versions of lvm2 available: 2.03.02".  After the parsing, I get an error that multiple versions of lvm2 are due to be built.  It seems to be ignoring my PREFERRED_VERSION_lvm2 = "2.02.171" directive.  I can't figure out where I'm going wrong.  versions of lvm2 available: 2.03.02
Mar 26 10:29:58 <yocti> New news from stackoverflow: Yocto device-tree interrupt on certain pin <https://stackoverflow.com/questions/60865100/yocto-device-tree-interrupt-on-certain-pin>
Mar 26 10:32:35 <Ninic0c0> qschulz hello :)  In fact should be really simple I have added 2 custom functions, and I want to share a simple variable.
Mar 26 10:35:48 <qschulz> Ninic0c0: can't, variables set in a task are set for the task only
Mar 26 10:36:18 <qschulz> Ninic0c0: but variables set in python __anonymous (which is executed at parsing time IIRC), are recipe-wide
Mar 26 10:38:34 <Ninic0c0> qschulz workaround possible ? create empty "global var" outside of function and call d.setVar/d.getVar from both functions ?
Mar 26 10:38:55 <qschulz> no
Mar 26 10:41:08 <Ninic0c0> qschulz ok :(  do you know it's not possible (just to understand) because looks a simple thing no ?
Mar 26 10:42:54 <qschulz> 11:35     qschulz| Ninic0c0: can't, variables set in a task are set for the task only
Mar 26 10:52:25 <copycat_88> Hi there
Mar 26 10:52:25 <copycat_88> Question regarding the Siemens kas. How can I use env variables inside kas yaml files? I need to specify the path to directory with repo, based on the kas workdir
Mar 26 10:53:04 <copycat_88> e.g:
Mar 26 10:53:04 <copycat_88> repos:
Mar 26 10:53:04 <copycat_88>   meta-my-own-meta:
Mar 26 10:53:04 <copycat_88>     path: "$KAS_WORK_DIR/meta-my-own-meta"
Mar 26 10:53:45 <copycat_88> Aww, sorry for multi-messaging, still can't handle this IRC feature with newlines
Mar 26 10:54:14 <mabnhdev> More details about my lvm2 backport problem here - https://gist.github.com/mabnhdev/fe1efed09b4c0159a394bdbae54f3fa9
Mar 26 10:54:58 <copycat_88> BTW,  path: "${TOPDIR}/../meta-my-own-meta" is working solution, but it looks, well, ugly
Mar 26 10:55:28 <LetoThe2nd> copycat_88: kas can directly reference a layer in its own repository.
Mar 26 10:56:34 <LetoThe2nd> copycat_88: like this: https://github.com/LetoThe2nd/meta-containerization
Mar 26 10:59:09 <copycat_88> LetoThe2nd: yeah, this works when layer is places directly in kas repo, but in my case layer is insise sub-directory under kas repo. Like this:
Mar 26 10:59:10 <copycat_88> kas_repo/meta-my-own-meta/conf/layer.conf
Mar 26 11:00:03 <copycat_88> I can remove 'path' in case of structure like this: kas_repo/conf/layer.conf, but still can't get any clue how to use sub-directory
Mar 26 11:01:29 <LetoThe2nd> i just checked, our own setup is a little bit different so i can't give any good advice, sorry.
Mar 26 11:25:09 <milloni> is there a date for dunfell release yet (more specific than "April")?
Mar 26 11:30:10 <yocti> New news from stackoverflow: How to create a patch or recipe to change kernel config <https://stackoverflow.com/questions/60865874/how-to-create-a-patch-or-recipe-to-change-kernel-config>
Mar 26 11:34:13 <LetoThe2nd> milloni: "when its done".. or "when no showstopping bugs exist anymore"... or "once people start submitting"... or...
Mar 26 11:36:17 <milloni> ok
Mar 26 11:36:36 <LetoThe2nd> :)
Mar 26 11:36:44 <milloni> is there a tracker i can look at?
Mar 26 11:37:30 <LetoThe2nd> bugzilla
Mar 26 11:37:55 <LetoThe2nd> and there is https://wiki.yoctoproject.org/wiki/Weekly_Status
Mar 26 12:07:56 <milloni> LetoThe2nd: thanks
Mar 26 12:28:45 <dv|2> can't prevent generating -src.rpm packet for my private recipe. How can I avoid it for one closed-source recipe?
Mar 26 12:35:34 <mihai> dv|2, FILES_${PN}-src = ""
Mar 26 12:42:26 <dv|2> mihai, perfect! it works
Mar 26 12:57:46 <dv|2> mihai, oh, no. doesn't work... :(
Mar 26 13:03:39 <milloni> oh, dunfell will be an lts, nice
Mar 26 13:04:15 <LetoThe2nd> milloni: be sure to carefully read the LTS menaing, please.
Mar 26 13:04:22 <mihai> dv|2, src pkg still generated?
Mar 26 13:04:31 <dv|2> yes
Mar 26 13:04:49 <milloni> LetoThe2nd: 2 years?
Mar 26 13:05:14 <dv|2> I even did FILES_${PN}-closed += "/usr/src/debug/${PN}/*" and PACKAGES = "${PN}-closed ${PN}-dbg ${PN}" in my recipe
Mar 26 13:05:21 <dv|2> and PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
Mar 26 13:05:30 <dv|2> - doesn't work
Mar 26 13:06:23 <qschulz> dv|2: isn't the package just empty?
Mar 26 13:06:44 <dv|2> it is not empty
Mar 26 13:07:27 <qschulz> dv|2:  15:15     rburton| dv|2: -dbg and -src packages are automatically generated without any input from the recipe, so if you want them to not be, set that
Mar 26 13:07:38 <LetoThe2nd> milloni: no, what the S in "LTS" actually includes, and what it does not include. specifically, just because something is declared LTS it doesn't mean it magically receives all bug-/security fixes.
Mar 26 13:08:18 <LetoThe2nd> milloni: so if you or your company actually care about LTS, consider contributing please.
Mar 26 13:08:25 <milloni> LetoThe2nd: ack
Mar 26 13:08:36 <milloni> that's true for pretty much everything
Mar 26 13:09:44 <dv|2> qschulz, oh, seems I found why. had to do cleanall for the recipe
Mar 26 13:09:45 <milloni> LetoThe2nd: who are you looking for for the lts maintainer? i would consider applying but i need to know more
Mar 26 13:11:31 <LetoThe2nd> milloni: monitoring upstream recipes and fixes, contributing patches... you don't have go 0 to maintainer!
Mar 26 13:13:30 <milloni> LetoThe2nd: sure, i only said i would consider this - i work with yocto quite a lot
Mar 26 13:13:42 <milloni> what kind of time commitment would you require from the mainainter?
Mar 26 13:14:25 <LetoThe2nd> milloni: if you are seriously thinking about getting involved, talk to RP or armpit
Mar 26 13:15:06 <LetoThe2nd> milloni: like i said, there's no need to jump directly to maintainer. producing patches and monitoring things is also a great aid.
Mar 26 13:15:07 <milloni> thanks - RP, armpit - if you can answer the question above i'd appreciate it, or i'd catch you later
Mar 26 13:16:27 <milloni> LetoThe2nd: i've only sent patches to agl - the yocto build that we work with is so old that we usually don't encounter issues that are still relevant to upstream
Mar 26 13:17:01 <milloni> but i will definitely try to contribute more in the future
Mar 26 13:17:49 <milloni> LetoThe2nd: how would i go about finding issues to send patches for? bugzilla again? how do i filter for ones that would be the most useful
Mar 26 13:19:54 <LetoThe2nd> milloni: bugzilla, or talking to RP. he knows best where he needs assistance
Mar 26 13:23:18 <milloni> ok, thanks for the tips, i'll try to see how i can help later
Mar 26 13:30:34 <yocti> New news from stackoverflow: Need to use git in yocto OS <https://stackoverflow.com/questions/60867932/need-to-use-git-in-yocto-os>
Mar 26 13:39:31 <JPEW> milloni: If your are looking for some "easier" bugs to get started, there is: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
Mar 26 13:40:58 <milloni> JPEW: thanks
Mar 26 13:43:22 <JPEW> milloni: There is also a call-in meeting to triage bugs every thursday: https://www.yoctoproject.org/public-virtual-meetings/
Mar 26 13:43:55 <milloni> oh interesting
Mar 26 13:50:48 <RP> milloni: hi! With the LTS maintainer we're trying to find someone who can put dedicated time to the job. Its a tricky one as we know the work will have spikes as issues arise.
Mar 26 13:51:35 <RP> milloni: Its hard to know which bugs make sense to which people as a lot depends on your background
Mar 26 13:55:07 <milloni> RP: i guess what i'm asking for is whether you're looking for someone to be involved in it as a full-time job or a side hobby
Mar 26 13:55:57 <RP> milloni: it needs to be more than a hobby
Mar 26 13:56:28 <milloni> RP: well - yeah - not the best word for it, but hopefully you see what i mean
Mar 26 13:56:51 <milloni> would someone holding a full time job still have time to do it?
Mar 26 13:59:34 <RP> milloni: we're guessing its a half time job for someone. The project does have some funding and we're exploring what options we might have in that context
Mar 26 14:05:50 <milloni> RP: ok, thanks, probably too much for me but i'll look around see if i know any people who might be interested
Mar 26 14:13:15 <sstiller> in poky-zeus, glibc-locale creates /usr/lib/locale/. This is an empty directory that leads to an error because it does not belong to any package. Any idea why this happens?
Mar 26 16:04:47 <khem> RP: you can take binutils patch as well, It came out on my world builds overnight
Mar 26 16:24:22 <RP> khem: I have concerns about dropping reautoconf, its a step backwards in som ways
Mar 26 16:24:49 <RP> khem: also, the glibc patch changing configure and configure.ac is risky, we've had problems with this before
Mar 26 17:05:49 <mauz555> hello what is the difference between https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto ?
Mar 26 17:06:06 <mauz555> using yocto to build my system should I stick with linux-yocto ?
Mar 26 17:12:28 <rburton> mauz555: linux-yocto just has some fixes on top of linus's tree
Mar 26 17:12:36 <rburton> you can see it at git.yoctoproject.org
Mar 26 17:25:45 <mauz555> rburton: sorry how do you see that ?
Mar 26 17:36:06 <khem> RP: I am cherry-picking patches from upstream, so why can't we handle thaat
Mar 26 17:36:35 <khem> its seems a bit less intuitive do drop valid changes from upstream patches
Mar 26 17:36:41 <RP> khem: Its all about file timestamps and the potential for autoconf not to want to change a newer file
Mar 26 17:37:18 <RP> khem: its also a real pain as it depends on the accuracy of the timestamps on the filesystems people build on
Mar 26 17:38:04 <khem> not patching configure is then a workaround to trick the system to treat it as old file ?
Mar 26 17:38:15 <khem> that seems wrong as well
Mar 26 17:38:34 <RP> khem: its all less than ideal :(
Mar 26 17:38:45 <RP> khem: but we do have real problems with this :(
Mar 26 17:39:08 <khem> perhaps add a touch cmd in autotools class to configure.ac after patching might be better IMOP
Mar 26 17:39:34 <RP> khem: you just broke your binutils change and gcc ;-)
Mar 26 17:39:47 <RP> (yes, I agree but its not quite so simple)
Mar 26 17:42:12 <RP> khem: I think autotools configure deletes the confiure scripts so we're probably ok from that issue in this case
Mar 26 17:43:51 <khem> how did I break binutils change ?
Mar 26 17:43:54 <kanavin_home> rburton: RP: so what do we do with gdk-pixbuf? just drop the bad fuzzing stuff?
Mar 26 17:44:20 <RP> kanavin_home: sorry, been meaning to reply. I did talk to Ross and upstream.
Mar 26 17:44:33 <rburton> kanavin_home: i'd say disable that test.  does gnome-desktop-testing-runner let you skip a test?
Mar 26 17:45:02 <khem> RP: autotools based packages usually patch both configure.ac and configure together in same patch, so it will be another quirk to teach people to not patch configure part
Mar 26 17:45:15 <RP> kanavin_home: they commented "meson test --no-suite=slow" would be better but I'm not sure we can translate that to the test runner we use
Mar 26 17:45:22 <rburton> khem: i'd say patching configure *and* configure.ac is bad form
Mar 26 17:45:26 <rburton> khem: just patch .ac
Mar 26 17:45:35 <RP> kanavin_home: The suggestion was to just disable it
Mar 26 17:46:01 <RP> khem: This has been the case all along, we ask people not to patch configure
Mar 26 17:47:46 <RP> kanavin_home: I'm still worried there is some subtle underlying bug here
Mar 26 17:48:01 <rburton> RP: the memory usage thing isn't an underlying bug its a stupid test
Mar 26 17:48:11 <rburton> assuming its always the randomly modified test case
Mar 26 17:48:46 <RP> rburton: should the mem usage spike and the app crash with a corrupted image though?
Mar 26 17:49:09 <RP> rburton: and why is it doing that with a loader we don't even build?
Mar 26 17:49:23 <khem> RP: I see that but did we look at more abstract solution instead ?
Mar 26 17:50:44 <RP> khem: I don't think we ever found something which worked
Mar 26 17:56:59 <khem> RP: as such the patches trees are unbuildable outside OE so my motivation was to make the trees work
Mar 26 17:57:08 <khem> s/patches/patched
Mar 26 17:58:41 <RP> khem: that is a noble aim but my bigger worry is intermittently failing builds. Introducing bugs like that close to release :/
Mar 26 18:01:37 <Yatekii> hey folks, how do I access the devtool again? :/
Mar 26 18:03:42 <qschulz> Yatekii: if you have access to bitbake, you havea ccess to devtool
Mar 26 18:07:01 <khem> RP: perhaps lets drop bintutils one, and I will resend glibc one without configure fragment
Mar 26 18:07:46 <Yatekii> qschulz: I basically want to run this: "devtool build raichu-core" but I need to have the proper devshell somehow :/
Mar 26 18:10:48 <khem> RP: 0015-sysdeps-gnu-configure.ac-handle-correctly-libc_cv_ro.patch and 0017-yes-within-the-path-sets-wrong-config-variables.patch also patch configure in glibc should that be removed as well then ?
Mar 26 18:16:57 <qschulz> Yatekii: ? devtool modify raichu-core; devtool build raichu-core?
Mar 26 18:19:12 <RP> khem: yes
Mar 26 18:19:57 <khem> RP: so let me send a patch on top of current patchset instead of rebasing
Mar 26 18:19:58 <RP> khem: I think we avoid the issue since in many cases we delete configure but I do also know its bitten us before
Mar 26 18:20:34 <RP> khem: also, patching generated files will mean "bitbake glibc -c patch -f" will fail
Mar 26 18:20:36 <khem> If we do that for glibc then I would like to keep the patches as such since it makes life easy
Mar 26 18:20:45 <RP> khem: that is fine
Mar 26 18:23:59 <Yatekii> qschulz: yep found it thx
Mar 26 18:31:30 <yocti> New news from stackoverflow: Nodejs node binary core dumped(Ilegal Insatruction) <https://stackoverflow.com/questions/60873690/nodejs-node-binary-core-dumpedilegal-insatruction>
Mar 26 19:09:07 <builderbob> I'm trying to build a very simple recipe that downloads a binary and adds it to the image. However when building I'm running into 500+ errors about `ERROR: k3s-1.17.0+k3s.1-r0 do_package: k3s: Multiple shlib providers for libgmp.so.10: k3s, k3s (used by files: /home/nhartman/build/tmp-glibc/work/core2-64-linux/k3s/1.17.0+k3s.1-r0/packages-split/k3s/recipe-sysroot-native/usr/libexec/x86_64-linux/gcc/x86_64-linux/9.2.0/cc1plus)`
Mar 26 19:12:48 <qschulz> builderbob: multiple packages provide the same lib. That is not allowed AFAIK
Mar 26 19:20:14 <Yatekii> hmm does any1 of you know how I best add openSSL to my yocto
Mar 26 19:26:44 <Yatekii> ah nice
Mar 26 21:48:33 <Yatekii> how can I figure what packages are available on yocoto? oO
Mar 26 21:53:37 <bluelightning> Yatekii: to have a package you must have a recipe - and all community recipes (and the layers that contain them) can be found via http://layers.openembedded.org/layerindex/recipes/
Mar 26 21:58:17 <Yatekii> yeah hmm
Mar 26 21:58:37 <Yatekii> problem is that I don't really know whether it installed openssl or not :/
Mar 26 22:02:25 <bluelightning> Yatekii: openssl is packaged into libcrypto and libssl IIRC
Mar 26 22:03:37 <bluelightning> Yatekii: the question is though why do you actually need to add openssl explicitly? it's a library - if you build your app that uses it from a recipe, the resulting package(s) will automatically pull in the openssl packages already when you add your app package(s) to the image
Mar 26 22:04:00 <bluelightning> assuming of course you're not looking for the openssl command line tool, that is
Mar 26 22:04:48 <Yatekii> my own receipe needs it
Mar 26 22:05:24 <bluelightning> right, then you should only need to add openssl to DEPENDS in the recipe
Mar 26 22:05:30 <bluelightning> brb
Mar 26 22:07:54 <Yatekii> k
Mar 26 22:08:24 <Yatekii> quality I'd say: https://gist.github.com/Yatekii/1c226d95e25d19c5da66b5e545ef4456 "can't edit the recipe because the recipe cannot be loaded" "NO SHIT SHERLOCK I WANNA FIX IT"
Mar 26 22:09:12 <Yatekii> bluelightning: the problem is that my rust crate wants libssl and cannot find it.
Mar 26 22:09:38 <Yatekii> https://gist.github.com/Yatekii/80f2d37194ff2488c5759a7513272ca3 is what I get
Mar 26 22:12:05 <bluelightning> hmm, I don't know much about rust unfortunately (no doubt others do), but it's almost certainly not looking in the right place i.e. the sysroot
Mar 26 22:12:51 <bluelightning> yeah apologies about the annoying error from devtool edit-recipe in that scenario, it should probably be a bit smarter
Mar 26 22:14:24 <Yatekii> bluelightning: well it should not fail to open the receipe.
Mar 26 22:14:49 <Yatekii> I mean the error is ok. it also prints the path of the receipe so I can fix it which is better than for many other errors
Mar 26 22:15:11 <bluelightning> I agree... the reason it tries to is in the general case it can't find out which recipe provides the name you ask of it until it has parsed the recipe
Mar 26 22:15:47 <bluelightning> (sometimes PN i.e. the name is not directly derived from the file name, although that is usually the case)
Mar 26 22:16:00 <bluelightning> details of course
Mar 26 22:16:08 <Yatekii> well I mean I am still learning but it's a classical linux toolchain and I don't like that much. and I prefer linux over all other OSes ^^
Mar 26 22:16:31 <Yatekii> bluelightning: https://github.com/rust-embedded/meta-rust-bin/blob/master/classes/cargo.bbclass according to that it should know the proper pkgconfi locations
Mar 26 22:16:54 <bluelightning> right, even outside of rust we do set PKG_CONFIG_PATH to point into the appropriate dir in the sysroot
Mar 26 22:16:58 <Yatekii> so idk what's wrong. is there a way to maybe print environment variables during build of the receipes? maybe I can echo them
Mar 26 22:17:30 <Yatekii> the weird part is that it can find all the other rust binaries through the other set variables so I am really confused :/
Mar 26 22:17:35 <bluelightning> you can examine the run file for the task (under temp under the workdir for the recipe)
Mar 26 22:17:52 <bluelightning> workdir can be found with bitbake -e recipename | grep ^WORKDIR=
Mar 26 22:18:10 <bluelightning> run file is run.do_taskname under temp/
Mar 26 22:18:30 <Yatekii> ah yeah I had a look there already once upon a time, lemme check
Mar 26 22:19:23 <bluelightning> you can of course modify/prepend the task function contents and echo stuff as well, depends on the situation and how you want to do things
Mar 26 22:19:58 <bluelightning> (you'd do that from the recipe)
Mar 26 22:20:03 <Yatekii> hmm this is all very weird & non-intuitive to me ^^
Mar 26 22:20:26 <bluelightning> it seems odd at first but there's a reason for about 90% of it
Mar 26 22:21:12 <bluelightning> I'm happy to explain things if I can
Mar 26 22:21:12 <Yatekii> yeah but for example pulling in my own receipe via git is still a mystery to me ...
Mar 26 22:21:25 <Yatekii> I made it work somehow but it is 100% wrong
Mar 26 22:21:33 <bluelightning> do you mean pulling the recipe itself or the source for what you're building ?
Mar 26 22:21:57 <Yatekii> and the megaguide is not helpful at all. qschulz kindly pointed me to all the right places but it's just odd to me ...
Mar 26 22:22:01 <Yatekii> pulling the source itself
Mar 26 22:22:09 <Yatekii> somehow it is not meant to ever use bleeding master
Mar 26 22:22:19 <Yatekii> at least not in obvious ways
Mar 26 22:22:38 <bluelightning> once you know how it's fairly easy to do that, but the way to is not intuitive I'd have to agree
Mar 26 22:23:01 <bluelightning> also depends on whether you want to work on the source locally at the same time or just pull and build from the repo only
Mar 26 22:23:25 <Yatekii> yeah, atm I use the devtool to open a shell into the receipe then I alter the source from there
Mar 26 22:23:42 <Yatekii> I don't like that but heh, that's how it is ;)
Mar 26 22:23:50 <bluelightning> yep, that's the right way for that scenario
Mar 26 22:23:51 <Yatekii> I mean for deployment I want a fixed version
Mar 26 22:23:58 <Yatekii> but for iterating I need bleading master ofc
Mar 26 22:24:04 <Yatekii> *bleeding
Mar 26 22:24:40 <bluelightning> well when you're ready to put things back you do devtool finish... I can't recall if it automatically fixes the SRCREV or if you ahve to do it, but that part is straightforward
Mar 26 22:24:43 <Yatekii> uhm so I am browsing the logs atm, but I don'0t seem to get any wiser ... anything specifiy I am looking for?
Mar 26 22:25:06 <bluelightning> well the runfile should show the exported value of PKG_CONFIG_PATH
Mar 26 22:26:49 <Yatekii> yap, just found it
Mar 26 22:26:54 <Yatekii> seems to be correct from the looks
Mar 26 22:26:59 <Yatekii> need to check the contents at that path
Mar 26 22:27:14 <Yatekii> also need to figure how pkg_config works :D
Mar 26 22:27:16 <Yatekii> no clue at all
Mar 26 22:27:47 <bluelightning> basically just looks at that file and prints out stuff that the calling program requests from it
Mar 26 22:27:53 <bluelightning> not a lot to it really
Mar 26 22:28:15 <bluelightning> well.. *that file* being the .pc file that has been installed alongside each library in that path
Mar 26 22:29:07 <Yatekii> yap
Mar 26 22:29:26 <Yatekii> okkk, so here we go: the two dirs in the path do not contain anything
Mar 26 22:29:41 <Yatekii> export PKG_CONFIG_PATH="/home/yatekii/repos/raichu/build-openstlinuxtkrt-stm32mp1-raichu-cubemx/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_tkrt-linux-gnueabi/raichu-core/999-r0/recipe-sysroot/usr/lib/pkgconfig:/home/yatekii/repos/raichu/build-openstlinuxtkrt-stm32mp1-raichu-cubemx/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_tkrt-linux-gnueabi/raichu-core/999-r0/recipe-sysroot/usr/share/pkgconfig"
Mar 26 22:29:45 <Yatekii> is what's in
Mar 26 22:29:52 <Yatekii> and both pkgconfig dirs are nonexistant
Mar 26 22:30:01 <Yatekii> \o/
Mar 26 22:30:37 <Yatekii> ok so you say I add a DEPENDS += openssl?
Mar 26 22:30:59 <bluelightning> DEPENDS += "openssl" yes
Mar 26 22:31:07 <Yatekii> lemme try
Mar 26 22:31:23 <bluelightning> in the recipe
Mar 26 22:31:28 <Yatekii> yes :)
Mar 26 22:31:50 <Yatekii> ok it smells better now
Mar 26 22:31:54 <Yatekii> already 15s in :D
Mar 26 22:31:59 <Yatekii> before it would explode at 5
Mar 26 22:32:03 <Yatekii> I guess yo da G :D
Mar 26 22:32:07 <Yatekii> *you
Mar 26 22:32:16 <bluelightning> :D
Mar 26 22:32:27 <Yatekii> yeah, I tried to add it to the binary packages
Mar 26 22:32:33 <Yatekii> which ofc wont reach it through properly
Mar 26 22:32:35 <Yatekii> silly
Mar 26 22:32:40 <bluelightning> binary packages?
Mar 26 22:32:48 <Yatekii> ah, sec
Mar 26 22:33:45 <Yatekii> I did this: IMAGE_INSTALL_append = " openplcutils openssh-sftp-server openssl raichu-core"
Mar 26 22:33:57 <bluelightning> right, yeah, that would be too late
Mar 26 22:34:08 <Yatekii> problem is:
Mar 26 22:34:11 <bluelightning> if it only needed it at runtime that would have worked, although even that's not ideal
Mar 26 22:34:58 <Yatekii> I am using an ST "framework" for their stm32mp1. and that is a huge mess like all ST stuff that's not silicon itself. and thus I never know if sth is really the yocto way or more like the st way or completely wrong (like the ST way :))
Mar 26 22:35:12 <Yatekii> bluelightning: yeah I see my mistake now, thanks!
Mar 26 22:35:39 <bluelightning> yeah it is sometimes an issue with vendor-provided things, can't say I have any experience with ST stuff myself
Mar 26 22:35:53 <Yatekii> well I use ST for many years.
Mar 26 22:35:53 <bluelightning> np
Mar 26 22:35:57 <Yatekii> ^^
Mar 26 22:36:28 <Yatekii> ok, noob's gonna noob: https://gist.github.com/Yatekii/287bb75a3d0793c4b7fec3e2197db72d
Mar 26 22:36:30 <Yatekii> :/
Mar 26 22:36:49 <Yatekii> something is really off :/
Mar 26 22:36:56 <bluelightning> yuck
Mar 26 22:37:11 <Yatekii> I haven't seen such a bad error in a while :D
Mar 26 22:37:22 <Yatekii> ahhhh
Mar 26 22:37:26 <Yatekii> I have an idea:
Mar 26 22:37:33 <Yatekii> I altered a receipe whilst it was building
Mar 26 22:37:38 <bluelightning> usually when you get "taskhash mismatch" it's because something changed between the first time it parsed a file and the next time
Mar 26 22:37:42 <Yatekii> does it maybe compare hashes from the start and the end?
Mar 26 22:37:43 <bluelightning> ah right, that will do it
Mar 26 22:37:46 <bluelightning> don't do that :)
Mar 26 22:37:53 <bluelightning> it'll be fine on the next run
Mar 26 22:38:01 <Yatekii> ok so Imma go on and blame the tool =D
Mar 26 22:38:05 <Yatekii> thx!
Mar 26 22:38:12 <bluelightning> I wonder if we document that somewhere, possibly not
Mar 26 22:38:38 <bluelightning> I probably should at least add taskhash mismatch to the FAQ if it's not there
Mar 26 22:39:44 <Yatekii> yeah, but the thing with docs is: you have thousands of docpages. nobody is gonna find anything like ever. it is great if you are pointed to it but that's about it. at least that's my opinion about extensive docs. that's why I prefer examples and guides =)
Mar 26 22:39:56 <Yatekii> but adding it to the FAQ might be a good thing, yep!
Mar 26 22:40:03 <Yatekii> whooo it built \o/
Mar 26 22:40:06 <Yatekii> thanks so much!
Mar 26 22:40:37 <Yatekii> ok, so can I maybe show you my receipe? :/
Mar 26 22:40:43 <bluelightning> sure
Mar 26 22:41:07 <Yatekii> I tried this a while ago with some other folks in here and I must say this channel is really kinda and helful, but I didn't get how it's done
Mar 26 22:41:26 <Yatekii> https://gist.github.com/Yatekii/1a79edabf08fcbafea80661618ec588d so this is it.
Mar 26 22:41:37 <Yatekii> file is called: raichu-core_git.bb
Mar 26 22:42:37 <Yatekii> optimally I would always pull a certain release tag, say v1.0.0 but when I dev I wanna do this bleeding
Mar 26 22:42:54 <Yatekii> so would I add tag=xyz and then just use the devtool to edit my sources?
Mar 26 22:43:15 <Yatekii> are those two lines:
Mar 26 22:43:16 <Yatekii> SRCREV = "${AUTOREV}"
Mar 26 22:43:17 <Yatekii> PV = "${SRCPV}"
Mar 26 22:43:45 <Yatekii> even needed? the mega gude told me something about setting the PV variable so I did, but I don't have the slightest clue if this is right
Mar 26 22:43:52 <bluelightning> so with devtool while you're developing you can just pull, checkout branches, do whatever in the local source tree and build from there
Mar 26 22:44:23 <bluelightning> it's only when you want others to build it that you need to worry about SRC_URI / SRCREV / etc. in the recipe
Mar 26 22:44:31 <Yatekii> yep
Mar 26 22:44:37 <Yatekii> (and for CI ofc)
Mar 26 22:44:43 <bluelightning> right, yes
Mar 26 22:44:58 <bluelightning> so the recipe itself looks fine
Mar 26 22:45:27 <bluelightning> and yes you can put tag= but typically you'd set SRCREV to the actual hash and then bitbake won't try to query the repo every time it's run
Mar 26 22:45:42 <Yatekii> last time they told me to put my version in the receipe name and use some variable in the receipe. but I wasn't sure what's right
Mar 26 22:46:13 <bluelightning> well, that is a convention if you are building a fixed version
Mar 26 22:46:49 <bluelightning> but when building from a git repo typically the recipe is just something_git.bb and then if there is a version you set it by PV = "x.y+git${SRCPV}"
Mar 26 22:46:59 <bluelightning> so you get the version and the hash in the resulting final package version
Mar 26 22:47:20 <bluelightning> that can be useful if you have to increment a few commits beyond the tagged version in the repo
Mar 26 22:48:26 <Yatekii> ok, I sse
Mar 26 22:48:41 <Yatekii> what I do not understand at all is how SRCREV and PC play together at all
Mar 26 22:48:50 <Yatekii> and thet magic SRCPV :DF
Mar 26 22:49:29 <Yatekii> I read about those in the mega manual, again, but not sure I understood correctly. I think there is also P and V variables with the package name and the version respectively
Mar 26 22:50:12 <bluelightning> SRCREV for a recipe being fetched from git is the actual revision that will be fetched... for best practice it should either be a full hash of a commit or "${AUTOREV}"
Mar 26 22:51:49 <Yatekii> that makes sense.
Mar 26 22:51:59 <bluelightning> SRCPV is a bit magic - it performs two functions (1) get the hash into the version and (2) act as a way to ensure that we fetch the latest version when "${AUTOREV}" is being used, i.e. it will happen the first time PV is expanded which is pretty early on
Mar 26 22:53:13 <bluelightning> there is an additional feature of the value itself  - it starts out as AUTOINC and then that gets replaced when the final package is built with a proper number
Mar 26 22:54:08 <bluelightning> the idea being to ensure that the version number always increments when the hash changes rather than jumping around depending on the actual value of the hash
Mar 26 22:54:30 <Yatekii> ok, but if I add a fixed version it will dump the hash or the other way around? I mean it can't please both in most cases I guess and only either one is needed
Mar 26 22:55:19 <Yatekii> ok so basically SRCPV just increments whenever the hash or the version change?
Mar 26 22:56:07 <bluelightning> well, the first part of SRCPV (the number part represented by AUTOINC), and just based on the hash, but yes
Mar 26 22:56:22 <bluelightning> if you move to a fixed version you would set PV = "theversionnumber+git${SRCPV}" and SRCREV = "thehashofthecommit"
Mar 26 22:58:05 <Yatekii> hmm I guess I am too dumb for this lol
Mar 26 22:58:19 <bluelightning> you can always experiment :)
Mar 26 22:58:46 <bluelightning> so let's say you have a tag v1.2.3 and that's the version you want to build
Mar 26 22:59:55 <bluelightning> and that tag points to commit with the hash c2b67f880f047904dd7b0ef9f1ae3d9077a09585
Mar 26 23:00:19 <bluelightning> to set up the recipe to use that (not using devtool) you would use PV = "v1.2.3+git${SRCPV}" and SRCREV = "c2b67f880f047904dd7b0ef9f1ae3d9077a09585"
Mar 26 23:01:30 <bluelightning> make sense?
Mar 26 23:01:45 <bluelightning> I'm going to grab lunch, back later
Mar 26 23:01:45 <Yatekii> ok, yes sofar so good, but why do I have to put the tag AND the rev? and why does it need that autoincrement now? I mean it's a fixed version now, so why not just PV = "v1.2.3(+git maybe)"
Mar 26 23:01:58 <Yatekii> bon appetit!
Mar 26 23:02:25 <Yatekii> no idea how this is spellt in english lol, so french has to do (I am not a french native but in swissgerman we can say this :D)
Mar 26 23:02:39 <bluelightning> it doesn't actually *need* ${SRCPV} in this case, it's just useful if at some point you need to change the hash but that's still the most recent version number applicable
Mar 26 23:03:07 <bluelightning> actually in english we may also say bon appetit :)
Mar 26 23:03:33 <bluelightning> english loves to steal things from other languages and then destroy the pronunciation (and sometimes spelling) :)
Mar 26 23:03:57 <bluelightning> particularly french
Mar 26 23:07:59 <Yatekii> ah, I see
Mar 26 23:08:12 <Yatekii> hahaha yeah xD
Mar 26 23:08:25 <Yatekii> and french love to invent stupid words just for the sake of being french native
Mar 26 23:08:45 <Yatekii> ok so now it cannot find libssl so during runtime ... weeeell :D
Mar 26 23:09:00 <Yatekii> that makes sense because I did not flash the image :/
Mar 26 23:09:06 <Yatekii> can I just install that lib somehow?
Mar 26 23:09:52 <bluelightning> your app package *should* now have a runtime dependency on the libssl package, if it doesn't that's a bit odd
Mar 26 23:10:30 <bluelightning> rebuild the image and you can check the manifest file to see if it got added alongside
Mar 26 23:13:53 <Yatekii> bluelightning: well how do I deploy my package? I mean I use "devtool deploy-target raichu-core root@$1"
Mar 26 23:14:03 <Yatekii> I am not sure if that really deploys all deps
Mar 26 23:14:20 <Yatekii> hmm kk imma see if I can find the manifest :D
Mar 26 23:25:04 <Yatekii> openssl cortexa7t2hf-neon-vfpv4 1.1.1b-r0.0$
Mar 26 23:25:11 <Yatekii> I am sure it's just not deploayed :/
Mar 26 23:25:48 <khem> RP: actually the suppliment patch to drop configure patches in glibc is wrong, we do not autoreconf glibc so lets drop that
Mar 26 23:26:17 <khem> we forcibly touch configure files
Mar 26 23:26:26 <khem> so they dont regenerate
Mar 26 23:40:22 <RP> khem: I'm a bit puzzled how the current build is running then? :/
Mar 26 23:40:46 <RP> khem: just out of date configure I guess?
Mar 26 23:42:13 <RP> khem: I'll abort that build
Mar 27 00:03:44 <khem> RP: if you look into glibc then you will see we override do_configure
Mar 27 01:00:13 <khem> infact the original binutils patch should also be applied since it makes things better for binutils
Mar 27 02:02:58 <yocti> New news from stackoverflow: How to remove packagegroup-core-full-cmdline-sys-services from build <https://stackoverflow.com/questions/60878753/how-to-remove-packagegroup-core-full-cmdline-sys-services-from-build>
**** ENDING LOGGING AT Fri Mar 27 02:59:57 2020