| *** dev1990 <dev1990!~dev@dynamic-62-87-247-41.ssp.dialog.net.pl> has quit IRC | 00:00 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC | 00:02 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto | 00:02 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has quit IRC | 00:03 | |
| *** radsquirrel <radsquirrel!~radsquirr@mail.fuzziesquirrel.com> has joined #yocto | 00:03 | |
| *** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 00:11 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 00:11 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:13 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 01:09 | |
| *** rcw <rcw!~rcw@45.72.241.84> has quit IRC | 01:28 | |
| *** TheComet_ <TheComet_!~hpom0@193.72.56.76> has quit IRC | 01:31 | |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC | 01:39 | |
| *** elvispre <elvispre!~elvispre@ftp.och.me.uk> has joined #yocto | 01:40 | |
| alejandrohs | khem: thanks! | 01:49 |
|---|---|---|
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has quit IRC | 02:08 | |
| *** hpsy1 <hpsy1!~hpsy@92.118.12.38> has joined #yocto | 02:08 | |
| *** hpsy <hpsy!~hpsy@92.118.12.38> has quit IRC | 02:08 | |
| *** PaowZ__ <PaowZ__!~Vince@193.252.149.222> has joined #yocto | 02:16 | |
| *** PaowZ <PaowZ!~Vince@193.252.149.222> has quit IRC | 02:18 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 02:26 | |
| *** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has joined #yocto | 02:27 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 02:29 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 02:30 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has quit IRC | 02:31 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 02:33 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-sietzmmchqkfpaex> has quit IRC | 03:09 | |
| *** sk48 <sk48!4815c441@72-21-196-65.amazon.com> has joined #yocto | 03:24 | |
| sk48 | Hello 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!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 03:31 | |
| *** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has joined #yocto | 03:33 | |
| *** sk48 <sk48!4815c441@72-21-196-65.amazon.com> has quit IRC | 03:51 | |
| *** rr123 <rr123!~xxiao@159.89.184.51> has joined #yocto | 04:18 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-131.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 04:29 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 05:41 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:49 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 05:53 | |
| *** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-nnqpkgujjiemxdly> has quit IRC | 06:00 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:01 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 06:02 | |
| *** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-strtxaetuqyugbqb> has joined #yocto | 06:03 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:08 | |
| ThomasD13 | Hi, is someone here who works with "arago" (linux sdk from texas instruments, similar to yocto, based on openembedded) ? | 06:12 |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 06:14 | |
| khem | ThomasD13: denix is working on arago | 06:20 |
| ThomasD13 | khem, thank you very much - I'll try to contact him | 06:21 |
| khem | he is in US Eastern time, so he must be fast asleep now | 06:21 |
| *** frsc <frsc!~frsc@i6DFA8B4E.versanet.de> has joined #yocto | 06:31 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 06:33 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-kcnwsvzeqzzypstk> has joined #yocto | 06:40 | |
| *** mckoan|away is now known as mckoan | 06:42 | |
| LetoThe2nd | happy coffee ingestion time, dudes! | 06:44 |
| ThomasD13 | Good morning LetoThe2nd. Did you get ever in touch with arago? | 06:45 |
| LetoThe2nd | depends on your definition of "getting in touch" | 06:46 |
| ThomasD13 | I 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 environment | 06:48 |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 06:48 | |
| ThomasD13 | Or 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_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 06:50 | |
| LetoThe2nd | you probably do not have to "port" anything. arago is just their distro, AFAIK. | 06:50 |
| ThomasD13 | okay | 06:51 |
| LetoThe2nd | e.g., grab poky, disable the poky layers, add the arago layers, done. thats the way it should be meant to be | 06:51 |
| denix | "similar to yocto, based on openembedded" that needs to be remembered! | 06:52 |
| LetoThe2nd | if you look at this http://arago-project.org/git/projects/?p=oe-layersetup.git;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!~fvo@i5E86934B.versanet.de> has joined #yocto | 06:53 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 06:53 | |
| LetoThe2nd | its really just a stack of layers that is tested together to fill the needs of ti | 06:53 |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has joined #yocto | 06:54 | |
| ThomasD13 | Okay, sounds like a newbie as me could just try it out | 06:54 |
| LetoThe2nd | denix: 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!~nslu2-log@milla.nas-admin.org> has joined #yocto | 06:54 | |
| LetoThe2nd | ThomasD13: 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 |
| ThomasD13 | Thanks for your view LetoThe2nd | 06:56 |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has quit IRC | 06:56 | |
| denix | LetoThe2nd: 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 |
| LetoThe2nd | denix: hehe. well you know that, i know that. unfortunately to the public, yocto == poky | 06:57 |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 06:58 | |
| ThomasD13 | denix, 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 |
| ThomasD13 | But I'm not sure if there is maybe some more "black magic" added by TI | 06:59 |
| * LetoThe2nd ponders starting a "black magic matters" meme | 06:59 | |
| ThomasD13 | Oh no :D | 06:59 |
| denix | what black magic? it's all public... | 06:59 |
| ThomasD13 | yes... black magic in a wider sense. Some stuff which I didnt discover yet, but required that it works somehow in the end | 07:01 |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 07:01 | |
| *** nslu2-log_ is now known as nslu2-log | 07:02 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 07:06 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 07:09 | |
| *** nslu2-log_ is now known as nslu2-log | 07:09 | |
| denix | LetoThe2nd: 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@213.138.44.181> has joined #yocto | 07:12 | |
| *** hpsy1 <hpsy1!~hpsy@92.118.12.38> has quit IRC | 07:15 | |
| LetoThe2nd | denix: hi5 | 07:15 |
| *** hpsy <hpsy!~hpsy@92.118.12.38> has joined #yocto | 07:16 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 07:21 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 07:24 | |
| fbre | Hi! What is intended to be the smallest?: core-image-minimal-initramfs or core-image-tiny-initramfs | 07:25 |
| fbre | What is the logical difference or idea behind, respectively? | 07:25 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 07:27 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:28 | |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC | 07:28 | |
| LetoThe2nd | fbre: well by looking at it, one could guess that the tiny incarnation is 1) based on poky-tiny 2) x86 only | 07:30 |
| LetoThe2nd | OTOH, the tiny version seems to be a bit more fine tuned / advanced, the minimal version is more generic / bare bones | 07:31 |
| *** dev1990 <dev1990!~dev@dynamic-62-87-247-41.ssp.dialog.net.pl> has joined #yocto | 07:31 | |
| fbre | ah 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.bbappend | 07:33 |
| fbre | I just have to tweak its init-live.sh script a bit since we don't have pluggable rootfs media | 07:35 |
| *** diego_r <diego_r!~diego@mob-109-119-218-57.net.vodafone.it> has joined #yocto | 07:36 | |
| * denix -> zzz | 07:38 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:44 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:54 | |
| *** PaowZ <PaowZ!~Vince@193.252.149.222> has joined #yocto | 07:59 | |
| fbre | Urgs, there is no RT patch for the kernel for the yocto release "warrior" | 08:02 |
| *** PaowZ__ <PaowZ__!~Vince@193.252.149.222> has quit IRC | 08:02 | |
| fbre | Would be nice if such requirement becomes standard for yocto releases | 08:03 |
| LetoThe2nd | fbre: disagreed: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux?h=warrior | 08:06 |
| fbre | hmm, I took a look here: https://source.codeaurora.org/external/imx/imx-manifest/tree/?h=imx-linux-warrior and here https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.19/ | 08:08 |
| LetoThe2nd | fbre: do not blame yocto for whatever freescale/imx support yank out. | 08:10 |
| fbre | and here https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.19/older/ | 08:10 |
| fbre | ok, sorry. Then it's up to NXP | 08:10 |
| LetoThe2nd | fbre: 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 |
| LetoThe2nd | fbre: 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 |
| fbre | I 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 is | 08:18 |
| fbre | I thought all releases base on the same kernel versions and vendors just put its meta layer on it | 08:19 |
| LetoThe2nd | fbre: i see. in a nutshell: what we care about is on git.yoctopoject.org. 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 warrior | 08:21 |
| LetoThe2nd | and 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 #yocto | 08:21 | |
| LetoThe2nd | unless somebody pays up, i do absolutely not care about which kernels nxp ships. | 08:22 |
| fbre | Well, 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 #yocto | 08:29 | |
| fbre | Equal names for different things lead to such questions here ;-) | 08:29 |
| fbre | Your "warrior" is not NXP's "warrior", this is what I've learned now | 08:30 |
| fbre | Sorry, if this came offensive. I appreciate your help here very much | 08:31 |
| LetoThe2nd | no. 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 |
| LetoThe2nd | so 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 |
| LetoThe2nd | e.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 |
| fbre | I see. Thanx for explaining it! | 08:40 |
| *** awe00_ <awe00_!~awe00@unaffiliated/awe00> has joined #yocto | 08:42 | |
| fbre | I 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 :-D | 08:42 |
| fbre | s/overseen/missed | 08:42 |
| LetoThe2nd | nope. 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 IRC | 08:45 | |
| *** awe00__ <awe00__!~awe00@unaffiliated/awe00> has joined #yocto | 08:45 | |
| zandrey | fbre: 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 mainline | 08:46 |
| zandrey | fbre: 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 IRC | 08:48 | |
| zandrey | fbre: 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 |
| zandrey | in a meantime - NXP pick *another tag*, drop some more patches and release it under their next release | 08: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 |
| zandrey | this one also gets picked up, upmerged - and so the story goes. | 08:49 |
| RobertBerger | @fbre https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/ | 08:50 |
| zandrey | you 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 |
| LetoThe2nd | zandrey: all the more reasons to not go for the stuff that gets mangled into those codeaurora things, and use vanilla OE/Poky as the base | 08:52 |
| fbre | RobertBerger: 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 https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-[version] -m imx-[version].xml | 08:53 |
| RobertBerger | @fbre which chip? | 08:53 |
| fbre | RobertBerger: imx8 | 08:53 |
| zandrey | LetoThe2nd: true! the only poor people that would be left outside though - are those who needs graphics and multimedia from NXP | 08:53 |
| RobertBerger | @fbre you need graphics/multimedia and so on? | 08:53 |
| RobertBerger | @rber or just headless image? | 08:54 |
| RobertBerger | I write to myself ;) | 08:54 |
| LetoThe2nd | zandrey: then they have to either pay for somebody to fix the crap for them, or go bitching to nxp. | 08:54 |
| RobertBerger | We are back to the "crappy vendor" discussions. | 08:54 |
| fbre | @RobertBerger camera drivers and video4linux | 08:54 |
| LetoThe2nd | zandrey: 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 |
| LetoThe2nd | RobertBerger: did we ever get away from it? | 08:55 |
| RobertBerger | Hmm since you don't seem to need the "special NXP sauce" upstream might work. | 08:55 |
| zandrey | RobertBerger: this were fun times in Lyon... :) | 08:55 |
| LetoThe2nd | zandrey: 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 |
| RobertBerger | If end users don't demand anything better that's what you get. | 08:56 |
| RobertBerger | The problem is:"What is the alternative?" | 08:56 |
| LetoThe2nd | the 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 |
| RobertBerger | They should know by now that this is not the case. | 08:57 |
| * LetoThe2nd shurgs. | 08:57 | |
| RobertBerger | And the community does NOT fix it. It's the consultants who sell the same fix to multiple customers without - without upstreaming. | 08:58 |
| RobertBerger | Since upstreaming costs extra. | 08:58 |
| fbre | @zandrey: I get the repo according to the NXP docs from repo init -u https://source.codeaurora.org/external/imx/imx-manifest -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 a | 08:58 |
| fbre | specific layer. No real idea of the background | 08:58 |
| RobertBerger | Anyways back to @fbre. | 08:58 |
| RobertBerger | Actually if you really really really want to use the NXP stuff it works as advertised. | 08:59 |
| zandrey | LetoThe2nd: 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 back | 08:59 |
| RobertBerger | But why don't you try meta-freescale (to build the boot container for you) and some 5.8.x upstream kernel? | 08:59 |
| zandrey | fbre: i posted the link the other day that you can use Yocto Quick Start Guide, and replace meta-altera in it to meta-freescale | 09:00 |
| RobertBerger | Linux version 5.8.5-custom-ml-virt (oe-user@oe-host) (aarch64-resy-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Thu Aug 27 07:31:49 UTC 2020 | 09:00 |
| zandrey | that way you get "community" BSP, which (with some tweaks) gives you a dunfell OE-Core base + NXP kernel + graphics + MM | 09:01 |
| RobertBerger | What 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 |
| zandrey | RobertBerger: exactly! this is really for those folks on the sidewalk, which do require GPU+VPU+IPU stuff from NXP | 09: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: https://gitlab.com/meta-layers/meta-phyboard-polis-imx8mm-bsp/-/blob/master/recipes-kernel/linux/patch/5.8.x/patches/phyboard-polis-imx8mm/dts/0001-freescale-imx8mm-phyboard-polis-rdk.dts-dependencies.patch | 09:05 |
| fbre | zandrey: yes, you posted the other day (25/08) a link to https://github.com/Freescale/meta-freescale 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 link | 09:08 |
| zandrey | fbre: 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 |
| zandrey | i 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 |
| zandrey | this 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 together | 09:14 |
| * LetoThe2nd is off to some js wrangling | 09:14 | |
| fbre | zandrey: https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf 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 https://github.com/Freescale/meta-freescale ? But what about | 09:15 |
| fbre | meta-freescale-3rdparty and meta-freescale-distro and meta-fsl-bsp-release then, is it still a consistent system then? | 09:15 |
| zandrey | fbre: unless you do not use any vendor board (Variscite, Congatec, etc) - you do not need -3rdparty | 09:16 |
| zandrey | -distro you would need to have | 09:16 |
| zandrey | meta-fsl-bsp-release afaik contains manifests for repo tool which are not maintained (maybe...) so i would not pull it in | 09:17 |
| zandrey | which MACHINE do you have? | 09:17 |
| zandrey | imx8mmevk? | 09:17 |
| fbre | yes | 09:18 |
| fbre | RobertBerger: 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 |
| zandrey | in this case - it resides in meta-freescale, so you can even skip the -distro | 09:19 |
| RobertBerger | @fbre: Feel free to join | 09:19 |
| RobertBerger | @fbre: I also offer "private" training and consulting | 09:19 |
| zandrey | but if you say: i need graphics - then you should pull meta-freescale-distro in, because that one defines the graphics packages you require | 09:19 |
| zandrey | fbre: take an offer from RobertBerger - do a recap, he might (maybe) go for discount! :D returning customer... :D | 09:20 |
| RobertBerger | @zandrey: Or ask more, since he didn't understand the first attempt ;) | 09:21 |
| zandrey | RobertBerger: either way - it's your offer! :D | 09:22 |
| RobertBerger | Sure - if fbre want one he knows where to find me - he has my contact details. | 09:23 |
| fbre | Actually 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 |
| fbre | it 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 newer | 09:28 |
| fbre | versions 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 #yocto | 09:29 | |
| RP | khem, armpit: Found the bind build issue, its with mutlilib, will fix | 09:34 |
| fbre | Currently, I have managed it, based on sumo, to bitbake a kernel with bundled tiny-initrams which contains a hacked init-live.sh 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 effect | 09:34 |
| zandrey | fbre: 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 |
| zandrey | but - it's your way, you make a decision here | 09:36 |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 09:36 | |
| fbre | yes, 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 now | 09:37 |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 09:38 | |
| fbre | As you see, it's already not easy to find out how I can get something which is ready for the RT patch :-D | 09: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_!~nslu2-log@milla.nas-admin.org> has quit IRC | 09:42 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 09:45 | |
| *** saraf <saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has quit IRC | 09:47 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 09:47 | |
| fbre | RobertBerger: 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 for | 09:47 |
| fbre | that. I just know how to get yocto with chapter "A1. Quick Start" from https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf. | 09:47 |
| *** saraf <saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has joined #yocto | 09: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 that | 09: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: https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/ | 09:51 |
| fbre | It sounds very promising you have managed it to get a working source tree of the latest yocto for bitbaking it | 09:51 |
| fbre | on an imx8mm eval board | 09:51 |
| RobertBerger | @fbre: It tool me some time, but yes ;) | 09:51 |
| RobertBerger | took | 09:52 |
| 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 |
| RobertBerger | overlayfs - you mean for the flash, or for some container? | 09:53 |
| RobertBerger | What you need the overlayfs for? | 09:54 |
| fbre | RobertBerger: 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 working | 09:54 |
| RobertBerger | OK I see | 09:55 |
| RobertBerger | That's kernel only | 09:55 |
| fbre | Such overlayfs initialisation must be done before the rootfs is mounted because I have to chroot the root directory "/" to that mountpoint | 09:56 |
| RobertBerger | Well not sure about that one | 09:57 |
| fbre | This forces me to use an initial RAM filesystem with appropriate scripts which is bundled to the kernel .bin file | 09:57 |
| qschulz | fbre: 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 #yocto | 09:58 | |
| qschulz | (just chiming in without having read any of the messages before so please ignore if completely out of topic :) ) | 09:59 |
| fbre | The 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 IRC | 09:59 | |
| RobertBerger | @fbre: This is old, but might do what you want: https://github.com/cmhe/meta-readonly-rootfs-overlay | 10:00 |
| fbre | RobertBerger: 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 |
| fbre | RobertBerger: Can I email you for that? | 10:01 |
| zandrey | fbre: 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 channel | 10:01 |
| zandrey | unless the audience would not mind :) | 10:01 |
| RobertBerger | @fbre - sure | 10:01 |
| fbre | thanx | 10:02 |
| LetoThe2nd | i 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 |
| fbre | qschulz: 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 |
| zandrey | LetoThe2nd: cool, then let's move on :) | 10:05 |
| zandrey | fbre: no problem! NXP forums are actually lagging, as i guess people either get direct support or discuss issues over MLs | 10:06 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-rcpaonzagrtyxvho> has joined #yocto | 10:06 | |
| zandrey | fbre: you can also use meta-freescale@lists.yoctoproject.org for questions, the audience is a bit broader there i guess than on nxp forums | 10:07 |
| *** saraf <saraf!~a_saraf@2409:4042:87:56e7:202f:eaa6:3676:2bf5> has joined #yocto | 10:07 | |
| RobertBerger | @fbre - you're welcome | 10:11 |
| *** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:f844:9310:1dc3:28ee> has quit IRC | 10:11 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 10:18 | |
| *** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has joined #yocto | 10:19 | |
| *** saraf <saraf!~a_saraf@2409:4042:87:56e7:202f:eaa6:3676:2bf5> has quit IRC | 10:19 | |
| *** saraf <saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has joined #yocto | 10:23 | |
| *** a_saraf <a_saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has quit IRC | 10:24 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 10:26 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 10:27 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 10:27 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 10:30 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 10:34 | |
| *** saraf <saraf!~a_saraf@2409:4042:511:2508:e862:9ca9:5996:b3f5> has quit IRC | 10:40 | |
| *** PaowZ_ <PaowZ_!~vince@2a01:e35:2e3e:4ac0:2430:f533:346b:e471> has quit IRC | 10:47 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has joined #yocto | 10:51 | |
| *** mbulut <mbulut!~nameclash@ip1f110f91.dynamic.kabel-deutschland.de> has quit IRC | 10:57 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has joined #yocto | 10:59 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has quit IRC | 11:03 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 11:03 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has joined #yocto | 11:03 | |
| *** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto | 11:05 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 11:18 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:19 | |
| cengiz_io | hello 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 installed | 11:20 |
| cengiz_io | how can I disable lttng alltogether? | 11:20 |
| cengiz_io | I tried adding "lttng-uprobes" to my image but there's no such recipe. | 11:21 |
| cengiz_io | nor a kernel module | 11:21 |
| zandrey_ | getting back on the topic of discussing "vendor BSPs": there is a section 3 in https://www.yoctoproject.org/docs/what-i-wish-id-known/ 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 setup | 11: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 Yocto | 11: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 layers | 11:27 |
| zandrey_ | fbre: for the rest of https://www.yoctoproject.org/docs/what-i-wish-id-known/ - it is a pretty well-formed Q&A for those who jumps into Yocto Project | 11:28 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-kbstzzznwmevbxlx> has joined #yocto | 11:29 | |
| fbre | (y) thanx for the document. I'm reading it in parallel to my work here | 11:32 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 11:32 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 11:34 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 11:35 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 11:35 | |
| *** otavio <otavio!~otavio@181.220.78.182> has joined #yocto | 11:36 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 11:36 | |
| *** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:40 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 11:40 | |
| fbre | zandrey_: 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 sight | 11:41 |
| fbre | who 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!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 11:44 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 11: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 IRC | 11:46 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC | 11:48 | |
| fbre | zandrey_: Regarding https://github.com/Freescale/meta-freescale , is this stuff from poky or from NXP? | 11:50 |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 11:51 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 11:51 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 11:51 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto | 11:51 | |
| fbre | zandrey_: Regarding https://github.com/Freescale/meta-freescale , is this stuff from poky or from NXP? | 11:53 |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 11:54 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 11:57 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 11:57 | |
| *** zand__ <zand__!~zandrey@193.8.40.126> has joined #yocto | 11:57 | |
| *** berton <berton!~berton@181.220.78.182> has quit IRC | 11:58 | |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 12:00 | |
| mckoan | fbre: meta-freescale is a NXP layer | 12:04 |
| fbre | thanx | 12:04 |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 12:05 | |
| mckoan | and looks like zandrey_ did a lot of work on that! Thanks | 12:07 |
| *** zand__ <zand__!~zandrey@193.8.40.126> has quit IRC | 12:09 | |
| fbre | zandrey: You told me to use meta-freescale from github.com (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@193.8.40.126> has joined #yocto | 12:09 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 12:10 | |
| zandrey | fbre: there are 2 answers to your question - simple and complicated ones. ;) the simple one: this is neither of both! | 12:10 |
| zandrey | the 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 earlier | 12:11 |
| zandrey | and at the same time - it is not a pure NXP layer, as it is not maintained by NXP directly | 12:12 |
| zandrey | they do provide contributions to it, but it is not actively maintained by them. | 12:12 |
| *** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 12:13 | |
| zandrey | so 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 maintained | 12:13 |
| zandrey | and 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@145.253.222.69> has quit IRC | 12:16 | |
| *** RobertBerger <RobertBerger!~rber@ppp-2-86-237-227.home.otenet.gr> has quit IRC | 12:17 | |
| zandrey | so 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@128.90.148.161> has joined #yocto | 12:18 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 12:19 | |
| fbre | shit, I got disconnected lol | 12:20 |
| zandrey | fbre: 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.0 | 12:21 |
| zandrey | and all other layers you pull would not be in conflict with it ;) | 12:21 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 12:22 | |
| zandrey | btw, next in pipe for the master is NXP release 5.4.24-2.1.0 integration | 12:22 |
| *** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto | 12:22 | |
| fbre | ah, 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 manifest | 12:22 |
| zandrey | fbre: 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 |
| zandrey | i 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 |
| zandrey | it is a meta-imx which you can see on codeaurora | 12:26 |
| smurray | having jumped through hoops just yesterday to test something with meta-imx, I'd advise avoiding it if at humanly possible | 12:28 |
| smurray | err, at all humanly possible | 12:28 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-rcpaonzagrtyxvho> has quit IRC | 12:29 | |
| zandrey | smurray: totally agree! the only reason i mentioned it is: this is the *only* source of information i have on the upgrade of meta-freescale | 12:30 |
| zandrey | other than that - there is no chance to see what NXP published in their public "vendor BSP" | 12:30 |
| smurray | yep | 12:31 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:33 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 12:33 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 12:33 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 12:43 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 12:48 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 13:04 | |
| JPEW | RP: Did the reproduibility diff get correctly generated for that latest failure>? | 13:06 |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has joined #yocto | 13:10 | |
| *** paulg <paulg!~paulg@24-212-228-244.cable.teksavvy.com> has quit IRC | 13:11 | |
| ilkappe | hello 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) in | 13:13 |
| rburton | kanavin_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 work | 13:13 |
| ilkappe | $ ls /sys/module | 13:13 |
| RobertBerger | bit better docu | 13:13 |
| ilkappe | by the way I can't see the module in the list. P.S. the module is a builtin module | 13:14 |
| RP | JPEW: hmm, didn't check | 13:14 |
| RP | JPEW: yes, looks like it did :) | 13:15 |
| ilkappe | AFAIK 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 |
| RobertBerger | a .ko file on your rootfs/ | 13:22 |
| RobertBerger | ? | 13:22 |
| RobertBerger | @ilkappe: check in /lib/modules/$(uname -r) | 13:23 |
| ilkappe | RobertBerger I set CONFIG_XXX=y in the .conf file used for kernel compilation | 13:24 |
| RobertBerger | Ah OK it's statically linked with the kernel | 13:24 |
| *** paulg <paulg!~paulg@24-212-228-136.cable.teksavvy.com> has joined #yocto | 13:25 | |
| ilkappe | Also, I do not know why but the rootfs.tar.gz file do not have any /lib/modules/ | 13:25 |
| RobertBerger | I know ;) | 13:25 |
| ilkappe | that's a surprise | 13:25 |
| RobertBerger | I guess it's a small one like core-image-minimal | 13:25 |
| ilkappe | yas | 13:25 |
| RobertBerger | hehe ;) | 13:25 |
| RobertBerger | look into your machine config | 13:25 |
| ilkappe | you are the best and you know eh ? I noticed that is shipped in another .tar.gz by the way | 13:26 |
| ilkappe | modules_XXXX.tar.gx | 13:26 |
| RobertBerger | in you machine config do you see kernel-modules in MACHINE_EXTRA_RRECOMMENDS? | 13:27 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 13:27 | |
| ilkappe | RobertBerger I'm searching for it | 13:28 |
| RobertBerger | https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-MACHINE_EXTRA_RRECOMMENDS | 13:28 |
| ilkappe | but I bet its not | 13:28 |
| RobertBerger | Well even if it is it won't work | 13:28 |
| RobertBerger | This variable affects only images based on packagegroup-base, which does not include the core-image-minimal or core-image-full-cmdline images. | 13:28 |
| ilkappe | by the way after building the core-image-minima the modules_4.19--XXXX.tar.gz is created in the build/tmp/deploy/images | 13:28 |
| RobertBerger | So throw in MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-modules kernel-devicetree" and it is going to work | 13:29 |
| RobertBerger | yes of course, but it's not in the image | 13:29 |
| ilkappe | that .tar.gz has the /lib/modules folder and also the modules.builtin file | 13:29 |
| RobertBerger | unless you do the change I said | 13:29 |
| qschulz | RobertBerger: meh... i wouldn't put kernel-modules in an RDEPENDS but rather each kernel-module-something which is **actually** required by the machine | 13:30 |
| ilkappe | RobertBerger yep ! that it's now clear, thanks | 13:30 |
| ilkappe | RobertBerger 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 there | 13:31 |
| RobertBerger | @ilkappe it will be only there if you change the =y to an =m | 13:32 |
| ilkappe | RobertBerger, so now it is definitely clear to me | 13:32 |
| *** PaowZ <PaowZ!~Vince@193.252.149.222> has quit IRC | 13:32 | |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 13:32 | |
| ilkappe | there is not any way to list the statically linked modules of the kernel from the userspace ? | 13:33 |
| RobertBerger | @ilkappe | 13:34 |
| RobertBerger | Do you have IKCONFIG_PROC enabled? | 13:34 |
| RobertBerger | if so at least you will see in /proc/config.gz that it's enabled in the currently running kernel | 13:35 |
| ilkappe | it seems so | 13:36 |
| RobertBerger | But does it really need to be statically linked? | 13:36 |
| RobertBerger | can't it be =m? | 13:36 |
| ilkappe | Probably I can make it so | 13:36 |
| RobertBerger | I suggest you first see that you get all your .ko into you rootfs | 13:36 |
| smurray | RobertBerger: poky + meta-freescale does mostly work for most of the NXP boards | 13:37 |
| ilkappe | But I was curios to know it it was possible though | 13:37 |
| RobertBerger | and then you make it =m and load it | 13:37 |
| RobertBerger | @smurray - at least it seems to compile ;) | 13:37 |
| ilkappe | RobertBerger thanks man | 13:37 |
| smurray | RobertBerger: 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-B | 13:38 |
| RobertBerger | @ilkappe - you're welcome | 13:39 |
| RobertBerger | @smurray are we all fixing NXP stuff lately? | 13:39 |
| RobertBerger | Thank you NXP for your ***** **** so it never works as expected and we can all have lots of work. | 13:40 |
| smurray | RobertBerger: 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 permits | 13:41 |
| ilkappe | RobertBerger config.gz worked like a charme. | 13:41 |
| RobertBerger | You might also try cat /lib/modules/$(uname -r)/modules.builtin | 13:41 |
| LetoThe2nd | RobertBerger: cat abuser! | 13:42 |
| ilkappe | that one is a little odd | 13:42 |
| RobertBerger | @LetoThe2nd you mean you need anything else besides echo and cat? | 13:42 |
| ilkappe | if untar the generated modules-4.19_XXXX.tar.gz | 13:42 |
| ilkappe | and cat the modules.builtin | 13:43 |
| ilkappe | there is no sign of the driver | 13:43 |
| RobertBerger | With my trick from above they will be put into the rootfs | 13:43 |
| RobertBerger | The drivers should be signed if that's enabled | 13:43 |
| RobertBerger | No matter if you add them manually or not | 13:43 |
| RobertBerger | It's done in compile time | 13:44 |
| ilkappe | yes! I have understood that | 13:44 |
| ilkappe | but i do not understand whu the driver is not listed anyway in the tar file | 13:44 |
| RobertBerger | Let's see again | 13:44 |
| ilkappe | RobertBerger, I've thought that too | 13:44 |
| RobertBerger | in config.gz is it =y or =m? | 13:44 |
| ilkappe | but in /proc/config.gz I got the driver with =y | 13:45 |
| RobertBerger | so it's only in cat /lib/modules/$(uname -r)/modules.builtin | 13:45 |
| RobertBerger | and not in the modules tarball | 13:45 |
| ilkappe | but in the /lib/modules/.../module.builtin there is nor | 13:45 |
| RobertBerger | So it's totally missing ;) | 13:45 |
| RobertBerger | That's your problem ;) | 13:45 |
| ilkappe | doh | 13:45 |
| RobertBerger | If it's neither in cat /lib/modules/$(uname -r)/modules.builtin nor in the tarball it's not compiled ;) | 13:46 |
| RobertBerger | How did you set the =y? | 13:46 |
| RobertBerger | Manually? | 13:46 |
| ilkappe | KERNEL_defconfig variable file has the line CONFIG_MYDRIVER=y | 13:46 |
| RobertBerger | Wait | 13:46 |
| RobertBerger | so you made your own driver | 13:47 |
| RobertBerger | Did you add it also to kconfig? | 13:47 |
| RobertBerger | does it show up in menuconfig? | 13:47 |
| ilkappe | yes it shows up | 13:48 |
| RobertBerger | What does it do? | 13:48 |
| ilkappe | and I see that it is compiled because a .o is gnerated n its folder | 13:48 |
| RobertBerger | can you print something in init? | 13:48 |
| RobertBerger | and check dmesg if that's printed? | 13:48 |
| ilkappe | basically I got a custom kernel with a custom driver from a vendor | 13:48 |
| RobertBerger | As I said go back and make it =m | 13:48 |
| RobertBerger | Load it manually and see if that works | 13:49 |
| ilkappe | a built the kernel using theri congiuration file also | 13:49 |
| RobertBerger | if that's OK then make it =y | 13:49 |
| ilkappe | yes, that's what I thought | 13:49 |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has quit IRC | 13:50 | |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has joined #yocto | 13:50 | |
| ilkappe | RobertBerger, sorry I was disconnected. I'll try what you suggested me. | 13:51 |
| RobertBerger | Enjoy! | 13:52 |
| ilkappe | you know that uh ? | 13:52 |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 13:54 | |
| RobertBerger | ;_ | 13:54 |
| RobertBerger | :-D | 13:54 |
| *** sk48 <sk48!6bcc141e@107-204-20-30.lightspeed.rcsntx.sbcglobal.net> has joined #yocto | 14:02 | |
| *** sk48 <sk48!6bcc141e@107-204-20-30.lightspeed.rcsntx.sbcglobal.net> has quit IRC | 14:04 | |
| *** sk48 <sk48!6bcc141e@107-204-20-30.lightspeed.rcsntx.sbcglobal.net> has joined #yocto | 14:04 | |
| yann | I 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!6bcc141e@107-204-20-30.lightspeed.rcsntx.sbcglobal.net> has quit IRC | 14:10 | |
| rburton | yann: yes | 14:13 |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has joined #yocto | 14:15 | |
| yann | there 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 |
| rburton | why does it ship its own? | 14:15 |
| fray | in most cases I've worked on.. if the files conflict, I drop the replacement versions and stick with the system originals | 14:16 |
| yann | probably because it authoritatively knows how it behaves itself :) | 14:16 |
| fray | I've seen other programs ship with their own terminfo before.. I don't have a clue why | 14:16 |
| fray | when i diffed them, they were the same as the terminfo (current or slightly older version) | 14:16 |
| yann | and in fact, since ncurses-terminfo is not necessarily installed, it seems sane to let it ships its own | 14:17 |
| fray | from an OS integration standpoint, you set a dependency and make sure it's installed.. | 14:17 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:21 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 14:23 | |
| yann | i'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 too | 14:23 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 14:24 | |
| *** dakhouya <dakhouya!4a3bc5db@modemcable219.197-59-74.mc.videotron.ca> has joined #yocto | 14:47 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 14:51 | |
| *** stbenz61 <stbenz61!~stbenz@ipbcc0f8a6.dynamic.kabel-deutschland.de> has quit IRC | 14:57 | |
| *** dakhouya <dakhouya!4a3bc5db@modemcable219.197-59-74.mc.videotron.ca> has quit IRC | 14:58 | |
| *** stbenz615 <stbenz615!~stbenz@ipbcc0f8a6.dynamic.kabel-deutschland.de> has joined #yocto | 14:58 | |
| armpit | RP, are we seeing icu-native build issues on CentOS7 worker? | 14:59 |
| * armpit should log a bug | 14:59 | |
| * armpit should check bugs | 15:00 | |
| RP | armpit: not that I've seen | 15:01 |
| RP | armpit: as its maintainer you need to learn dhcpcd != dhcpd ;-) | 15:02 |
| RP | armpit: I have however tracked down the issues and merged it | 15:02 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 15:03 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 15:03 | |
| armpit | well letters are expensive on the global market | 15:04 |
| *** dakhouya <dakhouya!4a3bc5db@modemcable219.197-59-74.mc.videotron.ca> has joined #yocto | 15:04 | |
| dakhouya | Hi, is there someone here that is working on building networkmanager 1.26.X? | 15:05 |
| RP | armpit: there is a shortage of c's atm? :) | 15:06 |
| *** awe00__ <awe00__!~awe00@unaffiliated/awe00> has quit IRC | 15:07 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-131.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 15:12 | |
| LetoThe2nd | RP: ever since xmodem support in bootloaders, AFAIK | 15:12 |
| fray | lol I have.. :) | 15:12 |
| fray | lol I have -used- xmodem support in bootloaders.. my brain is so scattered today | 15:13 |
| * LetoThe2nd hands fray a beer. | 15:13 | |
| fray | honestly it might help | 15:13 |
| LetoThe2nd | i know. | 15:13 |
| * LetoThe2nd is dealing with recursive inotify, hence... | 15:16 | |
| *** awe00__ <awe00__!~awe00@unaffiliated/awe00> has joined #yocto | 15:20 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has quit IRC | 15:24 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 15:48 | |
| *** brett <brett!uid462863@gateway/web/irccloud.com/x-awdafwgvsjeokaoc> has joined #yocto | 15:49 | |
| *** brett is now known as megabread | 15:52 | |
| *** gsalazar <gsalazar!5e3dbd6b@gateway/web/cgi-irc/kiwiirc.com/ip.94.61.189.107> has joined #yocto | 15:52 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 16:02 | |
| *** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:05 | |
| *** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 16:05 | |
| smurray | RP: 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 |
| RP | smurray: I think minimal does special things as its "minimal" but I don't remember specifically | 16:09 |
| smurray | RP: 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 |
| kergoth | weird, you'd think full would be the opposite of minimal :) | 16:11 |
| RP | smurray: it seems like it would be a reasonable fit for there | 16:11 |
| RP | I'd take a patch | 16:12 |
| RP | jonmason: I'm wondering what the concerns are for OE-Core and those tunes? | 16:12 |
| smurray | RP: okay, it stems from core-image-full-cmdline defining IMAGE_INSTALL and losing the ?= definition in core-image.bbclass | 16:12 |
| RP | smurray: looks partly deliberate as its adding packagegroup-core-boot | 16:13 |
| RP | smurray: I'm not sure why we'd have done that :/ | 16:14 |
| *** fl0v0 <fl0v0!~fvo@i5E86934B.versanet.de> has quit IRC | 16:14 | |
| smurray | RP: I suspect core-image-full-cmdline gets less use than minimal, maybe? | 16:14 |
| fray | probably.. I use it, but I don't know many other peoople that do | 16:15 |
| jonmason | RP: they should be fine, but I'm concerned that it's going to add too many files over time | 16:16 |
| RP | smurray: it used to be called "core-image-basic" which would explain it | 16:16 |
| RP | jonmason: I am a little worried about the number of tunes, I don't know quite what to do about that :/ | 16:16 |
| smurray | RP: 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 minimal | 16:16 |
| RP | jonmason: equally, if we're going to add them, now before M3 builds would be the better time | 16:16 |
| RP | smurray: The definition has changed. Lets just make it extend core-image.bbclass | 16:17 |
| jonmason | I was thinking that we could add them into armv8a-2.inc | 16:17 |
| RP | jonmason: ok, that could make more sense | 16:17 |
| fray | every 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 them | 16:17 |
| fray | (one odd place I DO use is combining tunes for a multilib toolchain) | 16:17 |
| RP | smurray: http://git.yoctoproject.org/cgit.cgi/poky/commit?id=91c372f287732cdedbd7c1204c6ba5f34e5b93f6 | 16:18 |
| jonmason | We should collapse the rest into their umbrellas but that would break backwards compatibility | 16:18 |
| fray | we can always have files that simply have a single include/require in them for backwards compatibility | 16:18 |
| fray | (and then over time drop those files) | 16:19 |
| jonmason | I'll do a patch for people to flame | 16:19 |
| RP | jonmason: we could just make people update I guess | 16:19 |
| rburton | armpit: given https://gitlab.isc.org/isc-projects/kea/-/blob/master/configure.ac#L597, can we drop the kea patch to remove AC_TRY_RUN? | 16:20 |
| smurray | RP: I looked a bit in git history yesterday, not sure I went back far enough to look at that commit | 16:20 |
| rburton | armpit: ah it was part of https://gitlab.isc.org/isc-projects/kea/-/commit/87d2b693849cae13fc86fec4c8a27ff20ea9c0cd which is 1.7.8 onwards. obviously our recipe is 1.7.7. | 16:21 |
| smurray | RP: I'll send a change to the list later today | 16:22 |
| RP | smurray: thanks | 16:26 |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 16:34 | |
| *** mckoan is now known as mckoan|away | 16:36 | |
| *** stbenz615 <stbenz615!~stbenz@ipbcc0f8a6.dynamic.kabel-deutschland.de> has quit IRC | 16:37 | |
| *** stbenz615 <stbenz615!~stbenz@ipbcc0f8a6.dynamic.kabel-deutschland.de> has joined #yocto | 16:39 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 16:41 | |
| *** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto | 16:47 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 16:50 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 16:53 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 16:55 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 16:56 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:57 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 17:00 | |
| khem | core-image-full-cmdline is basically an effort to not use busybox which in embedded space is not a common thing | 17:17 |
| khem | but I guess busybox is a bad poster boy :) | 17:17 |
| RP | khem: well, partly, it was more about trying to have the full commandline tools available instead of the limited ones | 17:18 |
| *** dakhouya <dakhouya!4a3bc5db@modemcable219.197-59-74.mc.videotron.ca> has quit IRC | 17:18 | |
| fray | Actually my experience is fewer people want busybox, and more want full command line tools | 17:18 |
| fray | and size really wasn't an issue.. saving 1 MB didn't matter | 17:19 |
| khem | not really, unless you are ok to use GPL-3 | 17:19 |
| fray | 5G radio/base/etc are fine to use GPL-3.. no problems at all, and they'd much rather have full usable tools | 17:20 |
| fray | the few instances (not 5G) I saw it, older versions of the tools were fine | 17:20 |
| khem | fray: you should do a survey :) | 17:21 |
| khem | I think you will find interesting things | 17:21 |
| fray | I can only speak of the customers I worked with and the requirements I've been given.. | 17:21 |
| fray | ones 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 anyway | 17:21 |
| khem | not many of consumer devices would be using such setups | 17:24 |
| fray | I still that that is industry specific.. lots of telco/networking stuff I've used recently has GPLv3 software in it.. | 17:25 |
| fray | they just don't put THEIR applications linking to it.. | 17:25 |
| *** dakhouya <dakhouya!4a3bc5db@modemcable219.197-59-74.mc.videotron.ca> has joined #yocto | 17:28 | |
| smurray | seems 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 zeddii | 17:29 | |
| smurray | I doubt they have all their massive codebase working with clang even now, though | 17:30 |
| khem | yes clang + libc++ + compiler-rt is viable now a days with OE | 17:33 |
| fray | BTW 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 |
| fray | https://twitch.tv/mgFray | 17:35 |
| smurray | khem: heh, getting meta-clang integrated wasn't the hard part, they had/have many MLOC of old C++ code | 17:35 |
| smurray | khem: thankfully that part wasn't my problem, and the contract ended shortly afterwards | 17:36 |
| smurray | fray: I popped on, but was just about to step out for a grocery run | 17:39 |
| fray | no problem.. ;) | 17:40 |
| * paulg wonders where the rocky island in the background is from | 17:43 | |
| paulg | and really, who uses "nano" ? | 17:44 |
| * paulg runs | 17:44 | |
| smurray | heh | 17:44 |
| *** frsc <frsc!~frsc@i6DFA8B4E.versanet.de> has quit IRC | 17:47 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-kcnwsvzeqzzypstk> has quit IRC | 17:49 | |
| *** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has joined #yocto | 18:06 | |
| *** Piraty <Piraty!~irc@unaffiliated/piraty> has quit IRC | 18:07 | |
| *** Piraty <Piraty!~irc@unaffiliated/piraty> has joined #yocto | 18:08 | |
| bsmerbeck | Still stuck on this recipe's dependency errors.... errors are `nothing provides` for `/bin/env/` `ld-linux-x86-64.so.2` and `libc.so.6`. Thought including `glibc` would solve at least the libc error but it provides libc.so 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 not | 18:09 |
| bsmerbeck | spend 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 appreciated | 18:09 |
| kergoth | sounds like you have all sorts of stuff in DEPENDS that doesn't belong there | 18:10 |
| kergoth | i doubt anyone cann help without mor einformation | 18:10 |
| bsmerbeck | Would be happy to provide more information | 18:11 |
| fray | RP 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/backttrace | 18:18 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 18:19 | |
| bsmerbeck | d'oh, someone sent me a version of the project built for a different architecture. Gonna try something out | 18:20 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 18:32 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 18:33 | |
| *** camus1 is now known as kaspter | 18:33 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 18:47 | |
| kergoth | RP: 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, afaict | 19:03 |
| kergoth | Hmm, 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-toolchain | 19:08 |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 19:21 | |
| *** anonzadas <anonzadas!~anonzadas@ja.sefod.eu> has quit IRC | 19:24 | |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 19:30 | |
| *** vineela <vineela!~vtummala@134.134.137.73> has quit IRC | 19:33 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-131.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 19:38 | |
| RP | kergoth: ah, thanks for reporting. sakoman ^^^ | 19:42 |
| RP | fray: master from yesterday or now? That should have just been fixed | 19:43 |
| sakoman | RP: wow, that bug has probably been there for ages! | 19:45 |
| sakoman | I'll submit a patch with my next set | 19:46 |
| RP | sakoman: thanks | 19:46 |
| RP | sakoman: and sorry for ccing you on a 3.2 bug, I'm getting confused | 19:47 |
| sakoman | Not a problem! | 19:47 |
| sakoman | kergoth: thanks for the bug report! | 19:47 |
| kergoth | np | 19:48 |
| *** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto | 19:48 | |
| RP | kergoth: do you remember much about the parser threads and some of the issues we had? | 19:50 |
| kergoth | not 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 hanging | 19:51 |
| RP | kergoth: right, I remember that too. We have a hang reported which I just managed to reproduce | 19:51 |
| *** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has quit IRC | 19:51 | |
| fray | RP -- master-next from about an hour ago | 19:52 |
| RP | kergoth: 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 hangs | 19:52 |
| fray | I can reproduce the isuee easily enough if you want | 19:52 |
| RP | fray: you have http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a6709152e9788418e6c9431851437eb8ec4c6b46 ? | 19:53 |
| RP | fray: if so please plastebin the trace and let me know how to reproduce :/ | 19:53 |
| fray | yes, that commit is there | 19:53 |
| fray | sure.. let me create something for you | 19:53 |
| RP | fray: shame, it was meant to fix this kind of stuff | 19:53 |
| RP | ah, I bet bitbake-layers uses different API | 19:53 |
| RP | fray: I'm going to guess tinfoil needs the same fix | 19:54 |
| *** dakhouya <dakhouya!4a3bc5db@modemcable219.197-59-74.mc.videotron.ca> has quit IRC | 19:54 | |
| fray | https://pastebin.com/WQeCY5xU | 19:56 |
| RP | fray: thanks, that is useful. Its not tinfoil | 19:57 |
| fray | I figured this was an easy one to reproduce.. (maybe not fix) but it'll be common if people typo things | 19:58 |
| RP | fray: where it says if exc and "BBHandledException" in exc: in server/process.py, can you add in a in "SystemExit" in exc and see if that looks better? | 19:59 |
| *** angery <angery!~dave@d66-183-215-121.bchsia.telus.net> has joined #yocto | 19:59 | |
| *** anonzadas <anonzadas!~anonzadas@ja.sefod.eu> has joined #yocto | 19:59 | |
| RP | fray: siting here going "no" :) | 20:00 |
| fray | what line? not sure I did it right | 20:01 |
| fray | I edited 372 | 20: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 |
| RP | fray: sorry, trying to login to twitch but not sure its working | 20:03 |
| fray | I saw your message there | 20:03 |
| RP | fray: right place but add an if exc and "SystemExit" in exc: \n raise bb.BBHandledException() | 20:04 |
| fray | send! | 20:10 |
| fray | sent even | 20:11 |
| RP | fray: thanks, I was thinking it wasn't working at first :) | 20:11 |
| RP | kergoth: Was able to get a python backtrace. Its sitting in self.result_queue.get(timeout=0.25) | 20:11 |
| RP | kergoth: spot the obvious problem | 20:11 |
| *** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 20:14 | |
| *** pohly <pohly!~pohly@p54849295.dip0.t-ipconnect.de> has joined #yocto | 20:14 | |
| *** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has joined #yocto | 20:14 | |
| RP | timeout applies to the lock, not the read() call | 20:14 |
| fray | see twitch can be useful.. ;) | 20:14 |
| RP | fray: :) | 20:15 |
| bsmerbeck | Hey 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 |
| angery | Is 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 |
| RP | bsmerbeck: sounds like something is wanting /bin/env when it should be /usr/bin/env | 20:16 |
| bsmerbeck | RP: I'm looking but the text `/bin/env` never appears in the files.... only `/usr/bin/env`. Going a bit mad trying to find it...got this entire node app to pass but that's the last thing ruining the build | 20:18 |
| ndec | hi sakoman! I noticed that you have a linux-firmware upgrade in dunfell-next, any chance you can pull https://git.openembedded.org/openembedded-core/commit/?id=e20c1e07a807f66f028104d8491d974a36734192 as well? | 20:19 |
| sakoman | ndec: sure, will do | 20:21 |
| ndec | thanks! | 20:21 |
| *** alimon <alimon!alimon@gateway/shell/linaro/x-thrrocncoppwqzws> has joined #yocto | 20:22 | |
| sakoman | ndec: I'll need to wait till that patch hits master though | 20:25 |
| ndec | it is in master. | 20:26 |
| RP | bsmerbeck: has to be coming from a file somewhere... | 20:26 |
| bsmerbeck | I 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 |
| bsmerbeck | RP: any shot I could get bitbake to let me know what the file is? | 20:28 |
| sakoman | ndec: it is indeed :-) Didn't fetch first! | 20:28 |
| RP | bsmerbeck: where is the error being shown? | 20:29 |
| RP | bsmerbeck: this is is a recipe? Have you tried grepping the WORKDIR of that recipe for the reference? | 20:30 |
| bsmerbeck | RP: 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 up | 20:31 |
| RP | bsmerbeck: you could also try a grep of the pkgdata directory for the expression | 20:32 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-131.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 20:34 | |
| bsmerbeck | RP: looking now....seems to be the logs and then the rpm it's making itself. Gonna peak at it now | 20:35 |
| RP | kergoth: 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 |
| bsmerbeck | RP: 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 somewhere | 20:37 |
| RP | bsmerbeck: right, that means that rpmdeps probably thinks something in the rpm uses /bin/env | 20:37 |
| fray | you can look at the rpm contents in two ways.. rpm -qp <package> <options> or rpm2cpio.sh <rpm> | cpio -id | 20:37 |
| fray | yup, what RP said | 20:38 |
| bsmerbeck | So I should give fray's command a shot and try to find out more i'm guessing | 20:38 |
| fray | you won't get anything further from rpm.. you have the right info.. | 20:38 |
| fray | what 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 |
| bsmerbeck | alright, i'll try package-splits again....i'm amazed it's so hidden | 20:39 |
| bsmerbeck | aaaand grep is gonna hate me...given how many files have /usr/bin/env | 20:44 |
| JaMa | moto-timo: ping https://patchwork.openembedded.org/patch/175786/ | 20:46 |
| bsmerbeck | think i found it | 20:47 |
| *** jaremekgg <jaremekgg!~jarek@37.120.217.252> has joined #yocto | 20:47 | |
| bsmerbeck | woah | 20:47 |
| *** jaremekgg <jaremekgg!~jarek@37.120.217.252> has quit IRC | 20:47 | |
| RP | kergoth: it is probably right, I'm getting confused :( | 20:54 |
| kanavin_home | rburton: why, what is the context for it? | 21:02 |
| rburton | kanavin_home: not sure what youre asking sorry | 21:02 |
| kanavin_home | rburton: (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 |
| rburton | oh right | 21:03 |
| rburton | don't worry, i broke it ;) | 21:03 |
| bsmerbeck | RP: 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 headsup | 21:04 |
| RP | kanavin_home: thinking we should get the remainder of the recipe upgrades into -next and tested... | 21:06 |
| RP | kanavin_home: its looking like the only remaining bit for M3 | 21:06 |
| *** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:06 | |
| kanavin_home | RP: 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!~pohly@p54849295.dip0.t-ipconnect.de> has quit IRC | 21:07 | |
| RP | kanavin_home: no problem, it can wait :) | 21:11 |
| kanavin_home | RP: 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 |
| RP | kanavin_home: thanks. I'll let them run overnight | 21:17 |
| RP | fray: I think some of this bitbake cooker code is stupid and should not be doing sys.exit(1) | 21:17 |
| fray | lol | 21:17 |
| *** pbb <pbb!~quassel@2a0f:4ac0::7> has quit IRC | 21:32 | |
| *** pbb <pbb!~quassel@2a0f:4ac0::7> has joined #yocto | 21:33 | |
| smurray | RP: 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-cmdline | 21:35 |
| zeddii | I remember the one time I was wrong. worst day grade 6. | 21:37 |
| smurray | RP: 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 not | 21:38 |
| RP | smurray: I think its probably fine to adjust it FWIW | 21:39 |
| smurray | RP: okay, I'm doing some test builds now to make sure I'm not missing something | 21:39 |
| *** diego_r <diego_r!~diego@mob-109-119-218-57.net.vodafone.it> has quit IRC | 21:40 | |
| *** diego_r <diego_r!~diego@mob-176-247-201-118.net.vodafone.it> has joined #yocto | 21:40 | |
| khem | smurray: core-image-base might be more interesting if you need packagegroup-base-extended | 21:48 |
| smurray | khem: 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-cmdline | 21:49 |
| *** diego_r <diego_r!~diego@mob-176-247-201-118.net.vodafone.it> has quit IRC | 21:50 | |
| khem | I dont know if intent of core-image-full-cmdline is core-image-minimal minus busybox if so then I think it should be left alone | 21:50 |
| fray | original point was yes | 21:50 |
| fray | I 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 option | 21:51 |
| khem | name is confusing, it perhaps should have been called core-image-minimal-nobusybox or somesuch | 21:51 |
| khem | 'full' in name makes is opposite of 'minimal' | 21:52 |
| khem | and hence confusion | 21:52 |
| *** maudat <maudat!~moda@bras-vprn-mtrlpq2848w-lp130-10-174-92-198-55.dsl.bell.ca> has quit IRC | 21:55 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 21:59 | |
| *** otavio_ <otavio_!~otavio@static.203.17.243.136.clients.your-server.de> has quit IRC | 21:59 | |
| *** droman <droman!~quassel@ns3046126.ip-91-121-8.eu> has quit IRC | 21:59 | |
| *** Chaser <Chaser!~Chaser@ec2-13-233-34-134.ap-south-1.compute.amazonaws.com> has quit IRC | 21:59 | |
| *** Gottox <Gottox!~Gottox@vm3.s01.de> has quit IRC | 21:59 | |
| *** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has joined #yocto | 22:00 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 22:00 | |
| *** Gottox <Gottox!~Gottox@vm3.s01.de> has joined #yocto | 22:00 | |
| *** otavio_ <otavio_!~otavio@static.203.17.243.136.clients.your-server.de> has joined #yocto | 22:00 | |
| *** Chaser <Chaser!~Chaser@ec2-13-233-34-134.ap-south-1.compute.amazonaws.com> has joined #yocto | 22:01 | |
| smurray | I 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 up | 22:02 |
| *** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-strtxaetuqyugbqb> has quit IRC | 22:02 | |
| *** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-ramulghteiaigmih> has joined #yocto | 22:03 | |
| *** diego_r <diego_r!~diego@mob-176-247-201-118.net.vodafone.it> has joined #yocto | 22:04 | |
| *** ilkappe <ilkappe!c65a42b1@198.90.66.177> has quit IRC | 22:08 | |
| fray | ya.. 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 |
| fray | but multiconfig could sway that twoard distro controlled.. but I'm not sure that overhead is a good idea | 22:09 |
| smurray | slight 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 variables | 22:10 |
| *** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 22:10 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 22:10 | |
| RP | full-cmdline isn't defined to be busybox free | 22:11 |
| fray | Ahh then I'm confused, I thought it was | 22:13 |
| *** vineela <vineela!vtummala@nat/intel/x-gzbfpddbvmaoignc> has joined #yocto | 22:18 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 22:22 | |
| khem | RP: so perhaps full-cmdline should inherit from core-image-base | 22:23 |
| *** diego_r <diego_r!~diego@mob-176-247-201-118.net.vodafone.it> has quit IRC | 22:27 | |
| *** diego_r <diego_r!~diego@mob-176-247-160-75.net.vodafone.it> has joined #yocto | 22:28 | |
| smurray | so the change makes full-cmdline 20-25% bigger, that might be a mark against it since it might catch existing users by surprise | 22:29 |
| RP | smurray: that's a surprisingly large differnce | 22:30 |
| fray | honestly this is one of the problems I faced at WR.. (and now at Xilinx) there is no 'right' image... | 22:30 |
| fray | only starting points..... | 22:30 |
| RP | At the end of the day, core-image-* are examples | 22:30 |
| fray | yup | 22:30 |
| fray | hard to remind people of that | 22:31 |
| fray | lots of people keep saying I need to add things cause it's _THE_ image | 22:31 |
| smurray | RP: roughly 103M vs 84M. Lots of stuff is in DISTRO_FEATURES by default | 22:31 |
| smurray | RP: I'm feeling I should just back away slowly ;) | 22:31 |
| fray | ya.. I really wish opengl, x11, etc wasn't... but again "my use-case".... | 22:32 |
| smurray | right | 22:32 |
| smurray | probably a good conference talk ;) | 22:33 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 22:34 | |
| *** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:35 | |
| *** nerdboy <nerdboy!~sarnold@47.143.129.64> has joined #yocto | 22:35 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 22:36 | |
| smurray | fray: 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 |
| smurray | fray: so one can indeed not win ;) | 22:36 |
| *** bsmerbeck <bsmerbeck!4a6132e0@pool-74-97-50-224.prvdri.fios.verizon.net> has quit IRC | 22:40 | |
| khem | usually its a bad idea to use any of core-image-* I usually suggest to inherit core-image and go from there | 22:40 |
| RP | smurray: This may be why its configured that way | 22:42 |
| RP | smurray: do you have the two package manifests to diff out of interest? | 22:43 |
| fray | smurray everyone wants their use-case or a demo.. nobody wants to customize cause it's too complicated | 22:43 |
| khem | RP: I see that you merged the patch to QA warning I have a patch which does not require that | 22:43 |
| RP | khem: 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 agree | 22:44 |
| RP | khem: I know I don't like maintaining a patch indefinitely | 22:45 |
| smurray | RP: here's the diff, nodistro + qemux86-64 https://www.irccloud.com/pastebin/5ot2KQ1W/c-i-full-cmdline.diff | 22:45 |
| khem | RP: 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 matters | 22:46 |
| RP | smurray: roughly speaking, sound, wifi and bluez | 22:47 |
| RP | of which wifi is probably most useful in a cmdline image | 22:47 |
| smurray | RP: yeah, and a few bits I recognize as being due to 3g | 22:48 |
| RP | smurray: right, comms bits | 22:48 |
| *** mmorton <mmorton!930bfc2a@unknown-252-42.windriver.com> has joined #yocto | 22:49 | |
| RP | smurray: its a tough one. Tempted to say we should add it but there is no right answer | 22:49 |
| smurray | RP: yeah | 22:50 |
| *** mmorton <mmorton!930bfc2a@unknown-252-42.windriver.com> has quit IRC | 22:51 | |
| smurray | RP: 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 |
| zeddii | there is only one true long weekend! | 22:52 |
| zeddii | the one that I'm about to get. | 22:52 |
| zeddii | everything else, is not valid. | 22:53 |
| RP | smurray: yes, wish I was still away on the weekend ;-) | 22:53 |
| smurray | heh, I have a 2 am conf call tonight, I'm starting the weekend on Friday | 22:53 |
| khem | RP: I think we configure internal toolchain too losely, perhaps thinks like hardfp on arm and hash_style should just be configured into toolchain | 22:55 |
| khem | and same for pie/pic | 22:55 |
| RP | khem: perhaps, yes | 22:55 |
| khem | I feel we stunt internal toolchain to accomodate external toolchains a bit too much | 22:55 |
| RP | khem: we also do allow recipe overrides for pie/pic | 22:56 |
| khem | yeah they can be reversed | 22:56 |
| khem | if toolchain defaulted to say PIE | 22:56 |
| khem | while we do find lot of bugs in applications who are not using flags correctly in their makefiles its unnessary work | 22:58 |
| khem | since usual argument is, it works ok on fedora/debian/ubuntu | 22:59 |
| khem | RP: I will need https://patchwork.openembedded.org/patch/175889/ for meta-networking ptest image to work | 23:03 |
| RP | khem: ok. I'm a bit worried the whole system is turning into a mass of symlinks :/ | 23:04 |
| khem | for elfutils, I think we should drop patching it, and live with INSANE_SKIP | 23:04 |
| khem | this is last one | 23:05 |
| khem | now most of meta-openembedded layers can build full images | 23:05 |
| khem | I am trying to bump up testing them a bit | 23:05 |
| RP | khem: its queued locally for the next build (will be tomorrow now) | 23:07 |
| khem | np | 23:08 |
| * armpit khem bump it up. senses a sound coming on | 23:11 | |
| *** lh__ <lh__!sid77898@gateway/web/irccloud.com/x-hpzfcbqabcwbjqct> has quit IRC | 23:12 | |
| *** lh__ <lh__!sid77898@gateway/web/irccloud.com/x-uevokuebvmvdteth> has joined #yocto | 23:12 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has quit IRC | 23:20 | |
| khem | I am seeing this https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/566/steps/8/logs/step1b | 23:20 |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.32> has joined #yocto | 23:20 | |
| khem | I wonder if something in core changed, that recipe is not changed | 23:21 |
| khem | x86_64-poky-linux-g++: error: unrecognized command-line option '-R' | 23:21 |
| khem | x86_64-poky-linux-g++: error: unrecognized command-line option '-R' | 23:21 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:31 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!