Wednesday, 2020-03-18

*** camus1 <camus1!~Instantbi@> has joined #yocto00:26
*** kaspter <kaspter!~Instantbi@> has quit IRC00:27
*** camus1 is now known as kaspter00:27
*** kaspter <kaspter!~Instantbi@> has quit IRC00:47
*** kaspter <kaspter!~Instantbi@> has joined #yocto00:47
*** vineela1 <vineela1!vtummala@nat/intel/x-gphgbigqmcjisavo> has joined #yocto00:49
*** vineela <vineela!vtummala@nat/intel/x-nvvzmnfcrsffkfsm> has quit IRC00:49
*** vineela1 <vineela1!vtummala@nat/intel/x-gphgbigqmcjisavo> has quit IRC01:00
*** vineela <vineela!~vtummala@> has joined #yocto01:00
*** vineela1 <vineela1!vtummala@nat/intel/x-mtteqnykizpcbdda> has joined #yocto01:02
*** vineela <vineela!~vtummala@> has quit IRC01:02
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:10
*** JaMa <JaMa!~martin@> has joined #yocto01:10
*** dev1990 <dev1990!> has joined #yocto01:10
*** vineela <vineela!~vtummala@> has joined #yocto01:15
*** vineela1 <vineela1!vtummala@nat/intel/x-mtteqnykizpcbdda> has quit IRC01:15
*** vineela <vineela!~vtummala@> has quit IRC01:18
*** maudat <maudat!> has quit IRC01:29
*** goliath <goliath!> has quit IRC01:38
*** fatalhalt <fatalhalt!> has quit IRC01:39
*** Bunio_FH <Bunio_FH!> has quit IRC01:41
*** robert_yang <robert_yang!~robert@> has quit IRC01:55
*** robert_yang <robert_yang!~robert@> has joined #yocto01:55
*** fatalhalt <fatalhalt!> has joined #yocto01:56
*** csanchezdll <csanchezdll!> has quit IRC02:03
*** dev1990 <dev1990!> has quit IRC02:12
*** ericch <ericch!> has quit IRC02:51
*** nerdboy <nerdboy!~sarnold@> has joined #yocto03:21
yoctiNew news from stackoverflow: Why .ipkg format is mainly considered for the embedded devices...? [closed] <>03:21
*** nerdboy <nerdboy!~sarnold@> has quit IRC03:22
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto03:22
*** zopsi_ <zopsi_!zopsi@2600:3c00::f03c:91ff:fe14:551f> has quit IRC03:23
*** zopsi <zopsi!zopsi@2600:3c00::f03c:91ff:fe14:551f> has joined #yocto03:24
*** vineela <vineela!~vtummala@> has joined #yocto04:04
*** vineela <vineela!~vtummala@> has quit IRC04:12
*** dv <dv!~dv@> has quit IRC04:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC04:53
*** robert_yang <robert_yang!~robert@> has quit IRC05:06
*** kiwi_29 <kiwi_29!> has joined #yocto05:06
*** robert_yang <robert_yang!~robert@> has joined #yocto05:06
kiwi_29Hello...I am creating Debian Package .deb files as output of an application. I have preinst postinst maintainer scripts as part of deb package. I currently have this included as pkg_preinst_${PN} and related functions05:13
kiwi_29the actual script is written inside these functions05:13
kiwi_29is there a way to include external scripts as part of this functions ?05:13
kiwi_29I used include <PATH_TO_SCRIPT>/ as first line of pkg_preinst_${PN} but it did not work05:14
*** kiwi_29 <kiwi_29!> has quit IRC05:34
*** tgamblin_ <tgamblin_!> has quit IRC05:48
*** tgamblin_ <tgamblin_!> has joined #yocto05:50
*** lexano <lexano!> has quit IRC05:52
*** lexano <lexano!> has joined #yocto05:56
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:23
*** aehs29 <aehs29!~znc@> has quit IRC06:23
*** AndersD <AndersD!> has joined #yocto06:27
*** AndersD_ <AndersD_!~AndersD@> has joined #yocto06:29
*** AndersD_ <AndersD_!~AndersD@> has quit IRC06:31
*** AndersD <AndersD!> has quit IRC06:32
*** robert_yang <robert_yang!~robert@> has quit IRC06:45
*** robert_yang <robert_yang!~robert@> has joined #yocto06:46
*** lucaceresoli <lucaceresoli!> has joined #yocto06:47
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:238d:84be:b349:9184> has quit IRC06:49
*** pharaon2502 <pharaon2502!> has joined #yocto06:55
*** kiwi_29 <kiwi_29!> has joined #yocto06:58
kiwi_29hello... I m getting "mkdir: cannot create directory ‘/var/DIRNAME : Permission denied'06:59
kiwi_29"dpkg : error processing archive  DEBIANPACKAGENAME.deb (--unpack):06:59
kiwi_29"new DEBIANPACKAGENAME package pre-installation script subprocess returned error exit status 1"07:00
kiwi_29I have a mkdir inside the pkg_preinst_${PN}. and that is throwing this error when do_rootfs runs07:01
kiwi_29how do I successfully create this directory inside /var as part of my preinst procedure07:01
*** sstiller <sstiller!> has joined #yocto07:01
*** kanavin_home <kanavin_home!> has joined #yocto07:02
*** pohly <pohly!> has joined #yocto07:03
*** lucaceresoli <lucaceresoli!> has quit IRC07:14
*** jeanba1 <jeanba1!> has left #yocto07:14
*** pharaon2502 <pharaon2502!> has quit IRC07:19
*** pharaon2502 <pharaon2502!> has joined #yocto07:20
*** hpsy <hpsy!~hpsy@> has quit IRC07:29
*** kiwi_29 <kiwi_29!> has quit IRC07:31
erbokiwi_29: You are getting that during image build, right? You're post install script need to handle the case where it's run during rootfs creation. I think most script do that by checking if env variable D is set.07:32
*** guerinoni <guerinoni!> has joined #yocto07:32
*** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:9c5e:6e43:1680:da06> has joined #yocto07:35
*** Bunio_FH <Bunio_FH!> has joined #yocto07:36
erboWell wasn't that reply from me well timed07:36
erboWell, kiwi_29, if you're looking at logs later you might want to have a look at:
*** frsc <frsc!> has joined #yocto07:38
*** [Sno] <[Sno]!> has quit IRC07:44
*** [Sno] <[Sno]!> has joined #yocto07:46
*** lucaceresoli <lucaceresoli!> has joined #yocto08:03
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto08:13
*** fl0v0 <fl0v0!~fvo@> has quit IRC08:24
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:91f6:264e:d600:92> has joined #yocto08:24
*** fl0v0 <fl0v0!~fvo@> has joined #yocto08:24
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:36
*** mckoan|away is now known as mckoan08:36
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:91f6:264e:d600:92> has quit IRC08:41
*** fl0v0 <fl0v0!~fvo@> has quit IRC08:42
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:91f6:264e:d600:92> has joined #yocto08:42
*** yacar2_ <yacar2_!> has joined #yocto08:42
*** fl0v0 <fl0v0!~fvo@> has joined #yocto08:42
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:91f6:264e:d600:92> has quit IRC08:43
*** rburton <rburton!rburton@nat/intel/x-zdrwznnsmvxvufns> has joined #yocto08:43
*** fl0v0 <fl0v0!~fvo@> has quit IRC08:43
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:91f6:264e:d600:92> has joined #yocto08:43
*** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:9c5e:6e43:1680:da06> has quit IRC08:44
*** fl0v0 <fl0v0!~fvo@> has joined #yocto08:44
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:91f6:264e:d600:92> has quit IRC08:44
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:64cf:561c:89fb:9dce> has joined #yocto08:45
*** fl0v0 <fl0v0!~fvo@> has quit IRC08:46
*** fl0v0 <fl0v0!~fvo@> has joined #yocto08:46
*** Erlkoenig <Erlkoenig!> has joined #yocto08:50
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:51
*** hpsy <hpsy!~hpsy@> has joined #yocto08:52
ErlkoenigHi, when using devtool to build & deploy a custom application, can I specify a build mode via command line? Something like `devtool --mode=debug build myapp`  such that i can use some kind of ${mode} variable inside my recipe, e.g. via EXTRA_OECMAKE += "BUILD_MODE=${mode}"?08:52
LetoThe2ndErlkoenig: nope, it doesn't work like that.08:53
LetoThe2ndErlkoenig: closest match probably is to do devtool edit-recipe and tinker it there.08:54
yannmilloni: probably.  incidently, gcc-dbg does not contain the source either08:55
ErlkoenigMh, okay...08:55
milloniyann: i wouldn't expect it to, unless i'm missing something -dbg packages in general are not meant to contain source, -dev packages are08:55
LetoThe2ndErlkoenig: once *could* maybe extend devtool with some form of "environment passing" mechanism, but 1) thats pretty much contradicting the mindset and 2) still someone would have to do it and send patches :)08:56
yannno, -dev package are supposed to ship headers and libs.  -dbg packages OTOH ship debug symbols and source code to make sense out of them08:56
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC08:57
rburtoni wonder if gcc is somewhat special, because source is packaged08:57
ErlkoenigHm. I could make a "myapp-buildmode.bbappend" that just contains MYAPP_BUILD_MODE="debug" and autogenerate that on demand...08:58
*** TobSnyder <TobSnyder!> has joined #yocto08:58
rburtonyann: recent yocto?  try gcc-src08:58
LetoThe2ndrburton: re yesterdays evening topic: technically i agree on the "full bitbake" mindset, but the thing is that the esdk is already there and ready to be used.08:58
rburtonLetoThe2nd: and not finished08:59
qschulzErlkoenig: what exactly are you trying to solve as an issue?08:59
yannrburton: not so recent yet, sumo in this case :(08:59
LetoThe2ndErlkoenig: if you are using devtool, there is an append already under the hood anyways.08:59
Erlkoenigyes indeed08:59
LetoThe2ndrburton: what do you mean exactly?08:59
ErlkoenigI would like to be able to easily test debug and release versions for my application08:59
ErlkoenigAnd add the respective build commands to my IDE09:00
rburtonLetoThe2nd: esdk is a great idea but its complex and was never quite "done"09:00
LetoThe2ndrburton: its close enough for what i envision as a start, hence the idea.09:00
qschulzErlkoenig: make two recipes, one inherit the other and just adding your debug flag? then build one or the other?\09:01
rburtonLetoThe2nd: why not just ship bitbake and a sstate cache fragment directly09:01
ErlkoenigHmm, good idea!09:01
qschulzErlkoenig: does not work well with devtool though because to it it's two different recipes so you would have to do your changes twice. But for when you are stopping to use devtool, should be okayish09:02
LetoThe2ndrburton: hum but how would one package up the sstate?09:02
qschulzErlkoenig: also, you could use PACKAGECONFIG for that, pass a flag to make with ETXRA_OECONF or EXTRA_OEMAKE with it. Then from your local.conf you can put PACKAGECONFIG_pn-myrecipe_append = " debug" ?09:02
rburtonLetoThe2nd: using the same method the esdk does ;)09:03
LetoThe2ndrburton: hmmm good point.09:03
rburtonLetoThe2nd: is your goal just 'this container works out of the box'09:03
LetoThe2ndwill have to think about it.09:03
ErlkoenigI'd rather not modify the local.conf programmatically :) The idea was to have the usual "Build release" and "Build debug" buttons in the IDE to work as usual09:03
LetoThe2ndrburton: the goal is: "this appliance can build for $TARGETIMAGE out of the box."09:04
yannrburton: I don't see a gcc-src even in poky's master09:04
yannwell, I can surely tune the host gdb configuration to find the source in work-shared, anyway09:06
*** NiksDev <NiksDev!~NiksDev@> has quit IRC09:10
rburtonyann: what are you actually trying to do?09:11
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto09:11
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:6c96:6654:2736:2529> has quit IRC09:12
yanntrying to indentify the root cause of a abort that appears to happen during thread creation.  Most of the stack is within libstdc++, hence the need for the source files :)09:13
yannI'll trick gdb with a symlink into work-shared, that ought to be sufficient for me09:13
rburtongdb on target or remote gdb?09:13
rburtoni mean, using gdbserver? covers generating a debug filesystem for all the symbols.09:15
rburtonbut if you don't have -src packages then -dbg should have them09:15
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto09:16
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto09:16
rburtonunless your distro/bsp is turning them off :)09:16
yannyes using gdbserver, with a partial roofs extracted from the relevant *-dbg.ipk09:16
yannso my gdb has all the syms and source it needs... except for the libstdc++ ones that don't appear to end up in such a package09:17
Erlkoenigthread creation via std::thread doesn't work? does pthread_create work?09:19
*** dev1990 <dev1990!> has joined #yocto09:19
*** csanchezdll <csanchezdll!> has joined #yocto09:20
rburtonyann: on my list of things to do is look at debuginfod so this just magically works09:21
LetoThe2ndErlkoenig: why shouldn't it work?09:21
ErlkoenigTrying to help yann :) ... maybe something with passing bound parameters09:22
yannyeah that particular item is particularly sexy :)09:22
*** kpo__ <kpo__!> has joined #yocto09:32
*** jkimblad <jkimblad!> has quit IRC09:35
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:36
rburtonyann: you want the gcc-runtime recipe, not gcc09:52
yoctiNew news from stackoverflow: Old version of library is included in image after updating bitbake file <>09:53
rburtonyann: but yeah that doesn't built a src package09:54
*** robert_yang <robert_yang!~robert@> has quit IRC09:54
*** robert_yang <robert_yang!~robert@> has joined #yocto09:54
*** junland_ <junland_!~junland@> has joined #yocto09:59
*** elfGamal <elfGamal!~elg@> has joined #yocto10:00
*** risca_ <risca_!~quassel@> has joined #yocto10:00
*** amaury_d_ <amaury_d_!> has joined #yocto10:02
rburtonyann: file a bug :)10:02
*** robert_yang <robert_yang!~robert@> has quit IRC10:03
*** robert_yang <robert_yang!~robert@> has joined #yocto10:04
*** risca <risca!~quassel@> has quit IRC10:04
*** csd <csd!> has quit IRC10:04
*** amaury_d <amaury_d!> has quit IRC10:04
*** junland <junland!~junland@> has quit IRC10:04
*** elGamal <elGamal!~elg@> has quit IRC10:04
*** gtristan_ <gtristan_!~tristanva@> has quit IRC10:04
*** gtristan_ <gtristan_!~tristanva@> has joined #yocto10:06
*** csd <csd!> has joined #yocto10:06
*** bradfa <bradfa!uid297668@gateway/web/> has joined #yocto10:07
*** robert_yang <robert_yang!~robert@> has quit IRC10:13
*** robert_yang <robert_yang!~robert@> has joined #yocto10:13
*** locutus_ <locutus_!> has joined #yocto10:15
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC10:15
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC10:15
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto10:16
*** eduardas <eduardas!~eduardas@> has joined #yocto10:19
*** camus1 <camus1!~Instantbi@> has joined #yocto10:20
*** kaspter <kaspter!~Instantbi@> has quit IRC10:20
*** camus1 is now known as kaspter10:20
yoctiNew news from stackoverflow: (EE) open /dev/dri/card0: No such file or directory in Yocto <>10:23
*** kaspter <kaspter!~Instantbi@> has quit IRC10:29
*** jkimblad <jkimblad!> has joined #yocto10:29
eduardashello, I am currently exploring different bootloader + update agent combinations for a Phytec i.MX6UL SoM.... can anyone share opinions on whether their barebox+RAUC offering (implemented in a Yocto BSP) is better than u-boot + SWUpdate (that some other SoM vendors use)?10:30
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:30
eduardasI am considering making my own u-boot + SWUpdate BSP since it currently seems to me these components have wider adoption in the embeddded Linux community overall10:32
eduardasIf I am wrong about it, I would like to know before investing a considerable amount of time10:33
*** robert_yang <robert_yang!~robert@> has quit IRC10:33
*** robert_yang <robert_yang!~robert@> has joined #yocto10:34
LetoThe2ndeduardas: there is no one true answer10:40
*** jobroe <jobroe!~manjaro-u@> has quit IRC10:41
*** jobroe <jobroe!~manjaro-u@> has joined #yocto10:41
*** kaspter <kaspter!~Instantbi@> has quit IRC10:51
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:51
sstillereduardas, barebox has a nice shell with paths and files instead of simple environment variables. If you want to stay with phytec, you can use it. Phytec is the only vendor I know, that provides barebox as default.10:52
*** Bunio_FH <Bunio_FH!> has quit IRC10:54
pi1On Debian using docker with debian I installed a SDK. Installed to /home/user/sdk/ and zipped it. Now I would like to give this SDK to other developers, but I am getting an issue that the "./arm-poky-linux-gnueabi-gcc: No such file or directory". I used file command and its an ELF 64 bit executable, x86-64. When i open the file, I can clearly see that there is an "" link inside the10:57
pi1executable that has a wrong path. I expect there should be a better method to do all this already when building the SDK. Any reccomendations?10:57
pi1Other developers are using ubuntu and arch-linux.10:58
LetoThe2ndpi1: why do you "install and then re-zip" the sdk, first and foremost?10:59
*** Zajc <Zajc!> has quit IRC11:00
pi1LetoThe2nd: I found the rootfs and the toolchain there, so I assumed this would be the folder I was looking for. Do you have a better solution?11:01
qschulzpi1: how did you "install to /home/user/sdk"?11:01
LetoThe2ndpi1: bitbake $YOURIMAGE -c populate_sdk ?11:01
pi1I did bitbake $MYIMAGE -c populate_sdk and found in /tmp/deploy/sdk a script which I ran. Can I ship this script instead?11:02
LetoThe2ndpi1: thats exactly what its meant for, yes.11:03
pi1LetoThe2nd: any other reccomendations to ship the toolchain.11:03
LetoThe2ndpi1: that is the recommendation to ship the toolchain.11:03
pi1LetoThe2nd: do you mean to run the script in the sdk folder or to ship the sdk folder?11:04
LetoThe2ndpi1: you just ship the .sh that you find in /tmp/deply/sdk/...11:04
erboShip the script, it's basically an SDK installer meant for distribution11:04
*** Zajc <Zajc!> has joined #yocto11:05
pi1LetoThe2nd: No other files?11:05
erbopi1: it's self contained11:05
pi1impressive. I will try11:05
LetoThe2ndpi1: seriously, i don't get whats so complicated about it.11:05
LetoThe2ndpi1: plus, we have rather good documentation on it. and plusplus, it is also explained in live coding session #3 (IIRC)11:06
erboLetoThe2nd: When you see that it's a shell script, it's not that far off to assume it's a script copying files from the build dir or so.11:06
pi1LetoThe2nd: I missunderstood. I saw that the SDK was much bigger than this script, and I did not know it was self contained11:06
LetoThe2nderbo: i never had that idea, to be honest.11:07
erboI guess not everyone has seen the trick of embedding compressed data in a shell script.11:07
pi1Thanks guys11:07
*** Bunio_FH <Bunio_FH!> has joined #yocto11:09
*** guerinoni <guerinoni!> has quit IRC11:10
erboLetoThe2nd: But you are the master, not the apprentice :)11:10
LetoThe2nderbo: its not so long since i was a complete newb too.11:11
*** khem <khem!~khem@unaffiliated/khem> has quit IRC11:19
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto11:19
*** goliath <goliath!> has joined #yocto11:29
*** hpsy <hpsy!~hpsy@> has quit IRC11:34
*** Bunio_FH <Bunio_FH!> has quit IRC11:35
*** yacar2_ <yacar2_!> has quit IRC11:39
*** berton <berton!~berton@> has joined #yocto11:46
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has joined #yocto11:48
*** Bunio_FH <Bunio_FH!> has joined #yocto11:54
nemgti-ogAnybody knows how can I debug cmake issues when working on a recipe (using devtool) in an eSDK?12:06
nemgti-ogI added some message() calls to my CMakeLists.txt. If Itry to build not using devtool then I can see my messages, but when runnint devtool build <recipe-name> they are ignored making it difficult to debug and find out what the issue is12:08
*** fl0v0 <fl0v0!~fvo@> has quit IRC12:10
*** kpo__ <kpo__!> has quit IRC12:11
*** kpo__ <kpo__!> has joined #yocto12:11
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto12:14
qschulznemgti-og: have you tried with -d?12:18
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:e899:b041:3610:2bad> has joined #yocto12:23
*** berton <berton!~berton@> has quit IRC12:24
*** berton <berton!~berton@> has joined #yocto12:25
*** yacar2_ <yacar2_!~yacar_@2a01:e0a:22a:7f40:14e5:503b:777b:7a93> has joined #yocto12:32
nemgti-ogI have the suspicion that my messages are not delivered here. Can anybody reply this back to know if my suspicions are correct - or not?12:33
*** maudat <maudat!> has joined #yocto12:34
*** yacar2_ <yacar2_!~yacar_@2a01:e0a:22a:7f40:14e5:503b:777b:7a93> has quit IRC12:35
nemgti-ogqschulz: - I didnt see your message before. So, I have not try with -d. Should I try it in this way: "devtool -d build <recipe-name>"12:35
nemgti-ogAh ok... I am looking at the help menu. I got it qschulz Thanks12:36
qschulznemgti-og: aren't you just missing a DEPENDS at build time? Or could it be that your cmake does not take the --sysroot passed by Yocto?12:38
qschulznemgti-og: devtool uses bitbake under the hood12:38
qschulznemgti-og: look for missing DEPENDS in the recipe, or hardcoded or set with := CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS in your cmake12:39
nemgti-ogqschulz: I am guessing the second of your options12:40
nemgti-ogqschulz: I mean, if I run cmake by myself the command will be found. Only when tryingto build via devtool is the command not found. So I think no DEPENDS are missing -> I understand DEPENDS is used to mark other recipe's files as dependencies12:42
nemgti-ogqschulz: also... unfortunately the option -d won't give me addition useful info. :/ Thank you for the hint anyways12:44
qschulznemgti-og: DEPENDS is used to say which other recipe you depends on at build time. So if you need some binaries, header files or libraries from other SW, they have to be in DEPENDS. If you need some binaries for other things than linking, then most probably you want the -native variant of the recipe in DEPENDS12:45
nemgti-ogqschulz: Ok. But if my binnary (the command to execute by cmake) is not provided by any other recipe, but instead is already provided in my environment, should I declare it anyways in DEPENDS?12:48
nemgti-ogqschulz: it might be that I am instead missing a RDEPENDS? The doc says "List a package'sruntime dependencies (i.e. other packages) that must be installed in order for the built package to run correctly"12:49
*** guerinoni <guerinoni!> has joined #yocto12:52
nemgti-ogNo... reading further it seems to me that I am also not missing a RDEPENDS12:52
qschulznemgti-og: you don't want to have host contamination in Yocto, so if no recipe is providing this binary, you have to create this recipe (look up first on and on google, there might be one available already)12:56
qschulznemgti-og: but IIRC, host contamination is possible in Yocto and not detected, so even if you should fix that, there's a bigger problem in the picture. Is your binary not in $PATH for example? Just throwing ideas12:59
*** kroon <kroon!> has joined #yocto13:00
nemgti-ogqschulz: Thanks. Yes the binary is accessible via the $PATH. So... the recomended practice is to provide such binary via a recipe --> does this apply too when working with an eSDK? So my eSDK should have a recipe that provides the binary? Since the binary is already in my host (in /usr/bin) I thouth I could simply install the eSDK and "devtool buid" with it13:02
qschulznemgti-og: the thing is, you would require other devs/users of your recipe to install your binary in their host distribution. And then starts the nightmare of people having different versions of the same binary provided by differnet distros/versions of distros.13:08
nemgti-ogqschulz: Now I see it. You're right. Thanks again!13:09
*** nacknick <nacknick!> has joined #yocto13:16
nacknickHi. Since my settings were deleted for some reason, can someone remind me how to set `ARM_INSTRUCTION_SET` for specific recipe inside *local.conf*?13:17
nacknick`ARM_INSTRUCTION_SET-PN`? I can't remember13:17
*** yacar_ <yacar_!> has joined #yocto13:28
*** kpo__ <kpo__!> has quit IRC13:31
nacknickah thanks13:36
nacknickAnother question please: Is there any way to force build of a specific recipe? If I use `bitbake <pn>` it probably has logs of hashes and it does not rebuild the recipe if it does not see a reason (by the hash)13:38
*** ericch <ericch!> has joined #yocto13:39
*** kpo__ <kpo__!> has joined #yocto13:39
*** mauz555_ <mauz555_!~mauz555@> has joined #yocto13:43
nemgti-ognacknick: you could try bitbake -c cleansstate <recipe-name> This will remove the shared state of the recipe/package in question and therefore it will be rebuilt next time you run bitbake on it or any other recipe that depends on it13:44
*** junland_ <junland_!~junland@> has quit IRC13:44
*** mattsm <mattsm!> has quit IRC13:47
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:e899:b041:3610:2bad> has quit IRC13:47
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:3105:3e60:51ab:b6a3> has joined #yocto13:48
JPEWkhem: Are you around yet?13:48
*** junland <junland!~junland@> has joined #yocto13:49
*** mattsm <mattsm!> has joined #yocto13:49
*** mauz555_ <mauz555_!~mauz555@> has quit IRC13:51
*** hpsy <hpsy!~hpsy@> has joined #yocto13:54
*** maudat <maudat!> has quit IRC14:01
*** maudat <maudat!> has joined #yocto14:03
*** nacknick <nacknick!> has quit IRC14:04
*** ssajal <ssajal!> has joined #yocto14:04
*** WillMiles <WillMiles!~Will@> has joined #yocto14:21
*** mauz555 <mauz555!~mauz555@2a01:e0a:56d:9090:3105:3e60:51ab:b6a3> has quit IRC14:25
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC14:26
*** kanavin_home <kanavin_home!> has quit IRC14:27
*** kpo__ <kpo__!> has quit IRC14:28
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:238d:84be:b349:9184> has joined #yocto14:28
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has quit IRC14:34
*** nemgti-og <nemgti-og!~nemgti-og@> has joined #yocto14:36
*** jobroe <jobroe!~manjaro-u@> has quit IRC14:43
*** jobroe <jobroe!~manjaro-u@> has joined #yocto14:45
khemJPEW: now yes14:50
*** schu-r <schu-r!~Thunderbi@> has joined #yocto14:50
*** jobroe <jobroe!~manjaro-u@> has quit IRC14:52
*** nacknick <nacknick!> has joined #yocto14:55
*** joseppc <joseppc!> has joined #yocto14:55
*** joseppc <joseppc!~josep@unaffiliated/joseppc> has joined #yocto14:56
nacknickIs there a way to add a file during the building process to the `/lib` directory of the final image?14:56
*** jobroe <jobroe!~manjaro-u@> has joined #yocto14:56
qschulznacknick: create a recipe which installs that file in /lib and add the package created by this recipe to the final image?14:58
nacknickqschulz I'm not sure how to install file into the /lib directory. What is the command?15:01
qschulznacknick: install ${S}/myfile ${D}{base_libdir} in do_install task? if it has to be in /lib even when using multilib, nonarch_base_libdir instead of base_libdir15:06
nemikis anyone using Android Verified Boot (libAVB) in u-boot and the abvtool with Yocto-produced images? is it a bad idea?15:06
qschulznacknick: I feel like you would like to watch:
qschulznemik: maybe something to ask on #u-boot also to check how well supported this is (is it even upstreamed?)15:09
nacknickqschulz: Thanks. I already watched some of the videos15:09
qschulznacknick: BTW, the install command is not Yocto specific ;)15:10
nacknickI know. It's Linux's15:10
qschulznacknick: I didn't know it existed before I worked with Yocto, that's why I'm sharing15:12
nacknickHaha me too15:12
ErlkoenigHave you never installed something using a source tarball and "make install" and wondered what all the lines starting with "install" do ;-)15:12
JPEWkhem: I got an AUH failure for diffoscope because it doesn't build for musl
nemgti-ogdoes anybody know why when bitbaking nativsdk recipes, the packages are placed under <some-funny-prefix>${D}${datadir}? Where <some-funny-prefix> in my case looks like "/opt/opky-ivi-systemd/2.6.2". In my poky-ivi-systemd.conf I have set SDKEXTPATH to something different than <some-funny-prefix>15:18
JPEWkhem: Is there a way to make the AUH happy in this case?15:18
JPEWkhem: Perhaps RECIPE_NO_UPDATE_REASON_libc-musl = "Dependencies don't build for musl" ?15:18
rburtonnemgti-og: thats the nativesdk prefix, that gets relocated when you install the SDK15:39
nemgti-ogrburton: yes thanks! I have found the variables that hold this path. Thank you!15:39
rburtonnemgti-og: you don't need to change it, consider it a implementation detail15:39
nemgti-ogrburton: but if I change the installatin path of my eSDK, the recipes that DEPENDS/RDEPENDS on other recipes will try to find such dependencies based on that <some-funny-prefix> won't they?15:41
rburtonthey get relocated15:41
rburtonat SDK installation time you decide where it goes15:41
nemgti-ogaham.... yes15:42
rburtonkhem: do we need to autoconf binutils, or can we just run configure directly15:42
*** hpsy <hpsy!~hpsy@> has quit IRC15:42
*** lfa <lfa!> has joined #yocto15:46
*** lfa_ <lfa_!> has quit IRC15:48
*** schu-r <schu-r!~Thunderbi@> has quit IRC15:50
*** lfa_ <lfa_!> has joined #yocto15:59
*** kaspter <kaspter!~Instantbi@> has quit IRC15:59
*** kaspter <kaspter!~Instantbi@> has joined #yocto15:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:02
*** lfa <lfa!> has quit IRC16:03
*** lfa <lfa!> has joined #yocto16:03
*** lfa_ <lfa_!> has quit IRC16:04
*** Erlkoenig <Erlkoenig!> has quit IRC16:04
*** csanchezdll <csanchezdll!> has quit IRC16:05
*** TobSnyder <TobSnyder!> has quit IRC16:10
*** eduardas <eduardas!~eduardas@> has quit IRC16:14
*** sstiller <sstiller!> has quit IRC16:15
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:f9b4:c5e7:779d:24de> has joined #yocto16:19
*** csanchezdll <csanchezdll!> has joined #yocto16:23
*** bri92 <bri92!> has joined #yocto16:26
bri92If I have a project where recipe A depends on B depends on C.  Then I rebuild C (say via force compile/deploy).  How can I rebuild A to get it build based upon C?16:28
qschulzbri92: if I'm not mistaken, Yocto should already do it by itself16:30
bri92Hmmm... perhaps I have a broken dependency...   Need to look more.  Thanks.16:31
qschulzbri92: better define what's the issue :) what do you want to do, what have you done, what's the error you're havin16:31
bri92Problem is, the issue is as above.  I rebuild C and see the end products in tmp/deploy, and then try to rebuild A but it doesn't run any tasks.16:32
bri92Normally, though, if building from a clean slate, A, B, and C get built.16:33
bri92(and A includes the C end products)16:33
qschulzbri92: by "depends" you mean an actual DEPENDS right?16:34
*** nacknick <nacknick!> has quit IRC16:34
qschulzbri92: what version of yocto are you using?16:34
*** lfa <lfa!> has quit IRC16:34
qschulzbri92: what files from C do you need in A? specifically, where do you get them from?16:36
bri92C deploys an elf file into tmp/deploy.  A uses that file to generate a bigger binary.16:37
qschulzbri92: Yocto has no knowledge of that file in A recipe, so it does not know it needs to rebuild A16:37
qschulzbri92: specifically, it knows a file has changed for a recipe and that it needs rebuild if it's in SRC_URI (maybe some other mechanisms, but that one, for sure)16:38
bri92Oh.   hmmm...  Can you make it depend on the deploys?  I (I guess mistakenly) thought that it did16:39
qschulzin your case, I doubt very much it is passed in SRC_URI in A16:39
bri92It's not16:39
qschulzbri92: what is the name of the task in recipe A using the deployed file?16:39
*** vineela <vineela!vtummala@nat/intel/x-olvdibbksifcrvzg> has joined #yocto16:41
qschulzI think you should be able to do do_compile[depends] += "recipeB:do_deploy" in recipeA16:41
bri92Ahha...  that makes some sense (I've seen that convention around)...16:42
bri92Very cool.16:42
qschulzthis means that your do_compile of recipeA depends on do_deploy of recipeB (typo, should be recipeC from your example). so iff do_deploy gets run again for some reason, the do_compile of recipeA will have to be re-run as well since it's a dependency16:42
qschulzI *think*16:42
bri92I will try it.16:43
bri92I've been yocto-ing a good bit for the past few months, and wow does it have a steep learning curve...16:44
rburtonbri92: why are you deploying an elf to deploydir?  if you want to run a binary during the build, write a native recipe to install it into the sysroot, and then just DEPEND on that recipe16:48
*** Bunio_FH <Bunio_FH!> has quit IRC16:48
bri92It's a boot binary, get loaded via JTAG or burnt to QSPI flash16:49
qschulzbri92: it's very important to YP that if there's anything to be improved in our docs or other way, that you share what you would have liked (even better, a patch to docs). The project knows it's not easy but for long time contributors it's hard to see what to improve for beginners16:49
rburtonthen yes you want to do the explict depends on the do_deploy16:49
rburtonas depends is just shorthand for "this recipe's do_configure depends on these recipe's do_populate_sysroot"16:50
nemgti-ogI got another question I have been postponing. After sourcing the environment-setup script of my eSDK I can't run devtool - it complains that there is no python3.5.real (No such file or directory) in order to solve this I have to manually rm (only after sourcing the environment-setup script) python3 from ${SDKTARGETSYSROOT}/usr/bin. Does anybody know why this happens?16:50
rburtonnemgti-og: is there a python3.5.real in the sdk somewhere?16:51
rburton*should* be alongside the python3.5 wrapper16:51
nemgti-ogactually, python3.5.real is located in the same directory ${SDKTARGETSYSROOT}/usr/bin16:52
rburtonright, so figure out why it isnt being ran :)16:55
*** frsc <frsc!> has quit IRC16:55
*** yacar2_ <yacar2_!> has joined #yocto17:02
*** hpsy <hpsy!~hpsy@> has joined #yocto17:03
*** Bunio_FH <Bunio_FH!> has joined #yocto17:03
*** yacar_ <yacar_!> has quit IRC17:04
*** fl0v01 <fl0v01!~fvo@2a01:c22:b032:c800:64cf:561c:89fb:9dce> has quit IRC17:04
khemrburton: we need to autoconf it17:06
rburtonkhem: but i want to test a new autoconf release17:06
khemrburton: I was doing it in patches but thats too error prone17:06
khemyeah go for it17:07
rburtonkhem: but binutils aborts if the autoconf version isn't exactly 2.69 :)17:07
khemthere are patches which modify or other related files so other option is to regenerate configure in everyone of those patches manually17:08
khemusing 2.6917:08
khemand refresh those patches17:08
rburtonwhy isn't the usual autotools reconfiguring usable? it calls autoconf directly17:08
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8879:dca4:8dd7:7b83> has quit IRC17:08
khemas I said we modiy configure.ac17:08
rburton(i tried patching the version check out but then it broke because aclocal isn't modified)17:08
rburtonright, i mean why does binutils have a custom do_configure instead of using the autotools class17:09
khemit does not need reconf17:09
khemonly autoconf to regenerate configure17:09
khemnot bootstrap it17:09
khemperhaps fallback to adding configure changes to relevant patches17:10
khemand dont call autoconf is easier way forward17:10
khemeven though that means pain to maintain those patches17:10
khemJPEW: I think AUH has issues here17:11
khemthe recipe clearly says its not compatible with musl17:12
nemgti-ogWell... I dont really see it. What I know is, if I remove python3 from ${SDKTARGETSYSROOT}/usr/bin, then the next time I run devtool, it will use python3 from another directory (i.e. ./buildtools/sysroots/x86_64-pokysdk-linux/usr/bin/python3)17:12
khemJPEW: perhaps RECIPE_NO_UPDATE_REASON_libc-musl is a good workaround17:13
khembut I would think fixing it in AUH might be better17:14
*** armpit <armpit!~armpit@2601:202:4180:a5c0:152a:39f6:f4c:9605> has joined #yocto17:14
*** vineela <vineela!vtummala@nat/intel/x-olvdibbksifcrvzg> has quit IRC17:19
*** nerdboy <nerdboy!~sarnold@> has joined #yocto17:30
*** Bunio_FH <Bunio_FH!> has quit IRC17:30
*** nerdboy <nerdboy!~sarnold@> has quit IRC17:31
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:31
rburtonkhem: file a bug and cc kanavin17:34
*** mckoan is now known as mckoan|away17:39
*** WillMiles <WillMiles!~Will@> has quit IRC17:40
*** Bunio_FH <Bunio_FH!> has joined #yocto17:47
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC17:54
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC18:02
*** lucaceresoli <lucaceresoli!> has quit IRC18:02
*** ericch <ericch!> has quit IRC18:03
*** ericch <ericch!> has joined #yocto18:05
[Sno]RP: is it worth to do a upgrade of perl (5.30.1 -> 5.30.2) soon or is release more or less done?18:06
*** locutus_ <locutus_!> has quit IRC18:14
khemugh perl scares me always18:16
khemis it bugfix only release ?18:16
*** kiwi_29 <kiwi_29!> has joined #yocto18:18
*** locutus_ <locutus_!> has joined #yocto18:21
kiwi_29erbo ...many thanks for prompt reply. I will check the information you provided18:21
*** jobroe <jobroe!> has joined #yocto18:27
*** joseppc <joseppc!~josep@unaffiliated/joseppc> has quit IRC18:31
*** kiwi_29 <kiwi_29!> has quit IRC18:36
*** falstaff <falstaff!~quassel@> has joined #yocto18:37
*** bri92 <bri92!> has quit IRC18:39
*** berton_ <berton_!~berton@> has joined #yocto18:40
*** berton_ <berton_!~berton@> has quit IRC18:41
*** berton_ <berton_!~berton@> has joined #yocto18:41
*** jobroe_ <jobroe_!> has joined #yocto18:41
*** jobroe <jobroe!> has quit IRC18:42
*** berton <berton!~berton@> has quit IRC18:43
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC18:43
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto18:44
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto18:45
*** falstaff <falstaff!~quassel@> has quit IRC18:46
*** falstaff <falstaff!~quassel@2a02:169:3df5::509> has joined #yocto18:48
RP[Sno]: I'm probably nervous of that at this point18:51
*** falstaff <falstaff!~quassel@2a02:169:3df5::509> has quit IRC18:57
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC18:58
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto18:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:03
*** vineela <vineela!~vtummala@> has joined #yocto19:19
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC19:21
*** kpo__ <kpo__!~kpo@> has joined #yocto19:24
*** falstaff <falstaff!~quassel@2a02:169:3df5::509> has joined #yocto19:26
*** bradfa <bradfa!uid297668@gateway/web/> has quit IRC19:29
*** falstaff <falstaff!~quassel@2a02:169:3df5::509> has quit IRC19:30
[Sno]khem: yes19:31
[Sno]RP: that's why I'm asking before acting :F19:32
*** vineela <vineela!~vtummala@> has quit IRC19:33
*** vineela <vineela!~vtummala@> has joined #yocto19:34
*** vineela <vineela!~vtummala@> has joined #yocto19:37
*** dmoseley <dmoseley!~dmoseley@> has quit IRC19:37
*** lucaceresoli <lucaceresoli!> has joined #yocto19:37
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto19:39
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:51
*** grma <grma!~gruberm@> has quit IRC19:56
*** lucaceresoli <lucaceresoli!> has quit IRC19:56
*** grma <grma!~gruberm@> has joined #yocto20:07
nemgti-ogis cmake ran during do_configure task?20:10
erbonemgti-og: yes20:12
nemgti-ogthanks erbo. I guess RDEPENS is not needed during do_configure right? is DEPENDS needed at this stage?20:13
erbonemgti-og: correct, DEPENDS are for build time dependencies and RDEPENDS for run-time20:14
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:238d:84be:b349:9184> has quit IRC20:19
nemgti-ogerbo: I have a recipe that basically download a binary release from a github repo and another recipe that executes this binary on its CMakeLists.txt (add_custom_command block). In the second recipe, I have added a DEPENDS_${PN} += "<recipe-name-that-downloaded-binary>, but when running devtool build <second-recip> (in my eSDK), cmake cannot find the executable (File not found)20:22
nemgti-ogDo you by any chance have a clue of what I might be missing?20:22
kergoththere's no such thing as DEPENDS_${PN}20:22
nemgti-ogthen should it be simple DEPENDS += ?20:22
kergothRDEPENDS is per-package, because a single recipe emits multiple binary packages. DEPENDS is recipe-wide build dependencies20:22
nemgti-ogThanks. I'll give it a try20:23
kergothi don't know where people keep getting DEPENDS_${PN} from, it's not used anywhere in any layers20:23
nemgti-ogI don't know, maybe we are all newbies - at leats I am :D20:23
yoctiNew news from stackoverflow: do_rootfs error due to package installation <>20:25
kergoththat's fair enough, but i'd suggest 1) the yocto project docs and 2) looking at some existing recipes in oe-core, preferably both, as it'll help you get a good understanding. you can also use `recipetool create <url>` to create a recipe automatically given an upstream url to its sources20:25
kroonkergoth, you're the father of bitbake, right ?20:26
kergoththe project has an admittedly high learning curve, having as much flexibility as it does comes with a certain cost20:26
kergothone of them, yeah, it was a few of us that started the project. i'll take the blame for a lot of its code, i was still learning python at hte time :)20:27
*** lucaceresoli <lucaceresoli!> has joined #yocto20:27
nemgti-ogkergoth: is recipetool create doing the same as devtool add?20:28
nemgti-ogand thanks for the hints. I will comply20:29
kroonkergoth, well I'll give you credit for it. But there is a thing that confuses me, compared to GNU make, in that references to undefined variables are kept as is during immediate expansion, instead of evaluating to nothing as in make. Is that really the intended behaviour in bitbake ?20:29
kergoththat comes down to the original inspirations and code, actually. in retrospect it was a terrible decision20:30
kergothoriginally we were inspired by and even used a little of the code from gentoo's portage20:30
kergothgentoo's recipes were shell scripts, though, and we didn't want to go in that direction20:30
kergothwe left them unexpanded to keep a certain feature parity and to let the shell expand them if bitbake didn't20:30
kergothbut it just causes a ton of confusion bout when expansion occurs, now20:30
kergothwe should have used a different syntax entirely, ex %{} ala .spec20:31
kergothit was also to deal with unhandled syntax without having to directly parse the shell code20:31
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:238d:84be:b349:9184> has joined #yocto20:32
kergothfor example, ${foo:-bar} as used in a shell script would never be expanded by bitbake20:32
kergothunless you had a foo:-bar variable20:32
kergothso that really should be left as is20:32
kergothI prototyped patching bitbake to warn/error on unexpanded variables and got bit by those :)20:32
kergothlike i said, if we'd used a different syntax entirely for our own expansions it'd have been a nonissue, but a bit late to do anything about it now without adding a new file format entirely20:36
kergothwhich would be nice, but no one ever cares enough to take on that particular pain :)20:37
kergothincluding me20:37
kergothour file format has a lot of quirks, actually. the mixed declarative and imperative nature is quite irritating20:38
kergothit looks declarative, but a lot of things are order dependent, so it really isn't20:38
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:6d38:4a9b:444f:3860> has quit IRC20:38
kergoththere's also a very tight binding between bitbake and the metadata due to the file format. the latter makes assumptions about how the former does its work. the fact taht recipes and classes can add tasks and poke into *how* bitbake does its job makes it harder to introduce a new format without also mirroring that20:39
*** jobroe_ <jobroe_!> has quit IRC20:40
kroonkergoth, RP, so it sounds like that's not going to change, so I'd say merging is better than having incorrect examples in the manual20:41
*** jobroe <jobroe!> has joined #yocto20:41
kergothagreed, we should definitely mention the behavior20:41
kergothprobably in more places than just there, as it affects more than just immediate expansion20:42
kergothHmm, if we made emit_var also emit non-exported variables into the shell and then didn't expand bitbake variables in shell functions, it'd still be able to access those variables, but at runtime in the shell, I wonder how much would break. we'd still need to handle ${@} the way we do now, though20:42
*** pharaon2502 <pharaon2502!> has quit IRC20:46
*** md_micheal <md_micheal!057014fe@> has joined #yocto20:46
md_michealhello every body :)20:47
md_michealdoes any body have good tutorial for kernel linux (not only kernel module ) and how it work and maybe some historical decisions20:49
md_michealthanks a lot20:49
*** lucaceresoli <lucaceresoli!> has quit IRC20:59
*** locutus_ <locutus_!> has quit IRC20:59
*** fl0v0 <fl0v0!~fvo@2a01:c22:b032:c800:89c1:5f93:2b8e:d546> has joined #yocto20:59
*** vineela <vineela!~vtummala@> has quit IRC21:11
*** maudat <maudat!> has quit IRC21:17
*** berton_ <berton_!~berton@> has quit IRC21:17
*** vineela <vineela!~vtummala@> has joined #yocto21:18
millonimd_micheal: learning the kernel is difficult21:25
millonithere's no single resource21:25
millonii suggest you find someone who knows stuff about it and ask them21:25
millonior do you mean the kernel in yocto? in that case see meta-skeleton21:26
*** md_micheal <md_micheal!057014fe@> has quit IRC21:28
*** md_micheal <md_micheal!057014fe@> has joined #yocto21:40
*** pohly <pohly!> has quit IRC21:42
*** lucaceresoli <lucaceresoli!> has joined #yocto21:44
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:48
*** md_micheal <md_micheal!057014fe@> has quit IRC21:50
*** kpo__ <kpo__!~kpo@> has quit IRC21:55
*** fl0v0 <fl0v0!~fvo@2a01:c22:b032:c800:89c1:5f93:2b8e:d546> has quit IRC22:01
*** guerinoni <guerinoni!> has quit IRC22:01
*** yacar2_ <yacar2_!> has quit IRC22:10
*** nemgti-og <nemgti-og!~nemgti-og@> has quit IRC22:20
*** lucaceresoli_ <lucaceresoli_!> has joined #yocto22:21
*** lucaceresoli <lucaceresoli!> has quit IRC22:24
*** ssajal <ssajal!> has quit IRC22:30
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:1d:2274:9b1e:3f9d> has joined #yocto22:38
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:1d:2274:9b1e:3f9d> has quit IRC22:43
*** jkimblad <jkimblad!> has quit IRC22:57
*** rburton <rburton!rburton@nat/intel/x-zdrwznnsmvxvufns> has quit IRC23:00
*** Nojh <Nojh!uid52797@gateway/web/> has joined #yocto23:00
*** JaMa <JaMa!~martin@> has quit IRC23:10
*** dkl__ <dkl__!> has joined #yocto23:12
*** m1ster_r0b0t <m1ster_r0b0t!> has quit IRC23:15
*** lucaceresoli_ <lucaceresoli_!> has quit IRC23:15
*** kroon <kroon!> has quit IRC23:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:35

Generated by 2.17.2 by Marius Gedminas - find it at!