Wednesday, 2020-09-02

*** dev1990 <dev1990!> has quit IRC00:00
*** JaMa <JaMa!> has quit IRC00:02
*** JaMa <JaMa!> has joined #yocto00:02
*** radsquirrel <radsquirrel!> has quit IRC00:03
*** radsquirrel <radsquirrel!> has joined #yocto00:03
*** vineela <vineela!~vtummala@> has quit IRC00:11
*** ericch <ericch!> has quit IRC00:11
*** goliath <goliath!> has quit IRC00:13
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC01:09
*** rcw <rcw!~rcw@> has quit IRC01:28
*** TheComet_ <TheComet_!~hpom0@> has quit IRC01:31
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC01:39
*** elvispre <elvispre!> has joined #yocto01:40
alejandrohskhem: thanks!01:49
*** maudat <maudat!> has quit IRC02:08
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto02:08
*** hpsy <hpsy!~hpsy@> has quit IRC02:08
*** PaowZ__ <PaowZ__!~Vince@> has joined #yocto02:16
*** PaowZ <PaowZ!~Vince@> has quit IRC02:18
*** nslu2-log_ <nslu2-log_!> has joined #yocto02:26
*** paulg <paulg!> has joined #yocto02:27
*** nslu2-log <nslu2-log!> has quit IRC02:29
*** nslu2-log <nslu2-log!> has joined #yocto02:30
*** nslu2-log_ <nslu2-log_!> has quit IRC02:31
*** nslu2-log <nslu2-log!> has quit IRC02:33
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC03:09
*** sk48 <sk48!> has joined #yocto03:24
sk48Hello All, I am new to this yocto project. I have a question on building a java maven project using Yocto. I am looking for a maven library to build a maven project by using "maven" and store the results to rootfs instead of installing maven to rootfs. Could some one please help.03:28
*** stacktrust <stacktrust!> has quit IRC03:31
*** stacktrust <stacktrust!> has joined #yocto03:33
*** sk48 <sk48!> has quit IRC03:51
*** rr123 <rr123!~xxiao@> has joined #yocto04:18
*** feddischson <feddischson!> has joined #yocto04:29
*** beneth <beneth!> has joined #yocto05:41
*** AndersD <AndersD!> has joined #yocto05:49
*** rcoote <rcoote!> has joined #yocto05:53
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC06:00
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:01
*** pohly <pohly!> has joined #yocto06:02
*** awafaa <awafaa!sid716@gateway/web/> has joined #yocto06:03
*** ThomasD13 <ThomasD13!> has joined #yocto06:08
ThomasD13Hi, is someone here who works with "arago" (linux sdk from texas instruments, similar to yocto, based on openembedded) ?06:12
*** agust <agust!> has joined #yocto06:14
khemThomasD13: denix is working on arago06:20
ThomasD13khem, thank you very much - I'll try to contact him06:21
khemhe is in US Eastern time, so he must be fast asleep now06:21
*** frsc <frsc!> has joined #yocto06:31
*** nslu2-log <nslu2-log!> has joined #yocto06:33
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto06:40
*** mckoan|away is now known as mckoan06:42
LetoThe2ndhappy coffee ingestion time, dudes!06:44
ThomasD13Good morning LetoThe2nd. Did you get ever in touch with arago?06:45
LetoThe2nddepends on your definition of "getting in touch"06:46
ThomasD13I try to understand the main difference between arago and yocto. For example I noticed there is no devtool available. I would like to figure out if its worth to port somehow arago/ti-layers to yocto environment06:48
*** zandrey <zandrey!~zandrey@> has joined #yocto06:48
ThomasD13Or if it is even possible to do. I mean there must be a major difference, otherwise why would TI work with arago, and not "something poky similar"?06:49
*** nslu2-log_ <nslu2-log_!> has joined #yocto06:50
LetoThe2ndyou probably do not have to "port" anything. arago is just their distro, AFAIK.06:50
LetoThe2nde.g., grab poky, disable the poky layers, add the arago layers, done. thats the way it should be meant to be06:51
denix"similar to yocto, based on openembedded" that needs to be remembered!06:52
LetoThe2ndif you look at this;a=blob;f=configs/arago-dunfell-config.txt;h=c9428d9c0783bc5733ea5c8af542ee89315def85;hb=83d2564acbb00a48dc6044f92588ce2c646bff13 there even no need to use their setup script (sorry denix)06:52
*** fl0v0 <fl0v0!> has joined #yocto06:53
*** nslu2-log <nslu2-log!> has quit IRC06:53
LetoThe2ndits really just a stack of layers that is tested together to fill the needs of ti06:53
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto06:54
ThomasD13Okay, sounds like a newbie as me could just try it out06:54
LetoThe2nddenix: on that occasion, good work, please keep it up. after some stuff i've seen recently its hard to value it enough.06:54
*** nslu2-log <nslu2-log!> has joined #yocto06:54
LetoThe2ndThomasD13: if it offer something you want/need, sure you can. my personal way would be to just add the layers as noted in the script and start using them.06:55
ThomasD13Thanks for your view LetoThe2nd06:56
*** nslu2-log_ <nslu2-log_!> has quit IRC06:56
denixLetoThe2nd: what I don't get is why people keep on claiming it's not Yocto! is it because it's not Poky? Poky is not Yocto!06:56
LetoThe2nddenix: hehe. well you know that, i know that. unfortunately to the public, yocto == poky06:57
*** nslu2-log_ <nslu2-log_!> has joined #yocto06:58
ThomasD13denix, you mean me? I compare arago more to poky, since I understand its a "reference distro for TI hardware". Same as poky (for qemu)06:58
ThomasD13But I'm not sure if there is maybe some more "black magic" added by TI06:59
* LetoThe2nd ponders starting a "black magic matters" meme06:59
ThomasD13Oh no :D06:59
denixwhat black magic? it's all public...06:59
ThomasD13yes... black magic in a wider sense. Some stuff which I didnt discover yet, but required that it works somehow in the end07:01
*** nslu2-log <nslu2-log!> has quit IRC07:01
*** nslu2-log_ is now known as nslu2-log07:02
*** nslu2-log_ <nslu2-log_!> has joined #yocto07:06
*** nslu2-log <nslu2-log!> has quit IRC07:09
*** nslu2-log_ is now known as nslu2-log07:09
denixLetoThe2nd: and thanks to you for all your work! us developers sometimes have hard time talking to users, so your involvement in explaining things is really appreciated!!07:12
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:12
*** hpsy1 <hpsy1!~hpsy@> has quit IRC07:15
LetoThe2nddenix: hi507:15
*** hpsy <hpsy!~hpsy@> has joined #yocto07:16
*** yann <yann!> has joined #yocto07:21
*** fbre <fbre!91fdde45@> has joined #yocto07:24
fbreHi! What is intended to be the smallest?: core-image-minimal-initramfs or core-image-tiny-initramfs07:25
fbreWhat is the logical difference or idea behind, respectively?07:25
*** kaspter <kaspter!~Instantbi@> has quit IRC07:27
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:28
*** JaMa <JaMa!> has quit IRC07:28
LetoThe2ndfbre: well by looking at it, one could guess that the tiny incarnation is 1) based on poky-tiny 2) x86 only07:30
LetoThe2ndOTOH, the tiny version seems to be a bit more fine tuned / advanced, the minimal version is more generic / bare bones07:31
*** dev1990 <dev1990!> has joined #yocto07:31
fbreah OK thanx. Although it doesn't make a problem to overload COMPATIBLE_HOST = "(i.86|x86_6|aarch64).*-linux" in a core-image-tiny-initramfs.bbappend07:33
fbreI just have to tweak its script a bit since we don't have pluggable rootfs media07:35
*** diego_r <diego_r!> has joined #yocto07:36
* denix -> zzz07:38
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:44
*** goliath <goliath!> has joined #yocto07:54
*** PaowZ <PaowZ!~Vince@> has joined #yocto07:59
fbreUrgs, there is no RT patch for the kernel for the yocto release "warrior"08:02
*** PaowZ__ <PaowZ__!~Vince@> has quit IRC08:02
fbreWould be nice if such requirement becomes standard for yocto releases08:03
LetoThe2ndfbre: disagreed:
fbrehmm, I took a look here: and here
LetoThe2ndfbre: do not blame yocto for whatever freescale/imx support yank out.08:10
fbreand here
fbreok, sorry. Then it's up to NXP08:10
LetoThe2ndfbre: seriously, i do not care that much where you looked. but i really have to point out that a false accusation of something being not there, and then even the request for it becoming standard (for you, free, or are you a high ranking member that i do not know about yet?) is quite unfortunate.08:12
LetoThe2ndfbre: if you look back a coupe of weeks in your own story here, many hassles have obviously been caused by that imx/codeaurora stuff. go blame your board verndor for pointing you there.08:13
fbreI don't want to be offensive. The idea was just because of lack of knowledge NXP has own source copies. I come as NXP user and didn't know what the repo topology is08:18
fbreI thought all releases base on the same kernel versions and vendors just put its meta layer on it08:19
LetoThe2ndfbre: i see. in a nutshell: what we care about is on if its not there, its up to somebody else to provide/fix it.08:19
fbre...but obviously generic yocto uses different kernel versions than vendor copies do, at least since you have an RT patch but there is not RT patch for NXP's release of warrior08:21
LetoThe2ndand as we've not only had but are having our fair share of board / BSP vendor crap each and everyday here, some folks (and especially me!) am highly reluctant to care about it. those who sell the hardware also get the money. its their duty to support it. not mine.08:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:21
LetoThe2ndunless somebody pays up, i do absolutely not care about which kernels nxp ships.08:22
fbreWell, just see my initial thought as idea for NXP's release "warrior" then. I think the "problem" is now the use of equal names for releases which are not version-identical (but just similar)08:28
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto08:29
fbreEqual names for different things lead to such questions here ;-)08:29
fbreYour "warrior" is not NXP's "warrior", this is what I've learned now08:30
fbreSorry, if this came offensive. I appreciate your help here very much08:31
LetoThe2ndno. you're mistaken here. the whole point of a BSP *IS* to inject a bootload/kernel/driver combination that makes a certain hardware work. the release name basically states the rest of the package versions and mechanisms you can use. so, our warrior versions are pretty much also those that nxps layers will use and rely on. BUT(!!) this does not apply to the kernel. and thats the point.08:31
LetoThe2ndso whatever a vendor hands you as kernel/bootloader/xxx combination, it is *THEIR* duty to a) support it b) state clearly what it brings, and what it doesn't bring. there is no nitpicking about names here. it is about both the vendor providing proper information, and about the user actually consuming it.08:32
LetoThe2nde.g., if you're on warrior you'll find a defined set of gcc, binutils, glibc, openssl, and so on and so on. that is what the version defines.08:35
fbreI see. Thanx for explaining it!08:40
*** awe00_ <awe00_!~awe00@unaffiliated/awe00> has joined #yocto08:42
fbreI thought a defined kernel version is also part of the release version labeled with a certain name. Likely this is even mentioned in any readme I have overseen :-D08:42
LetoThe2ndnope. you're messing up the scope. of course yocto/Oe ships a specific kernel  version with a release. but that does explicitly *NOT* mean that this release can only be used with that kernel version. again, as i already wrote a couple of minutes ago: the whole point of a BSP is to provide a kernel that make the desired hardware work.08:44
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC08:45
*** awe00__ <awe00__!~awe00@unaffiliated/awe00> has joined #yocto08:45
zandreyfbre: as I already pointed out the other day - please turn yourself to meta-freescale community BSP. it has almost all what NXP offers, and it is also closer to OE mainline08:46
zandreyfbre: if you feel there is an RT kernel missing - feel free to drop PR in meta-freescale to have it integrated.08:47
RobertBerger@fbre which NXP chip do you use?08:47
RobertBerger@fbre which kernel do you use on this chip?08:47
*** awe00_ <awe00_!~awe00@unaffiliated/awe00> has quit IRC08:48
zandreyfbre: the assumption about kernel releases from NXP is also not quite correct. what NXP does is: they pick a stable *tag* and drop their patches on top. then it goes to community, where people can up-merge later tags on top of what NXP delivers.08:48
zandreyin a meantime - NXP pick *another tag*, drop some more patches and release it under their next release08:49
RobertBerger@fbre if you use a kind of upstream kernel for your NXP chip you can apply the preempt-rt patch yourself.08:49
zandreythis one also gets picked up, upmerged - and so the story goes.08:49
zandreyyou would be surprised to see that in between 5.4.2 and 5.4.24 (which corresponds to NXP releases 1.0.0 and 2.1.0) there are significant differences in the kernel!08:50
LetoThe2ndzandrey: all the more reasons to not go for the stuff that gets mangled into those codeaurora things, and use vanilla OE/Poky as the base08:52
fbreRobertBerger: Currently, 4.14.78 with sumo. I tried several attempts to switch to warrior and zeus. I get the repo according to the NXP docs from repo init -u -b imx-linux-[version] -m imx-[version].xml08:53
RobertBerger@fbre which chip?08:53
fbreRobertBerger: imx808:53
zandreyLetoThe2nd: true! the only poor people that would be left outside though - are those who needs graphics and multimedia from NXP08:53
RobertBerger@fbre you need graphics/multimedia and so on?08:53
RobertBerger@rber or just headless image?08:54
RobertBergerI write to myself ;)08:54
LetoThe2ndzandrey: then they have to either pay for somebody to fix the crap for them, or go bitching to nxp.08:54
RobertBergerWe are back to the "crappy vendor" discussions.08:54
fbre@RobertBerger camera drivers and video4linux08:54
LetoThe2ndzandrey: in this current state we only get to pick up the pieces of the fallout.08:54
zandrey"or go bitching to nxp" - that would not work... they would probably get that stuff done for themselves, but not all others... :(08:55
LetoThe2ndRobertBerger: did we ever get away from it?08:55
RobertBergerHmm since you don't seem to need the "special NXP sauce" upstream might work.08:55
zandreyRobertBerger: this were fun times in Lyon... :)08:55
LetoThe2ndzandrey: seriously, thats not my problem. people have to either support the stuff they sell (as they get the money), or people have to buy somewhere else.08:55
RobertBergerIf end users don't demand anything better that's what you get.08:56
RobertBergerThe problem is:"What is the alternative?"08:56
LetoThe2ndthe point is that endusers and/or nxp obviously think that community support will fix it for free. and thats what i strongly oppose.08:57
RobertBergerThey should know by now that this is not the case.08:57
* LetoThe2nd shurgs.08:57
RobertBergerAnd the community does NOT fix it. It's the consultants who sell the same fix to multiple customers without - without upstreaming.08:58
RobertBergerSince upstreaming costs extra.08:58
fbre@zandrey: I get the repo according to the NXP docs from repo init -u -b imx-linux-[version] -m imx-[version].xml  You wrote "please turn yourself to meta-freescale community BSP" but I don't know what you mean what checkout command I should use in your case, if you mean a whole repo or just a08:58
fbrespecific layer. No real idea of the background08:58
RobertBergerAnyways back to @fbre.08:58
RobertBergerActually if you really really really want to use the NXP stuff it works as advertised.08:59
zandreyLetoThe2nd: totally agree! i'm just trying to advocate the fact that when people managed to get the vendor delivery done which can be used with upstream - they should contribute it back08:59
RobertBergerBut why don't you try meta-freescale (to build the boot container for you) and some 5.8.x upstream kernel?08:59
zandreyfbre: i posted the link the other day that you can use Yocto Quick Start Guide, and replace meta-altera in it to meta-freescale09:00
RobertBergerLinux version 5.8.5-custom-ml-virt (oe-user@oe-host) (aarch64-resy-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) #1 SMP PREEMPT Thu Aug 27 07:31:49 UTC 202009:00
zandreythat way you get "community" BSP, which (with some tweaks) gives you a dunfell OE-Core base + NXP kernel + graphics + MM09:01
RobertBergerWhat zandrey says will work as well. My point against it would be that I would use this ONLY if graphics and multimedia are needed.09:02
zandreyRobertBerger: exactly! this is really for those folks on the sidewalk, which do require GPU+VPU+IPU stuff from NXP09:03
RobertBerger@fbre just for your understanding I am running 5.8.x on an imx8mm (no MM, no graphics, still no SD card) with upstream and this patch, which is mainly device tree stuff:
fbrezandrey: yes, you posted the other day (25/08) a link to but I replied I do not understand it fully because meta-freescale is just one layer of many layers and I don't understand how I should get it married with my checked out sumo, warrior or zeus release I have checked out from NXP's codeaurora link09:08
zandreyfbre: if you follow a Quick Build Guide - then it should be straight forward for you to get a working image. that Guide is really well-written, and it takes you through all steps to get started with Yocto.09:11
zandreyi guess you're missing a concept about Yocto Project in general. it is *not* about cloning the manifest, it is about building your image by utilizing distribution, machine, and image.09:12
RobertBerger@fbre I think you lack some basic understanding - I know a trainer ;)09:14
zandreythis is what LetoThe2nd was pointing you to: you can have a distro from oe-core (poky), but once it comes down to really have it running on your machine (imx8m mini) - then it has to be combined together09:14
* LetoThe2nd is off to some js wrangling09:14
fbrezandrey: is my guide, especially A1. Quick Start. After that I have a full yocto source tree here I can bitbake. Do you mean I should remove a single layer yocto/sources/meta-freescale with the code I find in your ? But what about09:15
fbremeta-freescale-3rdparty and meta-freescale-distro and meta-fsl-bsp-release then, is it still a consistent system then?09:15
zandreyfbre: unless you do not use any vendor board (Variscite, Congatec, etc) - you do not need -3rdparty09:16
zandrey-distro you would need to have09:16
zandreymeta-fsl-bsp-release afaik contains manifests for repo tool which are not maintained (maybe...) so i would not pull it in09:17
zandreywhich MACHINE do you have?09:17
fbreRobertBerger: I once attended your training (a few months back) but actually just now I reached the sufficient level of understanding. Actually I would need the whole week again :')09:18
zandreyin this case - it resides in meta-freescale, so you can even skip the -distro09:19
RobertBerger@fbre: Feel free to join09:19
RobertBerger@fbre: I also offer "private" training and consulting09:19
zandreybut if you say: i need graphics - then you should pull meta-freescale-distro in, because that one defines the graphics packages you require09:19
zandreyfbre: take an offer from RobertBerger - do a recap, he might (maybe) go for discount! :D returning customer... :D09:20
RobertBerger@zandrey: Or ask more, since he didn't understand the first attempt ;)09:21
zandreyRobertBerger: either way - it's your offer! :D09:22
RobertBergerSure - if fbre want one he knows where to find me - he has my contact details.09:23
fbreActually we just use a specific camera driver and video4linux as API to the firmware. No need for most graphics stuff.09:24
RobertBerger@fbre As I said I would go for upstream plus whatever would be necessary and the camera driver is yours I guess.09:28
fbreit sounds very promising RobertBerger has an imx8mm running with 5.4.x. Probably, I'm gonna email you about that. Just now I'm very in hurry to just get an overlayfs working with that technique of bundling an initramfs image to the kernel. Meanwhile I almost found out how to get that working in the yocto-version "sumo". All attempts to use newer09:28
fbreversions currently lead to strange errors during bitbake, and I'm running out of time to tackle a whole distro switch.09:28
*** saraf <saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has joined #yocto09:29
RPkhem, armpit: Found the bind build issue, its with mutlilib, will fix09:34
fbreCurrently, I have managed it, based on sumo, to bitbake a kernel with bundled tiny-initrams which contains a hacked script which setups an overlayfs over the whole root filesystem. The only question is currently to get that Image....bin file to the boot partition. IMAGE_BOOT_FILES_append = "09:34
fbre${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin"  does not have an effect09:34
zandreyfbre: i have to say that your approach would generally work, but (a) it would lead you to nowhere in regards to keeping your device up-to-date; and (b) you would spend now more efforts to make that combination work rather than switching to what upstream can offer.09:34
zandreybut - it's your way, you make a decision here09:36
*** nslu2-log_ <nslu2-log_!> has joined #yocto09:36
fbreyes, but I have timelines, and the number of errors is too high on my attempts to a whole distro switch. The distro switch to something very much makes sense but too much time-consuming right now09:37
*** nslu2-log <nslu2-log!> has quit IRC09:38
fbreAs you see, it's already not easy to find out how I can get something which is ready for the RT patch :-D09:40
RobertBerger@fbre: Just for me to understand: What is actually your problem. I guess I missed something there.09:40
RobertBerger@fbre: The RT patch?09:40
*** nslu2-log_ <nslu2-log_!> has quit IRC09:42
*** fbre <fbre!91fdde45@> has quit IRC09:45
*** saraf <saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has quit IRC09:47
*** fbre <fbre!91fdde45@> has joined #yocto09:47
fbreRobertBerger: I have several things to meet: RT patch, overlayfs for the whole filesystem, imx8mm, some patches in our own meta layer I have to port from sumo to newer versions. I have a working NXP-"sumo" here but noticed overlayfs is not properly supported there. So the first problem is how to get a whole checkout of yocto which makes sense for09:47
fbrethat. I just know how to get yocto with chapter "A1. Quick Start" from
*** saraf <saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has joined #yocto09:48
fbre...which is getting the sources from codeaurora. It's already hard to understand for me what it is all about the other repos and alternative ways to get a yocto source tree I can bitbake.09:49
RobertBerger@fbre I totally understand that09:49
RobertBerger@fbre I usually don't even want to understand it ;)09:50
RobertBerger@fbre: in order to have the RT patch you need very specifc/ideally upstream kernel versions. Those:
fbreIt sounds very promising you have managed it to get a working source tree of the latest yocto for bitbaking it09:51
fbreon an imx8mm eval board09:51
RobertBerger@fbre: It tool me some time, but yes ;)09:51
RobertBerger@fbre For some reason the SD card does  not work. I guess some device tree stuff, I need to fix, but I don't care at the moment.09:52
RobertBergeroverlayfs - you mean for the flash, or for some container?09:53
RobertBergerWhat you need the overlayfs for?09:54
fbreRobertBerger: The idea is to mount flash partitions where the base system is read-only as factory-reset state, and an overlayed readwrite layer for updates and working09:54
RobertBerger OK I see09:55
RobertBergerThat's kernel only09:55
fbreSuch overlayfs initialisation must be done before the rootfs is mounted because I have to chroot the root directory "/" to that mountpoint09:56
RobertBergerWell not sure about that one09:57
fbreThis forces me to use an initial RAM filesystem with appropriate scripts which is bundled to the kernel .bin file09:57
qschulzfbre: or an initial initramfs doing all the things and then a switchroot to the ro base-system rootfs?09:58
*** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has joined #yocto09:58
qschulz(just chiming in without having read any of the messages before so please ignore if completely out of topic :) )09:59
fbreThe bootloader u-boot loads such kernel with root=/dev/ram0 and the scripts in that RAM file system mount the flash partitions, put them together to an overlayfs, e.g. in /mnt/overlay_fs, and then switch the root to that directory.09:59
*** saraf <saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has quit IRC09:59
RobertBerger@fbre: This is old, but might do what you want:
fbreRobertBerger: It would be coold if you could tell me the commands you use to checkout your yocto source tree from git, I mean the one which works with imx8mm for you on a 5.4.x kernel :-)10:00
fbreRobertBerger: Can I email you for that?10:01
zandreyfbre: i guess this discussion goes beyond the yocto, right? it is more about your system architecture, and i'm not sure if this should be tackled here in this channel10:01
zandreyunless the audience would not mind :)10:01
RobertBerger@fbre - sure10:01
LetoThe2ndi think its educational for the audience and nobdy is being interrupted by it so i see no problem in going ahead. i don't think we have strict ontopic rules here.10:02
fbreqschulz: Thanx for the link. I'll read it :-)    zandrey, sorry for making too much noise here. It's at least many times faster for me to get good help than writing in the NXP forum where rarely someone replies. ;-)  Thanx guys! Thanx RobertBerger!10:04
zandreyLetoThe2nd: cool, then let's move on :)10:05
zandreyfbre: no problem! NXP forums are actually lagging, as i guess people either get direct support or discuss issues over MLs10:06
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto10:06
zandreyfbre: you can also use for questions, the audience is a bit broader there i guess than on nxp forums10:07
*** saraf <saraf!~a_saraf@2409:4042:87:56e7:202f:eaa6:3676:2bf5> has joined #yocto10:07
RobertBerger@fbre - you're welcome10:11
*** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has quit IRC10:11
*** mbulut <mbulut!> has joined #yocto10:18
*** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has joined #yocto10:19
*** saraf <saraf!~a_saraf@2409:4042:87:56e7:202f:eaa6:3676:2bf5> has quit IRC10:19
*** saraf <saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has joined #yocto10:23
*** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has quit IRC10:24
*** mbulut <mbulut!> has quit IRC10:26
*** mbulut <mbulut!> has joined #yocto10:27
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto10:27
*** zandrey <zandrey!~zandrey@> has quit IRC10:30
*** mbulut <mbulut!> has quit IRC10:34
*** saraf <saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has quit IRC10:40
*** PaowZ_ <PaowZ_!~vince@2a01:e35:2e3e:4ac0:2430:f533:346b:e471> has quit IRC10:47
*** mbulut <mbulut!> has joined #yocto10:51
*** mbulut <mbulut!> has quit IRC10:57
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto10:59
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has quit IRC11:03
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto11:03
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has joined #yocto11:03
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto11:05
*** AndersD <AndersD!> has quit IRC11:18
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:19
cengiz_iohello there! I'm working with dunfell and my image build fails due to lttng module dependencies. Problem 1: package lttng-modules-2.11.2-r0.mmmm requires kernel-module-lttng-uprobes-5.4.51-fslc+g78f9980f23eb, but none of the providers can be installed11:20
cengiz_iohow can I disable lttng alltogether?11:20
cengiz_ioI tried adding "lttng-uprobes" to my image but there's no such recipe.11:21
cengiz_ionor a kernel module11:21
zandrey_getting back on the topic of discussing "vendor BSPs": there is a section 3 in which actually can be mis-interpreted.11:23
zandrey_as the latest discussion suggests - users tend to mix Poky with vendor BSPs (in terminology), and that charter imho only assists in this regards: it says - use vendor BSPs where possible, not stating that the BSP delivered from vendor does not necessarily adhere to the OE setup11:25
zandrey_NXP here is a good example, where they take community layer, drop their layers on top, create a repo manifest - and delivers this to customers, who (even after reading Yocto Project docs) are still under impression that this BSP is Yocto11:26
zandrey_maybe a more detailed explanation should be given there?11:26
zandrey_on at least to provide users the sight of the border between community silicon layers, and vendor custom layers11:27
zandrey_fbre: for the rest of - it is a pretty well-formed Q&A for those who jumps into Yocto Project11:28
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:29
fbre(y)  thanx for the document. I'm reading it in parallel to my work here11:32
*** rcoote <rcoote!> has quit IRC11:32
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC11:34
*** kpo_ <kpo_!> has quit IRC11:35
*** kpo_ <kpo_!> has joined #yocto11:35
*** otavio <otavio!~otavio@> has joined #yocto11:36
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto11:36
*** berton <berton!~berton@> has joined #yocto11:40
*** rcoote <rcoote!> has joined #yocto11:40
fbrezandrey_: I think it's quite normal users first just use the stuff from their vendor and do not know the borders between vendor stuff and free community stuff, especially in this example of following NXP's tutorial of getting a version "warrior" from source repos and then notice there is not RT patch for it. As a user I don't know at first sight11:41
fbrewho is responsible for not providing the RT-patch functionality. It's a complex world of software parts (kernel, patches, distro around it)11:41
*** rcoote <rcoote!> has quit IRC11:44
*** rcoote <rcoote!> has joined #yocto11:45
zandrey_fbre: this is exactly my point - there is a statement missing in the "Beginner's Guides" which should outline this border. i guess it would remove a lot of confusion and point users into a right perspective from the start.11:45
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC11:46
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC11:48
fbrezandrey_: Regarding  , is this stuff from poky or from NXP?11:50
*** zandrey_ <zandrey_!~zandrey@> has quit IRC11:51
*** zandrey <zandrey!~zandrey@> has joined #yocto11:51
*** rcoote <rcoote!> has quit IRC11:51
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto11:51
fbrezandrey_: Regarding  , is this stuff from poky or from NXP?11:53
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto11:54
*** rcoote <rcoote!> has joined #yocto11:57
*** zandrey <zandrey!~zandrey@> has quit IRC11:57
*** zand__ <zand__!~zandrey@> has joined #yocto11:57
*** berton <berton!~berton@> has quit IRC11:58
*** zandrey_ <zandrey_!~zandrey@> has quit IRC12:00
mckoanfbre: meta-freescale is a NXP layer12:04
*** zandrey_ <zandrey_!~zandrey@> has joined #yocto12:05
mckoanand looks like zandrey_ did a lot of work on that! Thanks12:07
*** zand__ <zand__!~zandrey@> has quit IRC12:09
fbrezandrey: You told me to use meta-freescale from (of whom?) instead of codeaurora (repo of NXP? At least advised by NXP). I wonder how I should mix up a whole git source checkout with a layer from another location.12:09
*** zand__ <zand__!~zandrey@> has joined #yocto12:09
*** zandrey <zandrey!~zandrey@> has joined #yocto12:10
zandreyfbre: there are 2 answers to your question - simple and complicated ones. ;) the simple one: this is neither of both!12:10
zandreythe more complicated answer is: poky is a reference distro from OE, hence it does not contain any HW specific. this is what LetoThe2nd wrote you earlier12:11
zandreyand at the same time - it is not a pure NXP layer, as it is not maintained by NXP directly12:12
zandreythey do provide contributions to it, but it is not actively maintained by them.12:12
*** zandrey_ <zandrey_!~zandrey@> has quit IRC12:13
zandreyso it is safe to say - this is a "community BSP layer", where NXP releases are merged into and also the compatibility to latest OE-Core is maintained12:13
zandreyand in fact - NXP uses this layer and includes it into their manifest for repo tool when they release their "vendor BSP"12:15
*** fbre <fbre!91fdde45@> has quit IRC12:16
*** RobertBerger <RobertBerger!> has quit IRC12:17
zandreyso it is a two-sided coin: NXP updates their copy of recipes with things like new MACHINEs, new recipes (e.g. eIQ); updates GPU drivers, firmware, etc. on the other hand - meta-freescale is maintained to provide a compatibility to current OE-Core, and once NXP announces the release on codeaurora - all those NXP-specific things are getting picked up and merged with latest OE-Core to make sure that targets can use "the best of both worlds".12:18
*** RobertBerger <RobertBerger!~rber@> has joined #yocto12:18
*** fbre <fbre!91fdde45@> has joined #yocto12:19
fbreshit, I got disconnected lol12:20
zandreyfbre: that is the reason i was pointing you into that direction - if you move away from the NXP "locked-down" BSP fetched via their manifest and create your own one by pulling meta-freescale layer yourself, then you would get dunfell BSP with kernel 5.4.61 + all NXP patches from release 5.4.2-1.0.012:21
zandreyand all other layers you pull would not be in conflict with it ;)12:21
*** rcoote <rcoote!> has quit IRC12:22
zandreybtw, next in pipe for the master is NXP release 5.4.24-2.1.0 integration12:22
*** JaMa <JaMa!> has joined #yocto12:22
fbreah, I think this is the missing link in my understanding, I need to create another manifest for pulling your advised meta-freescale layer instead of the one NXP uses in their manifest12:22
zandreyfbre: here is a funny fact - NXP actually pulls meta-freescale in their manifest! :) they need it to provide a "base" compatibility with whatever branch of OE-Core is there. in your case it is warrior.12:24
zandreyi actually also see your confusion: "warrior" release from NXP didn't have a clean layer structure. they made it with "zeus", where they created a separate repository to store their "custom" layers.12:26
zandreyit is a meta-imx which you can see on codeaurora12:26
smurrayhaving jumped through hoops just yesterday to test something with meta-imx, I'd advise avoiding it if at humanly possible12:28
smurrayerr, at all humanly possible12:28
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC12:29
zandreysmurray: totally agree! the only reason i mentioned it is: this is the *only* source of information i have on the upgrade of meta-freescale12:30
zandreyother than that - there is no chance to see what NXP published in their public "vendor BSP"12:30
*** kaspter <kaspter!~Instantbi@> has quit IRC12:33
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:33
*** rcoote <rcoote!> has joined #yocto12:33
*** rcoote <rcoote!> has quit IRC12:43
*** fbre <fbre!91fdde45@> has quit IRC12:48
*** rcoote <rcoote!> has joined #yocto13:04
JPEWRP: Did the reproduibility diff get correctly generated for that latest failure>?13:06
*** ilkappe <ilkappe!c65a42b1@> has joined #yocto13:10
*** paulg <paulg!> has quit IRC13:11
ilkappehello guys ! I Have a question, I have built both the kernel and the dtb and booted my target with those files. After the login I've searched for a specific drivers (that I have enabled in .conf with the appropriete CONFIG line) in13:13
rburtonkanavin_home: can you do me a favour and verify that eg atk builds correctly with gtk-doc enabled?13:13
RobertBerger@zandrey,@smurray: I think I am building for their eval board poky+meta-freescale - needs a bit better, but seems to work13:13
ilkappe$ ls /sys/module13:13
RobertBergerbit better docu13:13
ilkappeby the way I can't see the module in the list. P.S. the module is a builtin module13:14
RPJPEW: hmm, didn't check13:14
RPJPEW: yes, looks like it did :)13:15
ilkappeAFAIK in /sys/module all the kernel builtin modules are listed, also if they are not loaded. Is it true ?13:15
RobertBerger@ikappe just for me to understand - you mean it's an in-tree kernel module?13:21
RobertBergera .ko file on your rootfs/13:22
RobertBerger@ilkappe: check in /lib/modules/$(uname -r)13:23
ilkappeRobertBerger I set CONFIG_XXX=y in the .conf file used for kernel compilation13:24
RobertBergerAh OK it's statically linked with the kernel13:24
*** paulg <paulg!> has joined #yocto13:25
ilkappeAlso, I do not know why but the rootfs.tar.gz file do not have any /lib/modules/13:25
RobertBergerI know ;)13:25
ilkappethat's a surprise13:25
RobertBergerI guess it's a small one like core-image-minimal13:25
RobertBergerhehe ;)13:25
RobertBergerlook into your machine config13:25
ilkappeyou are the best and you know eh ? I noticed that is shipped in another .tar.gz by the way13:26
RobertBergerin you machine config do you see kernel-modules in MACHINE_EXTRA_RRECOMMENDS?13:27
*** stephano <stephano!> has joined #yocto13:27
ilkappeRobertBerger I'm searching for it13:28
ilkappebut I bet its not13:28
RobertBergerWell even if it is it won't work13:28
RobertBergerThis variable affects only images based on packagegroup-base, which does not include the core-image-minimal or core-image-full-cmdline images.13:28
ilkappeby the way after building the core-image-minima the modules_4.19--XXXX.tar.gz is created in the build/tmp/deploy/images13:28
RobertBergerSo throw in MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-modules kernel-devicetree" and it is going to work13:29
RobertBergeryes of course, but it's not in the image13:29
ilkappethat .tar.gz has the /lib/modules folder and also the modules.builtin file13:29
RobertBergerunless you do the change I said13:29
qschulzRobertBerger: meh... i wouldn't put kernel-modules in an RDEPENDS but rather each kernel-module-something which is **actually** required by the machine13:30
ilkappeRobertBerger yep ! that it's now clear, thanks13:30
ilkappeRobertBerger by the way inspecting the modules.builtin files in the modules-4,19_XXXX.tar.gz file do not list my expected statically linked driver..13:31
RobertBerger@qschulz - so please tell ilkappe which to add ;)13:31
RobertBerger@ilkappe your statically linked driver will not be there13:31
RobertBerger@ilkappe it will be only there if you change the =y to an =m13:32
ilkappeRobertBerger, so now it is definitely clear to me13:32
*** PaowZ <PaowZ!~Vince@> has quit IRC13:32
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto13:32
ilkappethere is not any way to list the statically linked modules of the kernel from the userspace ?13:33
RobertBergerDo you have IKCONFIG_PROC enabled?13:34
RobertBergerif so at least you will see in /proc/config.gz that it's enabled in the currently running kernel13:35
ilkappeit seems so13:36
RobertBergerBut does it really need to be statically linked?13:36
RobertBergercan't it be =m?13:36
ilkappeProbably I can make it so13:36
RobertBergerI suggest you first see that you get all your .ko into you rootfs13:36
smurrayRobertBerger: poky + meta-freescale does mostly work for most of the NXP boards13:37
ilkappeBut I was curios to know it it was possible though13:37
RobertBergerand then you make it =m and load it13:37
RobertBerger@smurray - at least it seems to compile ;)13:37
ilkappeRobertBerger thanks man13:37
smurrayRobertBerger: I've got various boards working in AGL with it.  My issue yesterday was tinkering to see if there's some special sauce in meta-imx for the Bluetooth on the i.MX8MQ EVK-B13:38
RobertBerger@ilkappe - you're welcome13:39
RobertBerger@smurray are we all fixing NXP stuff lately?13:39
RobertBergerThank you NXP for your ***** **** so it never works as expected and we can all have lots of work.13:40
smurrayRobertBerger: this was for a specific ask from someone; generally NXP support in AGL is purely community-driven, though it's become the case that it's basically just me picking at it as time permits13:41
ilkappeRobertBerger config.gz worked like a charme.13:41
RobertBergerYou might also try cat /lib/modules/$(uname -r)/modules.builtin13:41
LetoThe2ndRobertBerger: cat abuser!13:42
ilkappethat one is a little odd13:42
RobertBerger@LetoThe2nd you mean you need anything else besides echo and cat?13:42
ilkappeif untar the generated modules-4.19_XXXX.tar.gz13:42
ilkappeand cat the modules.builtin13:43
ilkappethere is no sign of the driver13:43
RobertBergerWith my trick from above they will be put into the rootfs13:43
RobertBergerThe drivers should be signed if that's enabled13:43
RobertBergerNo matter if you add them manually or not13:43
RobertBergerIt's done in compile time13:44
ilkappeyes! I have understood that13:44
ilkappebut i do not understand whu the driver is not listed anyway in the tar file13:44
RobertBergerLet's see again13:44
ilkappeRobertBerger, I've thought that too13:44
RobertBergerin config.gz is it =y or =m?13:44
ilkappebut in /proc/config.gz I got the driver with =y13:45
RobertBergerso it's only in cat /lib/modules/$(uname -r)/modules.builtin13:45
RobertBergerand not in the modules tarball13:45
ilkappebut in the /lib/modules/.../module.builtin there is nor13:45
RobertBergerSo it's totally missing ;)13:45
RobertBergerThat's your problem ;)13:45
RobertBergerIf it's neither in cat /lib/modules/$(uname -r)/modules.builtin nor in the tarball it's not compiled ;)13:46
RobertBergerHow did you set the =y?13:46
ilkappeKERNEL_defconfig variable file has the line CONFIG_MYDRIVER=y13:46
RobertBergerso you made your own driver13:47
RobertBergerDid you add it also to kconfig?13:47
RobertBergerdoes it show up in menuconfig?13:47
ilkappeyes it shows up13:48
RobertBergerWhat does it do?13:48
ilkappeand I see that it is compiled because a .o is gnerated n its folder13:48
RobertBergercan you print something in init?13:48
RobertBergerand check dmesg if that's printed?13:48
ilkappebasically I got a custom kernel with a custom driver from a vendor13:48
RobertBergerAs I said go back and make it =m13:48
RobertBergerLoad it manually and see if that works13:49
ilkappea built the kernel using theri congiuration file also13:49
RobertBergerif that's OK then make it =y13:49
ilkappeyes, that's what I thought13:49
*** ilkappe <ilkappe!c65a42b1@> has quit IRC13:50
*** ilkappe <ilkappe!c65a42b1@> has joined #yocto13:50
ilkappeRobertBerger, sorry I was disconnected. I'll try what you suggested me.13:51
ilkappeyou know that uh ?13:52
*** ericch <ericch!> has joined #yocto13:54
*** sk48 <sk48!> has joined #yocto14:02
*** sk48 <sk48!> has quit IRC14:04
*** sk48 <sk48!> has joined #yocto14:04
yannI have a recipe for the "st" terminal emulator, which we use as a replacement for matchbox-terminal.  I guess meta-oe would be where to submit it ?14:07
*** sk48 <sk48!> has quit IRC14:10
rburtonyann: yes14:13
*** maudat <maudat!> has joined #yocto14:15
yannthere is one last thing in it that's bothering me, it ships its own terminfo defs, but those files are also shipped by ncurses-terminfo, what would be the policy to apply in such cases ?14:15
rburtonwhy does it ship its own?14:15
frayin most cases I've worked on.. if the files conflict, I drop the replacement versions and stick with the system originals14:16
yannprobably because it authoritatively knows how it behaves itself :)14:16
frayI've seen other programs ship with their own terminfo before.. I don't have a clue why14:16
fraywhen i diffed them, they were the same as the terminfo (current or slightly older version)14:16
yannand in fact, since ncurses-terminfo is not necessarily installed, it seems sane to let it ships its own14:17
frayfrom an OS integration standpoint, you set a dependency and make sure it's installed..14:17
*** sakoman <sakoman!> has joined #yocto14:21
*** ThomasD13 <ThomasD13!> has quit IRC14:23
yanni'll double-check as soon as I have some available cpu cycles, but it does not look like matchbox-terminal does that, IIRC it ships its own terminfo too14:23
*** Konsgnx <Konsgnx!> has joined #yocto14:24
*** dakhouya <dakhouya!> has joined #yocto14:47
*** yann <yann!> has quit IRC14:51
*** stbenz61 <stbenz61!> has quit IRC14:57
*** dakhouya <dakhouya!> has quit IRC14:58
*** stbenz615 <stbenz615!> has joined #yocto14:58
armpitRP, are we seeing icu-native build issues on CentOS7 worker?14:59
* armpit should log a bug14:59
* armpit should check bugs15:00
RParmpit: not that I've seen15:01
RParmpit: as its maintainer you need to learn dhcpcd != dhcpd ;-)15:02
RParmpit: I have however tracked down the issues and merged it15:02
*** sakoman <sakoman!> has quit IRC15:03
*** sakoman <sakoman!> has joined #yocto15:03
armpitwell letters are expensive on the global market15:04
*** dakhouya <dakhouya!> has joined #yocto15:04
dakhouyaHi, is there someone here that is working on building networkmanager 1.26.X?15:05
RParmpit: there is a shortage of c's atm? :)15:06
*** awe00__ <awe00__!~awe00@unaffiliated/awe00> has quit IRC15:07
*** feddischson <feddischson!> has quit IRC15:12
LetoThe2ndRP: ever since xmodem support in bootloaders, AFAIK15:12
fraylol I have.. :)15:12
fraylol I have -used- xmodem support in bootloaders.. my brain is so scattered today15:13
* LetoThe2nd hands fray a beer.15:13
frayhonestly it might help15:13
LetoThe2ndi know.15:13
* LetoThe2nd is dealing with recursive inotify, hence...15:16
*** awe00__ <awe00__!~awe00@unaffiliated/awe00> has joined #yocto15:20
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has quit IRC15:24
*** yann <yann!> has joined #yocto15:48
*** brett <brett!uid462863@gateway/web/> has joined #yocto15:49
*** brett is now known as megabread15:52
*** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/> has joined #yocto15:52
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC16:02
*** chris_ber <chris_ber!~quassel@> has quit IRC16:05
*** zandrey <zandrey!~zandrey@> has quit IRC16:05
smurrayRP: I noticed yesterday that core-image-full-cmdline doesn't pull in packagegroup-base-extended like core-image-minimal does, was/is there a reason for that?16:09
RPsmurray: I think minimal does special things as its "minimal" but I don't remember specifically16:09
smurrayRP: the result is less stuff in core-image-full-cmdline, and it misses a bunch of DISTRO_FEATURE driven things from packagegroup-base (which is what I noticed)16:11
kergothweird, you'd think full would be the opposite of minimal :)16:11
RPsmurray: it seems like it would be a reasonable fit for there16:11
RPI'd take a patch16:12
RPjonmason: I'm wondering what the concerns are for OE-Core and those tunes?16:12
smurrayRP: okay, it stems from core-image-full-cmdline defining IMAGE_INSTALL and losing the ?= definition in core-image.bbclass16:12
RPsmurray: looks partly deliberate as its adding packagegroup-core-boot16:13
RPsmurray: I'm not sure why we'd have done that :/16:14
*** fl0v0 <fl0v0!> has quit IRC16:14
smurrayRP: I suspect core-image-full-cmdline gets less use than minimal, maybe?16:14
frayprobably.. I use it, but I don't know many other peoople that do16:15
jonmasonRP: they should be fine, but I'm concerned that it's going to add too many files over time16:16
RPsmurray: it used to be called "core-image-basic" which would explain it16:16
RPjonmason: I am a little worried about the number of tunes, I don't know quite what to do about that :/16:16
smurrayRP: if you think there was a reason for it, I'm okay with it, just was a bit of a surprise since I figured it'd be a superset of minimal16:16
RPjonmason: equally, if we're going to add them, now before M3 builds would be the better time16:16
RPsmurray: The definition has changed. Lets just make it extend core-image.bbclass16:17
jonmasonI was thinking that we could add them into armv8a-2.inc16:17
RPjonmason: ok, that could make more sense16:17
frayevery time we add tune -files- vs just tune entries, it makes it hard to combine them.. since we usually end up with duplicate inclusions if we try to combine them16:17
fray(one odd place I DO use is combining tunes for a multilib toolchain)16:17
jonmasonWe should collapse the rest into their umbrellas but that would break backwards compatibility16:18
fraywe can always have files that simply have a single include/require in them for backwards compatibility16:18
fray(and then over time drop those files)16:19
jonmasonI'll do a patch for people to flame16:19
RPjonmason: we could just make people update I guess16:19
rburtonarmpit: given, can we drop the kea patch to remove AC_TRY_RUN?16:20
smurrayRP: I looked a bit in git history yesterday, not sure I went back far enough to look at that commit16:20
rburtonarmpit: ah it was part of which is 1.7.8 onwards.  obviously our recipe is
smurrayRP: I'll send a change to the list later today16:22
RPsmurray: thanks16:26
*** pohly <pohly!> has quit IRC16:34
*** mckoan is now known as mckoan|away16:36
*** stbenz615 <stbenz615!> has quit IRC16:37
*** stbenz615 <stbenz615!> has joined #yocto16:39
*** leon-anavi <leon-anavi!~Leon@> has quit IRC16:41
*** vineela <vineela!~vtummala@> has joined #yocto16:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:50
*** rcoote <rcoote!> has quit IRC16:53
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC16:55
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:56
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:57
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:00
khemcore-image-full-cmdline is basically an effort to not use busybox which in embedded space is not a common thing17:17
khembut I guess busybox is a bad poster boy :)17:17
RPkhem: well, partly, it was more about trying to have the full commandline tools available instead of the limited ones17:18
*** dakhouya <dakhouya!> has quit IRC17:18
frayActually my experience is fewer people want busybox, and more want full command line tools17:18
frayand size really wasn't an issue.. saving 1 MB didn't matter17:19
khemnot really, unless you are ok to use GPL-317:19
fray5G radio/base/etc are fine to use GPL-3.. no problems at all, and they'd much rather have full usable tools17:20
fraythe few instances (not 5G) I saw it, older versions of the tools were fine17:20
khemfray: you should do a survey :)17:21
khemI think you will find interesting things17:21
frayI can only speak of the customers I worked with and the requirements I've been given..17:21
frayones I worked with didn't care at all about GPL-3, since it was the carriers that were their customers, and they got the sources for the OS anyway17:21
khemnot many of consumer devices would be using such setups17:24
frayI still that that is industry specific.. lots of telco/networking  stuff I've used recently has GPLv3 software in it..17:25
fraythey just don't put THEIR applications linking to it..17:25
*** dakhouya <dakhouya!> has joined #yocto17:28
smurrayseems to come down to the legal dept's thinking, the last big telco I did stuff for had folks that not only didn't want GPLv3, but had also decided the library exception for libstdc++ wasn't good enough for them...17:29
*** zeddiii is now known as zeddii17:29
smurrayI doubt they have all their massive codebase working with clang even now, though17:30
khemyes clang + libc++ + compiler-rt is viable now a days with OE17:33
frayBTW I'm going to go live on twitch - mgFray -- going to work on some toolchain rebase work for microblaze.. figured I'd do this as an experiment.17:34
smurraykhem: heh, getting meta-clang integrated wasn't the hard part, they had/have many MLOC of old C++ code17:35
smurraykhem: thankfully that part wasn't my problem, and the contract ended shortly afterwards17:36
smurrayfray: I popped on, but was just about to step out for a grocery run17:39
frayno problem.. ;)17:40
* paulg wonders where the rocky island in the background is from17:43
paulgand really, who uses "nano" ?17:44
* paulg runs17:44
*** frsc <frsc!> has quit IRC17:47
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC17:49
*** bsmerbeck <bsmerbeck!> has joined #yocto18:06
*** Piraty <Piraty!~irc@unaffiliated/piraty> has quit IRC18:07
*** Piraty <Piraty!~irc@unaffiliated/piraty> has joined #yocto18:08
bsmerbeckStill stuck on this recipe's dependency errors.... errors are `nothing provides` for `/bin/env/` `` and ``. Thought including `glibc` would solve at least the libc error but it provides and not the .6. I know it's probably a trivial problem so I'm sorry for bothering to ask for help, I just figured I might not18:09
bsmerbeckspend a week or two banging my head against my desk if I asked for help. Image is for a jetson nano dev kit, builds perfectly when I exclude the recipe. It's simply a recipe to take a node application (already gathered all the npm resources) as an archive, unpack it, and place it in a directory on rootfs. Any help would be appreciated18:09
kergothsounds like you have all sorts of stuff in DEPENDS that doesn't belong there18:10
kergothi doubt anyone cann help without mor einformation18:10
bsmerbeckWould be happy to provide more information18:11
frayRP I think I found a bug in master..  if you have an invalid (typo) a layer patch in bblayers, it provides a most unhelpful error emssage/backttrace18:18
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:19
bsmerbeckd'oh, someone sent me a version of the project built for a different architecture. Gonna try something out18:20
*** camus1 <camus1!~Instantbi@> has joined #yocto18:32
*** kaspter <kaspter!~Instantbi@> has quit IRC18:33
*** camus1 is now known as kaspter18:33
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC18:47
kergothRP: oe-core dunfell version indicates BB_MIN_VERSION is 1.43.2, but the npm changes were merged that require bitbake 1.46. you can't do a recipetool newappend on dunfell with bitbake 1.43 or 1.44 right now, afaict19:03
kergothHmm, wonder if it's be worth adding SDK_CLASSES. IMAGE_CLASSES alone isn't ideal for classes that adjust sdk postprocessing since it wouldn't apply to standalone sdks like meta-toolchain19:08
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC19:21
*** anonzadas <anonzadas!> has quit IRC19:24
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto19:30
*** vineela <vineela!~vtummala@> has quit IRC19:33
*** feddischson <feddischson!> has joined #yocto19:38
RPkergoth: ah, thanks for reporting. sakoman ^^^19:42
RPfray: master from yesterday or now? That should have just been fixed19:43
sakomanRP: wow, that bug has probably been there for ages!19:45
sakomanI'll submit a patch with my next set19:46
RPsakoman: thanks19:46
RPsakoman: and sorry for ccing you on a 3.2 bug, I'm getting confused19:47
sakomanNot a problem!19:47
sakomankergoth: thanks for the bug report!19:47
*** vineela <vineela!~vtummala@> has joined #yocto19:48
RPkergoth: do you remember much about the parser threads and some of the issues we had?19:50
kergothnot in any detail, i'm sorry to say, it's been ages. i remember multiprocessing being a giant pain in the ass and having to deal with issues trying to ensure queues were flushed to avoid hanging19:51
RPkergoth: right, I remember that too. We have a hang reported which I just managed to reproduce19:51
*** bsmerbeck <bsmerbeck!> has quit IRC19:51
frayRP -- master-next from about an hour ago19:52
RPkergoth: if you put something like FOO := "${@d.getVar('MCMACHINES').split()[1]}" into meson.bbclass, then repeatedly run "bitbake bash -g" in a loop, it eventually hangs19:52
frayI can reproduce the isuee easily enough if you want19:52
RPfray: you have ?19:53
RPfray: if so please plastebin the trace and let me know how to reproduce :/19:53
frayyes, that commit is there19:53
fraysure.. let me create something for you19:53
RPfray: shame, it was meant to fix this kind of stuff19:53
RPah, I bet bitbake-layers uses different API19:53
RPfray: I'm going to guess tinfoil needs the same fix19:54
*** dakhouya <dakhouya!> has quit IRC19:54
RPfray: thanks, that is useful. Its not tinfoil19:57
frayI figured this was an easy one to reproduce.. (maybe not fix)  but it'll be common if people typo things19:58
RPfray: where it says if exc and "BBHandledException" in exc: in server/, can you add in a in "SystemExit" in exc and see if that looks better?19:59
*** angery <angery!> has joined #yocto19:59
*** anonzadas <anonzadas!> has joined #yocto19:59
RPfray: siting here going "no" :)20:00
fraywhat line?  not sure I did it right20:01
frayI edited 37220:01
fray        if exc and "BBHandledException" in exc:20:01
fray            sys.exit(1)20:01
fray(nothing changed in the output from what I saw)20:02
RPfray: sorry, trying to login to twitch but not sure its working20:03
frayI saw your message there20:03
RPfray: right place but add an if exc and "SystemExit" in exc: \n raise bb.BBHandledException()20:04
fraysent even20:11
RPfray: thanks, I was thinking it wasn't working at first :)20:11
RPkergoth: Was able to get a python backtrace. Its sitting in  self.result_queue.get(timeout=0.25)20:11
RPkergoth: spot the obvious problem20:11
*** zandrey <zandrey!> has joined #yocto20:14
*** pohly <pohly!> has joined #yocto20:14
*** bsmerbeck <bsmerbeck!> has joined #yocto20:14
RPtimeout applies to the lock, not the read() call20:14
fraysee twitch can be useful.. ;)20:14
RPfray: :)20:15
bsmerbeckHey guys! Solved a lot of my errors and have only one left: `nothing provides /bin/env needed by`. Only thing is I've searched through the entire project and never see /bin/env called...just /usr/bin/env which should be there because i included `coreutils`. Thoughts?20:15
angeryIs anyone familiar with with-gnu-ld? I can't figure out specifics about how it affects gcc configuration. Docs didn't help me too much and I'm not sure where to look next.20:16
RPbsmerbeck: sounds like something is wanting /bin/env when it should be /usr/bin/env20:16
bsmerbeckRP: I'm looking but the text `/bin/env` never appears in the files.... only `/usr/bin/env`. Going a bit mad trying to find this entire node app to pass but that's the last thing ruining the build20:18
ndechi sakoman! I noticed that you have a linux-firmware upgrade in dunfell-next, any chance you can pull as well?20:19
sakomanndec: sure, will do20:21
*** alimon <alimon!alimon@gateway/shell/linaro/x-thrrocncoppwqzws> has joined #yocto20:22
sakomanndec: I'll need to wait till that patch hits master though20:25
ndecit is in master.20:26
RPbsmerbeck: has to be coming from a file somewhere...20:26
bsmerbeckI don't think I could search deeper for this dependency >.<  I ran a deep search of the entire project it's always referred to `#!/usr/bin/env`20:27
bsmerbeckRP: any shot I could get bitbake to let me know what the file is?20:28
sakomanndec: it is indeed :-)  Didn't fetch first!20:28
RPbsmerbeck: where is the error being shown?20:29
RPbsmerbeck: this is is a recipe? Have you tried grepping the WORKDIR of that recipe for the reference?20:30
bsmerbeckRP: during `do_rootfs`, It's placing an entire node application so there's a ton to look through, let me give the grep a try and see what pops up20:31
RPbsmerbeck: you could also try a grep of the pkgdata directory for the expression20:32
*** feddischson <feddischson!> has quit IRC20:34
bsmerbeckRP: looking now....seems to be the logs and then the rpm it's making itself. Gonna peak at it now20:35
RPkergoth: in the cooker parser code, does the self.results.cancel_join_thread() look odd to you? Should all the parsers really be calling that?20:36
bsmerbeckRP: obviously reading the compiled .rpm isn't the best but there's a chunk: `/bin/bash^@/bin/env^@/bin/sh^@/usr/bin/env^@/usr/bin/perl^@rpmlib(CompressedFileNames)^@rpmlib(FileDigests)^` so it's definitely popping up somewhere20:37
RPbsmerbeck: right, that means that rpmdeps probably thinks something in the rpm uses /bin/env20:37
frayyou can look at the rpm contents in two ways.. rpm -qp <package> <options>  or <rpm> | cpio -id20:37
frayyup, what RP said20:38
bsmerbeckSo I should give fray's command a shot and try to find out more i'm guessing20:38
frayyou won't get anything further from rpm.. you have the right info..20:38
fraywhat you need to do is find the recipe (work dir) for that package/recipe.. and simply look in the package-splits/<package> directory.. and the top of each file in there..20:39
bsmerbeckalright, i'll try package-splits again....i'm amazed it's so hidden20:39
bsmerbeckaaaand grep is gonna hate me...given how many files have /usr/bin/env20:44
JaMamoto-timo: ping
bsmerbeckthink i found it20:47
*** jaremekgg <jaremekgg!~jarek@> has joined #yocto20:47
*** jaremekgg <jaremekgg!~jarek@> has quit IRC20:47
RPkergoth: it is probably right, I'm getting confused :(20:54
kanavin_homerburton: why, what is the context for it?21:02
rburtonkanavin_home: not sure what youre asking sorry21:02
kanavin_homerburton: (15.13.25) rburton: kanavin_home: can you do me a favour and verify that eg atk builds correctly with gtk-doc enabled?21:03
rburtonoh right21:03
rburtondon't worry, i broke it ;)21:03
bsmerbeckRP: found the culprit. Dependency of a dependency of a dependency of a package. Don't even use it but it's included in the whole thing. `#!/bin/env` right there at the top. Looks like this recipe is getting a `sed -i` added to it hahaha. Thanks! also thanks fray for the headsup21:04
RPkanavin_home: thinking we should get the remainder of the recipe upgrades into -next and tested...21:06
RPkanavin_home: its looking like the only remaining bit for M321:06
*** Konsgnx <Konsgnx!> has quit IRC21:06
kanavin_homeRP: I can rebase and send them now if you want, it's slightly challenging because I'm back from a few beers with colleagues (first time I've seen them since mid-March!)21:07
*** pohly <pohly!> has quit IRC21:07
RPkanavin_home: no problem, it can wait :)21:11
kanavin_homeRP: I rebased them (correctly, I hope) and sent them :) I ran them through the AB previously, but if there are any new failures, that will have to wait for me being sober :)21:15
RPkanavin_home: thanks. I'll let them run overnight21:17
RPfray: I think some of this bitbake cooker code is stupid and should not be doing sys.exit(1)21:17
*** pbb <pbb!~quassel@2a0f:4ac0::7> has quit IRC21:32
*** pbb <pbb!~quassel@2a0f:4ac0::7> has joined #yocto21:33
smurrayRP: so on a closer look, it turns out, I'm incorrect.  core-image-minimal sets IMAGE_INSTALL, so it also does not get packagegroup-base-extended, just packagegroup-core-boot, so that part's the same between minimal and full-cmdline21:35
zeddiiI remember the one time I was wrong. worst day grade 6.21:37
smurrayRP: some of the other core-image users in oe-core don't set IMAGE_INSTALL, so they'll get it.  It's not clear if we care about the consistency or not21:38
RPsmurray: I think its probably fine to adjust it FWIW21:39
smurrayRP: okay, I'm doing some test builds now to make sure I'm not missing something21:39
*** diego_r <diego_r!> has quit IRC21:40
*** diego_r <diego_r!> has joined #yocto21:40
khemsmurray: core-image-base might be more interesting if you need packagegroup-base-extended21:48
smurraykhem: yeah, I noticed that.  tbh, I'm okay with not changing anything, just was surprising to not get the DISTRO_FEATURE driven stuff from packagegroup-base when I built core-image-full-cmdline21:49
*** diego_r <diego_r!> has quit IRC21:50
khemI dont know if intent of core-image-full-cmdline  is core-image-minimal minus busybox if so then I think it should be left alone21:50
frayoriginal point was yes21:50
frayI would love it if there was a way to actually configure core-image-minimal to be busybox (or not).. and then if you wanted both, the core-image-full-cmdline would just inherit core-image-minimal and set the option21:51
khemname is confusing, it perhaps should have been called core-image-minimal-nobusybox or somesuch21:51
khem'full' in name makes is opposite of 'minimal'21:52
khemand hence confusion21:52
*** maudat <maudat!> has quit IRC21:55
*** dmoseley <dmoseley!~dmoseley@> has quit IRC21:59
*** otavio_ <otavio_!> has quit IRC21:59
*** droman <droman!> has quit IRC21:59
*** Chaser <Chaser!> has quit IRC21:59
*** Gottox <Gottox!> has quit IRC21:59
*** stkw0 <stkw0!> has joined #yocto22:00
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto22:00
*** Gottox <Gottox!> has joined #yocto22:00
*** otavio_ <otavio_!> has joined #yocto22:00
*** Chaser <Chaser!> has joined #yocto22:01
smurrayI think there's maybe something needed wrt documentation, a bunch of the DISTRO_FEATURES to drive things basically get ignored for the commonly mentioned core-image-* due to packagegroup-base not being picked up22:02
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC22:02
*** awafaa <awafaa!sid716@gateway/web/> has joined #yocto22:03
*** diego_r <diego_r!> has joined #yocto22:04
*** ilkappe <ilkappe!c65a42b1@> has quit IRC22:08
frayya.. but I can also see clear needs for a busybox and non-busybox filesystem in the same 'distro'.  (busybox initramfs, non-busybox rootfs)22:09
fraybut multiconfig could sway that twoard distro controlled.. but I'm not sure that overhead is a good idea22:09
smurrayslight wrinkle atm is core-image-full-cmdline ends up with busybox for a couple of things unless you tinker in local.conf to set some VIRTUAL-RUNTIME variables22:10
*** vineela <vineela!~vtummala@> has quit IRC22:10
*** beneth <beneth!> has left #yocto22:10
RPfull-cmdline isn't defined to be busybox free22:11
frayAhh then I'm confused, I thought it was22:13
*** vineela <vineela!vtummala@nat/intel/x-gzbfpddbvmaoignc> has joined #yocto22:18
*** yann <yann!> has quit IRC22:22
khemRP: so perhaps full-cmdline should inherit from core-image-base22:23
*** diego_r <diego_r!> has quit IRC22:27
*** diego_r <diego_r!> has joined #yocto22:28
smurrayso the change makes full-cmdline 20-25% bigger, that might be a mark against it since it might catch existing users by surprise22:29
RPsmurray: that's a surprisingly large differnce22:30
frayhonestly this is one of the problems I faced at WR.. (and now at Xilinx) there is no 'right' image...22:30
frayonly starting points.....22:30
RPAt the end of the day, core-image-* are examples22:30
frayhard to remind people of that22:31
fraylots of people keep saying I need to add things cause it's _THE_ image22:31
smurrayRP: roughly 103M vs 84M.  Lots of stuff is in DISTRO_FEATURES by default22:31
smurrayRP: I'm feeling I should just back away slowly ;)22:31
frayya.. I really wish opengl, x11, etc wasn't... but again "my use-case"....22:32
smurrayprobably a good conference talk ;)22:33
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC22:34
*** agust <agust!> has quit IRC22:35
*** nerdboy <nerdboy!~sarnold@> has joined #yocto22:35
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto22:36
smurrayfray: AGL has a bunch of options between its layer structure and setup script to try to avoid just ending up with a kitchen-sink image, but there's been some comments recently that there's too many options...22:36
smurrayfray: so one can indeed not win ;)22:36
*** bsmerbeck <bsmerbeck!> has quit IRC22:40
khemusually its a bad idea to use any of core-image-* I usually suggest to inherit core-image and go from there22:40
RPsmurray: This may be why its configured that way22:42
RPsmurray: do you have the two package manifests to diff out of interest?22:43
fraysmurray everyone wants their use-case or a demo.. nobody wants to customize cause it's too complicated22:43
khemRP: I  see that you merged the patch to  QA warning I have a patch which does not require that22:43
RPkhem: rburton convinced me that was the correct one rather than patching the code although I see there is now more discussion and you don't agree22:44
RPkhem: I know I don't like maintaining a patch indefinitely22:45
smurrayRP: here's the diff, nodistro + qemux86-64
khemRP: since its only a testcase perhaps its ok to ignore this but I am not sure if it will work on arches where gnu_hash matters22:46
RPsmurray: roughly speaking, sound, wifi and bluez22:47
RPof which wifi is probably most useful in a cmdline image22:47
smurrayRP: yeah, and a few bits I recognize as being due to 3g22:48
RPsmurray: right, comms bits22:48
*** mmorton <mmorton!> has joined #yocto22:49
RPsmurray: its a tough one. Tempted to say we should add it but there is no right answer22:49
smurrayRP: yeah22:50
*** mmorton <mmorton!> has quit IRC22:51
smurrayRP: I'd say something to mull over on the long weekend, but a quick check shows it was this past weekend in the UK ;)22:52
zeddiithere is only one true long weekend!22:52
zeddiithe one that I'm about to get.22:52
zeddiieverything else, is not valid.22:53
RPsmurray: yes, wish I was still away on the weekend ;-)22:53
smurrayheh, I have a 2 am conf call tonight, I'm starting the weekend on Friday22:53
khemRP: I think we configure internal toolchain too losely, perhaps thinks like hardfp on  arm and hash_style should just be configured into toolchain22:55
khemand same for pie/pic22:55
RPkhem: perhaps, yes22:55
khemI feel we stunt internal toolchain to accomodate external toolchains a bit too much22:55
RPkhem: we also do allow recipe overrides for pie/pic22:56
khemyeah they can be reversed22:56
khemif toolchain defaulted to say PIE22:56
khemwhile we do find lot of bugs in applications who are not using flags correctly in their makefiles its unnessary work22:58
khemsince usual argument is, it works ok on fedora/debian/ubuntu22:59
khemRP: I will need for meta-networking ptest image to work23:03
RPkhem: ok. I'm a bit worried the whole system is turning into a mass of symlinks :/23:04
khemfor elfutils, I think we should drop patching it, and live with INSANE_SKIP23:04
khemthis is last one23:05
khemnow most of meta-openembedded layers can build full images23:05
khemI am trying to bump up testing them a bit23:05
RPkhem: its queued locally for the next build (will be tomorrow now)23:07
* armpit khem bump it up. senses a sound coming on23:11
*** lh__ <lh__!sid77898@gateway/web/> has quit IRC23:12
*** lh__ <lh__!sid77898@gateway/web/> has joined #yocto23:12
*** NiksDev <NiksDev!~NiksDev@> has quit IRC23:20
khemI am seeing this
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto23:20
khemI wonder if something in core changed, that recipe is not changed23:21
khemx86_64-poky-linux-g++: error: unrecognized command-line option '-R'23:21
khemx86_64-poky-linux-g++: error: unrecognized command-line option '-R'23:21
*** goliath <goliath!> has quit IRC23:31

Generated by 2.17.2 by Marius Gedminas - find it at!