seninha has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
amitk has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Oxbef has joined #yocto
<Oxbef>
Hello,
<Oxbef>
I had a quick question about the eSDK if anyone knows. I have a repo that contains layers and non-layer content. I need to have that non-layer content in my SDK because the recipes depend on it, but I don't see a built-in way to do that. (populate_sdk_ext just copies layers from what's in BBLAYERS variable). Is there a "nice" way to copy that
<Oxbef>
content into my SDK using something like TOOLCHAIN_TARGET_TASK or POPULATE_SDK_POST_TARGET_COMMAND or something along those lines?
<Oxbef>
Any help on this is appreciated, thanks
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
sakoman has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 268 seconds]
jmiehe1 is now known as jmiehe
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Skiper has quit [Ping timeout: 252 seconds]
Skiper has joined #yocto
sakoman has quit [Quit: Leaving.]
roussinm has quit [Quit: WeeChat 3.0]
stuom has joined #yocto
Skiper has quit [Read error: Connection reset by peer]
Skiper has joined #yocto
thomasd13 has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Estrella has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
manuel1985 has joined #yocto
florian_kc has joined #yocto
alessioigor has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
adams[1] has quit [Quit: Client closed]
rob_w has joined #yocto
zpfvo has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Skiper has quit [Read error: Connection reset by peer]
Skiper has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Guest82 has joined #yocto
<Guest82>
Hello all,
gsalazar has joined #yocto
<Guest82>
While trying to build u-boot-imx-2022.04 I'm running into a RAM limit on my machine (32G). I have tried setting BB_NUMBER_THREADS and PARALLEL_MAKE both to 2 and I do see in htop that this indeed seems to limit the CPU usage, but still if I only bitbake u-boot the RAM is running out. Would you know if I can change settings, or have to go out and
<Guest82>
get me some 64G worth of RAM?
ptsneves has joined #yocto
lexano has quit [Ping timeout: 240 seconds]
<Oxbef>
Guest82 You definitely don't need 64GB just to compile U-Boot... What's the error message you're getting, if any?
<Guest82>
Oxbef: meta-freescale/recipes-bsp/u-boot/u-boot-imx_2022.04.bb:do_compile) failed with exit code '137'
<Guest82>
I can also visually see the RAM filling up in htop during the build.
<Oxbef>
And you set BB_NUMBER_THREADS & PARALLEL_MAKE in your local.conf or elsewhere?
<Guest82>
in local.conf
<stuom>
you can always try to increase swap to see if it solves the problem, before upgrading physical RAM
<Oxbef>
Did you set it as BB_NUMBER_THREADS = 2
<Oxbef>
or
<Oxbef>
BB_NUMBER_THREADS = "2"
<Guest82>
BB_NUMBER_THREADS = "2"
<Guest82>
PARALLEL_MAKE = "-j 2"
lexano has joined #yocto
<Guest82>
stuom: Ok let me check that out. Currently it is set at 2G.
argonautx has joined #yocto
mvlad has joined #yocto
<qschulz>
Oxbef: this non-layer content, can't you make a recipe for it? is this non-layer content not under some software control mechanism like git/svn/whatever?
<Oxbef>
qschulz: Funny story... no my hands are sort of tied here. I ended up pulling some of it out (what I could) and making a recipe. For the rest, I have to get feedback from my team. They have a bunch of automation built around the repo structure that will break if I mess with it
dev1990 has joined #yocto
<Oxbef>
@qschulz: I'll just have to push that and move on. Ideally everything in a layer is stored in that layer or referenced in some source control by the recipe
Guest38 has joined #yocto
<qschulz>
ernstp: I like using kwargs for string.format function so it's a bit more explicit while reading the string what is going where
<qschulz>
i.e. 'cpe:2.3:a:{}:{}:{}:*:*:*:*:*:*:*'.format(vendor, product, version) could be 'cpe:2.3:a:{vendor}:{product}:{version}:*:*:*:*:*:*:*'.format(vendor=vendor, product=product, version=version)
<qschulz>
limits the possible mistakes when migrating away from f strings
<ernstp>
qschulz: the line just got so long, it didn't look pretty :-)
<qschulz>
ernstp: hehe
<LetoThe2nd>
yo dudX
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
leon-anavi has joined #yocto
mihai has joined #yocto
<Guest82>
stuom: Increased swap to 16G, could compile a couple of minutes longer with two cores but also filling up gradually and crashing. It does indeed feel like baking only u-boot should not need that much and something is out of whack.
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<Oxbef>
Guest82: Just a sanity check, but when you run "bitbake <image> -e" to get your environment, you see those variables set to what you expect, right? I'm at a loss
manuel1985 has joined #yocto
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
amitk has quit [Ping timeout: 252 seconds]
manuel_ has quit [Ping timeout: 268 seconds]
creich has joined #yocto
<Guest82>
Oxbef: Yes indeed those variables are set correctly checking with -e. I'm currently doing a clean build of the whole thing on 2 cores to see if there is a warning that I've missed. Might take a while since I'm used to 24 cores...
manuel_ has joined #yocto
olani has quit [Ping timeout: 252 seconds]
olani has joined #yocto
xmn has quit [Quit: ZZZzzz…]
nemik has quit [Ping timeout: 268 seconds]
pgowda_ has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
starblue has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
gsalazar_ has joined #yocto
gsalazar has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
florian has joined #yocto
GuestNew has joined #yocto
<GuestNew>
hi all, after migration to head of kirkstone branch the build is stuck on python3-wheel install with : python -m installer: error: unrecognized arguments: --interpreter /home/path/python3-wheel/0.37.1-r0/dist/wheel-0.37.1-py3-none-any.whl. ANy tips to solve that ?
SDes91 has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
GNUmoon2 has quit [Ping timeout: 268 seconds]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
seninha has joined #yocto
brazuca has quit [Quit: Client closed]
thomasd13 has quit [Ping timeout: 268 seconds]
GuestNew has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
Oxbef has quit [Quit: Client closed]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Oxbef has joined #yocto
stuom has quit [Quit: Client closed]
leon-anavi has quit [Quit: Leaving]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
SDes91 has quit [Quit: Client closed]
leon-anavi has joined #yocto
prabhakarlad has joined #yocto
Guest38 has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 264 seconds]
dtometzki has joined #yocto
SDes91 has joined #yocto
Guest82 has quit [Quit: Client closed]
SDes91 has left #yocto [#yocto]
<ernstp>
qschulz: I can't send a v2 right now though, git send-email doesn't work everywhere..
<qschulz>
ernstp: it was just a suggestion, v1 could be merged as is I guess
<ernstp>
qschulz: well see if anyone else has a strong opinion :-)
Oxbef has quit [Quit: Client closed]
Skiper has quit [Ping timeout: 268 seconds]
Skiper has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
xmn has joined #yocto
agupta1 has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus has joined #yocto
prabhakarlad has quit [Quit: Client closed]
agupta1 has quit [Ping timeout: 252 seconds]
agupta1 has joined #yocto
prabhakarlad has joined #yocto
roussinm has joined #yocto
<roussinm>
I remember seeing a tool to navigate the dependency graph with the terminal, and not a gui. It looked like the taskdep gui, but in the terminal. I tried ncurses, but it doesn't seems to work. It errors out weirdly.
<roussinm>
I can't seems to find it in bitbake, maybe it was an experiment that never merged?
Skiper has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
Skiper has joined #yocto
zpfvo has joined #yocto
<LetoThe2nd>
ssh k
ptsneves has quit [Quit: ptsneves]
<qschulz>
root@k password:
otavio has quit [Ping timeout: 268 seconds]
Skiper has quit [Read error: Connection reset by peer]
Skiper has joined #yocto
otavio has joined #yocto
florian has quit [Quit: Ex-Chat]
Skiper has quit [Ping timeout: 244 seconds]
Skiper has joined #yocto
davidinux has joined #yocto
Skiper has quit [Read error: Connection reset by peer]
Skiper has joined #yocto
vladest has joined #yocto
goliath has quit [Quit: SIGSEGV]
Oxbef has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
camus has quit [Quit: camus]
Oxbef has quit [Quit: Client closed]
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
GNUmoon2 has quit [Ping timeout: 268 seconds]
zpfvo has quit [Quit: Leaving.]
GNUmoon2 has joined #yocto
manuel_ has quit [Ping timeout: 268 seconds]
leon-anavi has quit [Quit: Leaving]
agupta1 has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
Harm has joined #yocto
<Harm>
Hey, I was wondering whether there are any guidelines about when to create a .patch file and when to just copy a raw file into the source tree. I currently have a BSP layer with a Linux .dts file which needs to be placed in the correct directory in the source.
chep` has joined #yocto
gsalazar_ has quit [Ping timeout: 268 seconds]
chep has quit [Ping timeout: 268 seconds]
chep` is now known as chep
<qschulz>
Harm: to compile it you probably will need to edit the Makefile of the directory where you'll put your dts no?
alicef_ has quit [Quit: install gentoo]
<Harm>
qschulz: no, I think Yocto does that with KERNEL_DEVICETREE?
alicef has joined #yocto
<qschulz>
Harm: have you tried? I see that it's calling make <dtb> for each specified KERNEL_DEVICETREE
agupta1 has joined #yocto
<qschulz>
but if you don't have the make target, it wont do anything?
<Harm>
qschulz: yeah, I have tried and it works. I did not try compiling by hand, only through Yocto
<Harm>
Anyway, that is not the point. I just wonder if there is any best practice here. On one hand I can see that creating a .patch to just add the file is easier with devtool, as it creates a commit and you can track changes with git locally. On the other hand, when the dts is a plain file it is easier to read outside a 'devtool modify ' environment
<qschulz>
Harm: It was part of the point, if you need a patch for the makefile, there's no point in keeping it outside since you already need a patch
roussinm has quit [Quit: WeeChat 3.0]
<qschulz>
Harm: in any case, I personally very much prefer to have things pertaining to the same project in the same git repo
<Harm>
Ah yeah
<qschulz>
so, your DTS for the kernel, in the kernel tree
<qschulz>
since it's also very likely the DTS won't be the only thing you'll change in the kernel
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
<Harm>
qschulz: a dts feels a bit in between code and config to me. Since, if I understand correctly, it is unusual to put the defconfig as a .patch in the Yocto layer
<qschulz>
Harm: I've seen and used everything already
<qschulz>
defconfig in kernel tree, defconfig in Yocto layer, defconfig + config fragment in Yocto
<Harm>
qschulz: so there is no real best practice here yet?
<qschulz>
this is less of an issue for ARM32 boards since they have defconfigs in the kernel tree
<qschulz>
but just a generic one for ARM64
<qschulz>
no idea what we're supposed to do
<qschulz>
(I mean even outside of Yocto itself.. how am I supposed to give a defconfig to users for my board?)
<Harm>
Interesting
<Harm>
I do see specific files for arm64 boards, I.e. tesla fsd-evb.dts
<qschulz>
Harm: in your local tree yes, not upstream
<qschulz>
custom tree*
<qschulz>
vvn: interesting, I don't see where the issue would be
<qschulz>
do you have the issue without your bbappend?
<qschulz>
if you have the issue only with your bbappend, I guess there might be something happening in the systemd.bbclass
<vvn>
qschulz: no I build fine without my bbappend. The package skips only an /etc/init.d/rc.pvr script, so I wanted to provide a proper service unit to please systemd-sysv-generator