Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Daanct12 has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
deribaucourt has quit [Ping timeout: 268 seconds]
ederibaucourt has joined #yocto
Xagen has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Daanct12 has quit [Quit: WeeChat 4.5.1]
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
ehussain has joined #yocto
Daanct12 has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
ahussain has joined #yocto
ehussain has quit [Ping timeout: 244 seconds]
ahussain is now known as ehussain
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
pidge_ has joined #yocto
pidge has quit [Ping timeout: 268 seconds]
leon-anavi has joined #yocto
Articulus has joined #yocto
enok has joined #yocto
rob_w has joined #yocto
pbergin has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
henrik_ has quit [Ping timeout: 272 seconds]
ehussain has quit [Ping timeout: 272 seconds]
<khem>
RP: I looked at the toolchain selection patch in master-next and to me it looks good to go,
<khem>
I can fix the clang fallouts
mckoan|away is now known as mckoan
Kubu_work has joined #yocto
rfuentess has joined #yocto
henrik_ has joined #yocto
henrik_ has quit [Read error: Connection reset by peer]
rob_w has quit [Remote host closed the connection]
rob_w has joined #yocto
Ad0 has joined #yocto
vthor_ has joined #yocto
vThor has quit [Read error: Connection reset by peer]
ablu has quit [Ping timeout: 265 seconds]
ablu has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
AndyPandy60 has joined #yocto
enok has quit [Ping timeout: 252 seconds]
<rfuentess>
yesterday I was freaking out because I was trying to mimic the behavior in a new hardware platform based in our current one. I'm not the main maintainer, I just discovered that all my effort was fruitless because the recipe that I was using as reference was not even working as expected in the original platform
<rfuentess>
I still need to adapt the stuff, but now I need to discover how is that the stuff can work in the current hardware
enok has joined #yocto
<rfuentess>
by the way, are there good faqs about busybox ? xD
<rfuentess>
(adapted to yocto I mean)
enok71 has joined #yocto
rob_w has quit [Ping timeout: 248 seconds]
enok has quit [Ping timeout: 276 seconds]
enok71 is now known as enok
berton has joined #yocto
<AndyPandy60>
Hi there, I am wondering if someone came across the issue. I am using Yocto Kirkstone. I have a recipe say
<AndyPandy60>
u-boot-test, there two layers, one with a lower priority has the following file u-boot-test_%.bbappend
<AndyPandy60>
SRC_URI:append = " \
<AndyPandy60>
file://0200-test.patch \
<AndyPandy60>
"
<AndyPandy60>
And one with a higher priority has the following files: u-boot-test_%.bbappend and u-boot-test_2021.04.bb
<AndyPandy60>
Somehow the %.bbappend file from the higher priority layer is appended after %.bbappend from the lower one?
<AndyPandy60>
How is it possible? What did I miss?
<KanjiMonster>
AndyPandy60: just guessing here, but I presume the append order is from lowest to highest so that e.g. if both try to append the same file (name/path), the "highest" priority one will win
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<AndyPandy60>
I assumed that, say x_*.bbappend would be appended to x_1.bb for the recipe in one layer, and then in another layer with lower priority x_*.bbappend would be appended.
<AndyPandy60>
In other words if I have the following in bblayers.conf BBLAYERS += " \
<AndyPandy60>
layer1 \
<AndyPandy60>
layer2 \
<AndyPandy60>
" layer2's bbappend will be applied last.
rob_w has joined #yocto
<KanjiMonster>
Consider if both bbappends try to set the same variable (e.g. PACKAGECONFIG), shouldn't the value from the highest priority one win? Easiest to solve this is to parse/append the highest priority one last (with the side effect that any :appends are also applied in this order)
<CrazyGecko>
hei guys, I'm trying to use the less or equal util to set a variable. I'm failing with a syntax error in the first `cpu_count` resolution, but I don't know how to solve it. when I put it in "", then all the characters are written into the variable. anyone any idea, what I'm doing wron?
<berton>
Hello! There is an issue with ccache that I want to fix. bitbake uses hardlinks to create files in recipe-sysroot and this resets the ctime of each file. I want to add the include_file_ctime to the CCACHE_SLOPPINESS variable, see https://ccache.dev/manual/latest.html#config_sloppiness. What is the best place to add this, using `export CCACHE_SLOPPINESS` in ccache.bbclass or adding an entry in conf/ccache.conf?
florian has joined #yocto
<CrazyGecko>
if anyone is interessted in the solution: CPU_LIMIT = "12" \ CPU_COUNT = '${@oe.utils.cpu_count()}' \ PARALLEL_MAKE = '-j ${@oe.utils.less_or_equal("CPU_COUNT", ${CPU_LIMIT}, ${CPU_COUNT}, ${CPU_LIMIT}, d)}'
<paulg>
CrazyGecko, you might also want to look at BB_PRESSURE_MAX_CPU (and i/o and memory) if you are trying to keep a lid on things.
<CrazyGecko>
paulg, thanks. that's a good input. We're currently on kirkstone which does not have this variable, but I will keep that in mind for the future. Our current problem is wpewebkit takes too much RAM when building with a lot of threads in parallel ;)
starblue has joined #yocto
Guest71 has joined #yocto
<Guest71>
Hi, a bit confused by the branch naming in yocto upstream. What does "-nut" (eg: kirkstone-nut)branch means ? Is it related to nightly testing ?
<RP>
berton: probably ccache.conf since exporting something to the environment will change all the task signatures
<RP>
Guest71: yes, they're testing branches. The names have become a bit strange over the years, it means "next under test"
<Guest71>
Thanks.
<berton>
RP: yes, I'm running some test and if I add new values to CCACHE_SLOPPINESS the sstate cache is invalidated. And bitbake -S printdiff shows that CCACHE_SLOPPINESS has changed. So, it need to be added in the conf file.
<RP>
berton: there are ways to avoid that but the conf file will be easier
<berton>
RP: Ok, thanks!
<RP>
berton: a patch for that would probably make sense
Guest71 has quit [Quit: Client closed]
<dvergatal>
JPEW: around?
<berton>
RP: Do you mean a patch to add the `sloppiness = include_file_ctime` in the meta/conf/ccache.conf?
<paulg>
CrazyGecko, I've had this idea I've been mulling over for quite some time - introduce some kind of bitbake variable to pause adding/scheduling additional tasks. So packages like rust-llvm and qemu-native could set it, and then those behemoths could grind away at PARALLEL_MAKE setting but effectively and temporarily setting BB_NUMBER_THREADS to one.
<RP>
berton: yes
<RP>
paulg: effectively the BB pressure and load variables do that based on the system load values
<paulg>
yeah, but they are still hard to tune for Joe Average, and not really well documented. We already know which packages are the culprits - why make others suffer and learn it for themselves?
<berton>
RP: I will prepare a patch and send it to ML
pvogelaar has quit [Ping timeout: 248 seconds]
<RP>
paulg: I know what you mean although the problems can be more widespread, things like large rpms hitting craziness with the compression algos
<paulg>
well, I figured probably best to float the idea here vs. eventually implementing it and then getting a NACK.
<RP>
paulg: we just tried to aim for more automatic solutions rather than a list of known offenders
<RP>
trying to come up with rules for which recipes/tasks should be in the list would have its own challenges
mbulut has joined #yocto
<paulg>
yeah, maybe we somehow need to be better in detecting when we've forced a machine into swap-death and eventual kernel OOM splat.
<RP>
paulg: I'd love to do that if we could...
<RP>
if only some kernel literate people could work out how to do it... :)
* RP
waits for the inevitable reply to that
<paulg>
I've got several 8G machines to dump this spring. Perfectly fine for running firefox with a bunch of tabs open - but no longer tolerable for yocto builds.
<RP>
I do want to see a prebuilt binary rust option too. Just nobody has written it and I'm not going to do it
<paulg>
Challenge is, some of my machines don't even have swap space enabled. :-P
<paulg>
and for the record, the in-kernel OOM killer sucks donkey balls too. I've had many times where the hard disk LED is on solid and I can't even move the mouse, and it just sits there whistling and staring off at the clouds.
<paulg>
Forcing me to do a sysrq in order to bring the grindfest to an end.
<CrazyGecko>
what if we just would add a variable, which does not allow this recipe to run in parallel with other recipes?
<paulg>
CrazyGecko, I guess that faces the same challenge RP mentioned - who decides what lands on that list?
<RP>
paulg: I've had a lot of problems with the OOM killer. It seems better now, probably systemd helping :)
<CrazyGecko>
the same people who decide to use PARALLEL_MAKE with another option than the default. It's not optimal, but it gives the "user" more joice to maybe build some behemouths separated
<RP>
CrazyGecko: from a scheduler perspective, true isolation is hard since you have to wait for everything else to stop to run this specific task
<RP>
the bitbake schedulers are plugins so someone could actually write one
<bjdooks>
I just OOMed my laptop by just make -j modules in 6.13
<paulg>
In a strict sense you are right, but in practice that isn't entirely true. If I'm watching a build, and see a behemoth building, I'll hit a single ^C and that effectively lets all the "normal" tasks to complete, and the behemoth.do_compile to chug along alone.
<paulg>
Effectively a manual implementation of my original idea above.
<CrazyGecko>
RP, yes, I see. and maybe some other tasks wait on that one to continue
<paulg>
if a behemoth recipe set BB_I_AM_A_GIANT_PIG, it still has to do unpack patch and configure, giving a good window for other tasks to complete and get out of the way before it gets to compiling.
<paulg>
Anyway, whatever. I know it wouldn't be perfect, but it might just suck slightly less.
<RP>
paulg: it depends whether you require "only run this task" or "don't run any more tasks"
<RP>
paulg: people would expect different things
AndyPandy60 has quit [Quit: Client closed]
<paulg>
well, I suppose one could also claim to expect that a 32G machine wouldn't OOM on something as common as core-image-minimal, but I digress.
<Emantor>
at least core-image-minimal does not contain a chromium.
* Emantor
still remembers the horror of his colleague hugging the build server with chromium
<RP>
my build server probably needs a hug :)
mckoan is now known as mckoan|away
<LetoThe2nd>
RP: yeah my mental image also was... similar.
<paulg>
with the recent cold snap here in Ottawa, hugging the build server could actually make sense...
Jones42 has joined #yocto
darko311 has joined #yocto
frgo_ has joined #yocto
frgo has quit [Ping timeout: 272 seconds]
Daanct12 has quit [Quit: WeeChat 4.5.1]
enok has quit [Ping timeout: 248 seconds]
enok has joined #yocto
Xagen has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
grma has quit [Ping timeout: 248 seconds]
<rfs613>
paulg: bigger problem is where to put all the snow...
rob_w has quit [Remote host closed the connection]
<paulg>
tell me about it. I've got a six foot wide strip of "lawn" between me and my neighbour and it is heaped up to where it is a triangle and it just rolls down one side or the other now. Good thing March is just around the corner.
Jones42 has quit [Quit: Client closed]
enok has quit [Ping timeout: 248 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
florian_kc has joined #yocto
Xagen has joined #yocto
goliath has joined #yocto
CrazyGecko has quit [Ping timeout: 252 seconds]
dgriego has quit [Ping timeout: 272 seconds]
ptsneves has joined #yocto
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
cambrian_invader has joined #yocto
<kilobyte_ch>
Hello, I have a task running after do_image_wic which modifies the wic file with "mcopy". This works fine, but this alters the wic checksum. Any idea how to prevent this? My goal is to modify the content of the textfile on my boot partitions. Thus the workaround with "mcopy".
<kilobyte_ch>
bmaptool: ERROR: checksum mismatch for blocks range 33792-46199: calculated bb4eb524db6b9614994f698386a8afe0928e42cc4edaca85e267415ce6a362e3, should be 0a0b6422d3152002ff1c976e0c3395175303e8e962032613f3c6f240af9eb48c (image file xxx.wic)
<kilobyte_ch>
Is there a way to alter the partitions before wic maybe?
<LetoThe2nd>
kilobyte_ch: by putting your modifications into a recipe.
<kilobyte_ch>
I haven't found a way to do this in a recipe. I have bootA/bootB with source bootimg-partition. But then I need to change cmdline.txt for bootA/bootB as they differ for A/B.
<rburton>
doing the change in a do_image_wic[postfunc
<rburton>
] might happen before the bmap generation happens?
florian has quit [Quit: Ex-Chat]
rfuentess has quit [Quit: en busqueda de las chelas]
florian_kc has quit [Ping timeout: 252 seconds]
dgriego has joined #yocto
Articulus has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
berton has quit [Remote host closed the connection]
florian_kc has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
florian_kc has quit [Ping timeout: 265 seconds]
druppy has joined #yocto
darko311 has quit [Ping timeout: 248 seconds]
druppy has quit [Ping timeout: 248 seconds]
Minvera has joined #yocto
florian_kc has joined #yocto
pidge has joined #yocto
pidge_ has quit [Read error: Connection reset by peer]
pidge_ has joined #yocto
pidge has quit [Ping timeout: 245 seconds]
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
beneth has quit [Quit: Gateway shutdown]
florian_kc has quit [Ping timeout: 252 seconds]
druppy has joined #yocto
frgo has joined #yocto
frgo_ has quit [Ping timeout: 268 seconds]
frgo has quit [Ping timeout: 268 seconds]
Kubu_work has quit [Quit: Leaving.]
savolla has joined #yocto
frgo has joined #yocto
florian_kc has joined #yocto
frgo has quit [Ping timeout: 248 seconds]
prabhakalad has quit [Ping timeout: 244 seconds]
<JPEW>
RP: meta-mingw master-next is updated. Let me know if there are any more issues
frgo has joined #yocto
beneth has joined #yocto
frgo has quit [Ping timeout: 268 seconds]
frgo has joined #yocto
<RP>
JPEW: tested green and merged, thanks. Very much appreciated
frgo has quit [Ping timeout: 244 seconds]
savolla has quit [Quit: WeeChat 4.4.3]
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
frgo has joined #yocto
mbulut has quit [Quit: Leaving]
frgo has quit [Ping timeout: 252 seconds]
frgo has joined #yocto
frgo has quit [Ping timeout: 248 seconds]
steelswords94361 has quit [Quit: Ping timeout (120 seconds)]
steelswords94361 has joined #yocto
Kotio has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
Kotio has quit [Quit: Client closed]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]