invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
adams[1] has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
sakoman has joined #yocto
Estrella has joined #yocto
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #yocto
xmn has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
seninha has quit [Quit: Leaving]
wooosaiii has joined #yocto
wooosaiiii has quit [Ping timeout: 248 seconds]
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
olani- has quit [Ping timeout: 268 seconds]
demirok has quit [Quit: Leaving.]
goliath has joined #yocto
demirok has joined #yocto
yssh has joined #yocto
rob_w has joined #yocto
PaowZ has joined #yocto
Schlumpf has joined #yocto
goliath has quit [Quit: SIGSEGV]
mckoan|away is now known as mckoan
<mckoan>
good morning
<Schlumpf>
good morning
rfuentess has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
PhoenixMage has quit [Ping timeout: 248 seconds]
PhoenixMage has joined #yocto
camus has quit [Quit: camus]
camus has joined #yocto
adams[1] has quit [Quit: Client closed]
<LetoThe2nd>
yo dudX
zpfvo has joined #yocto
frieder has joined #yocto
Jham has joined #yocto
manuel1985 has joined #yocto
frieder has quit [Quit: Leaving]
frieder has joined #yocto
<KareemZarka[m]>
morning all! do we prefer to sumbit merge request to upstream? or a patch attached by email? for a small change regardng a script within oe-core/scripts/lib/wic/bootimg-efi/py?
<JaMa>
KareemZarka[m]: see README file which recommends git send-email, there is no need for whole pull-request with cover letter if it's just 1 commit
guest40 has joined #yocto
<guest40>
goodmorning all
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
<guest40>
Sorry if seems a stupid question: Is there a way to include the generated rootfs.tar.bz2 file in the image itself ? ( possible scenario: the factory-reset procedure of a device require the rootfs file )
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
<LetoThe2nd>
Guest40: yes, by chaining builds. see multiconfig
goliath has joined #yocto
<guest40>
so using IMAGE_POSTPROCESS_COMMAND is it not possible ? i mean...the fisical rootfs file is not yet generated in this step ?
<LetoThe2nd>
Guest40: an image is only one rootfs. so what you technically could do is by defining a custom image type include the *very same* rootfs again as a tar.gz. but that sounds like needlessly restricting yourself.
<RP>
Guest40: you could depend on another image recipe which could provide that second rootfs
<LetoThe2nd>
RP: okay thats possible too, yes. but still restricts you to the very same machine and distro and local configs.
<RP>
LetoThe2nd: right, just saying it is an option
<LetoThe2nd>
RP: +1
wooosaiii is now known as wooosaiiii
leon-anavi has joined #yocto
<guest40>
so technically i
<guest40>
have to create another .bb recipe of the same image...and depends on that one
<guest40>
thank you very much for the explanation!
yann has joined #yocto
florian has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
xmn has joined #yocto
ptsneves has joined #yocto
guest40 has quit [Quit: Client closed]
AntA has quit [Read error: Connection reset by peer]
tomzy_0 has joined #yocto
Schlumpf has quit [Ping timeout: 260 seconds]
yssh has quit [Quit: Client closed]
OnkelUlla has joined #yocto
Guest79 has joined #yocto
<Guest79>
hi, anyone using "meta-raspberrypi" dunfell and kirkstone? There is a performance loss in my app and when i benchmarked with sysbench, i found that the threads running slower in the Kirkstone.
<qschulz>
agherzan: I think this is for you? ^
<LetoThe2nd>
yeah. i think many are using it, but a performance regression has not been mentioned AFAIK.
<LetoThe2nd>
(i also use both revisions, but not doing anything that could exhibit such an observation)
starblue has quit [Ping timeout: 248 seconds]
<Guest79>
If you want a detailed explanation, i can write how i came to this conclusion and why i suspect threads.
starblue has joined #yocto
<LetoThe2nd>
well as i am not the one to solve it, probably not required here. if you think it is originally caused by meta-raspberrypi (and not some package that it just provides), then maybe file an issue on github?
<Guest79>
LetoThe2nd i thought of opening an issue but before opening it, i wanted to ask if anyone else has encountered such a problem.
<LetoThe2nd>
Guest79: :-) so while it is not an authoritative answer, i think this channels answer to that is "not yet reported"
<rburton>
hm why are there so many CVEs still in master. I should have made a load of those disappear.
PaowZ_ has joined #yocto
PaowZ has quit [Ping timeout: 248 seconds]
PaowZ_ has quit [Ping timeout: 252 seconds]
xmn has quit [Quit: ZZZzzz…]
PaowZ has joined #yocto
<rburton>
hm none of my mails to nist were actioned
seninha has joined #yocto
alessioigor has joined #yocto
<agherzan>
Guest79: as people mentioned above, nothing I'm aware of either.
<agherzan>
We would need to narrow it down a bit trying to figure out if it's BSP or package level
fray has quit [Ping timeout: 260 seconds]
seninha has quit [Quit: Leaving]
fray has joined #yocto
<agherzan>
Also, what kinda performance loss are we talking about - percentage-wise.
PaowZ_ has joined #yocto
seninha has joined #yocto
vik has joined #yocto
PaowZ has quit [Ping timeout: 256 seconds]
d-fens_ has joined #yocto
<vik>
Hi. Does anyone have experience with yocto hash equivalence server in case of multiple platform builds?
<vik>
Can we cover this use case with single running hash server instance or we need running hash server for each platform?
d-fens has quit [Ping timeout: 264 seconds]
<rburton>
vik: single instance if you share a sstate
<rburton>
basically, the hash server is tied to a sstate
<vik>
well for each platform we have separate sstate-cache
<vik>
so that means that we need multiple instance then, thank you rburton
florian_kc has joined #yocto
<rburton>
you can share sstate between platforms fwiw
<vik>
So if I have two different architectures for example x86 and arm64 I could use same folder for SSTATE_MIRRORS to share cache?
frieder has quit [Ping timeout: 252 seconds]
<vik>
Naming inside sstate cache folder is unique enough? I would lose any date due overwrite
<vik>
Naming inside sstate cache folder is unique enough? I wouldn't lose any date due overwrite?
Schlumpf has joined #yocto
<rburton>
you can always share sstate
<rburton>
that's the point of the 'shared' bit :)
<rburton>
the autobuilder has arm and x86 hosts, building for all of the qemu machines _and_ two meta-arm machines _and_ two meta-intel machines, with different libcs and distro configurations.
<rburton>
one sstate
<vik>
Thx, good to know. So then i'm good with single instance of server.
demirok has quit [Quit: Leaving.]
frieder has joined #yocto
vladest has quit [Ping timeout: 260 seconds]
jmk1 has quit [Ping timeout: 248 seconds]
xmn has joined #yocto
<vik>
One more question rburton, can i combine sstate cache with different version of yocto?
<rburton>
yes
<vik>
Great, will try :)
<JaMa>
you can, but it's not very useful to share in that case
demirok has joined #yocto
<JaMa>
I keep sstate-cache separate for different releases, because it makes the cleanup a bit faster (and can clean cache from master more often as it also grows much faster cache from releases)
<KareemZarka[m]>
<JaMa> "Kareem Zarka: see README file..." <- I'm not able to send a patch using git-email because I dont have SMTP access ,
<KareemZarka[m]>
would it be fine to simply include the patch in the body of the email ?
<KareemZarka[m]>
or shall I just make a merge request with the change ?
<rburton>
patches are via email. if you can't send a patch, complain to management.
<KareemZarka[m]>
rburton: oh yes I can send emails but not thru SMTP
<KareemZarka[m]>
I can simply send a email with body containing the patch ?
<KareemZarka[m]>
" Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs, wrap lines etc etc)."
<rburton>
you can try and it most likely won't work as mailers tend to break the patch.
<JaMa>
if you cannot send it from company network, you can send it from home later and complain to management as rburton said
sakoman has joined #yocto
<Guest79>
agherzan Here's how i discovered the performance difference between "meta-raspberrypi" dunfell and kirkstone:
<Guest79>
1) I'm doing CPS(Cycle Per Second) calculation in my code. I see between 23-25 in Dunfell, 15-17 in Kirkstone. I debug in my code to understand what is causing low cps and i noticed that OpenCV's resize() function is returning slower in Kirkstone.
<Guest79>
2) I created a main.cpp and resized 1640x1232 and 640x480 cv::Mat to 300x300 5000 times in it and calculated the elapsed time.
<Guest79>
In Kirkstone, the 1640x1232 resolution takes 30-31 seconds to resize. In Dunfell, it's 19-20 seconds.
<Guest79>
I zip the code (C++) and test results i wrote, I will share it below.
<Guest79>
3) I thought the problem would be caused by OpenCV, but the OpenCV version i used in Dunfell and Kirkstone is the same and the recipes are the same. However, i pulled the latest OpenCV version from the "meta-openembedded" master and got a build. But, the result did not change.
<Guest79>
4)I finally thought of benchmarking with the "sysbench" tool. I noticed something like this in the thread workload benchmark I made:
<Guest79>
While a single thread can execute 4125 events in 20 seconds in Kirkstone, it can execute 9227 events in Dunfell. I am sharing the test results below.
<Guest79>
**If you want me to upload it somewhere else, I can upload it there.
<Guest79>
By the way, i'm new to Yocto. I looked for my mistake as best i could and tried to solve it. I did everything i could to the best of my knowledge and came to the conclusion that the problem was not my fault. Maybe i am wrong but believe me i tried to figure it out myself before i came here. I'm sorry if im wrong, I'd appreciate it if you corrected
<Guest79>
it.
yann has joined #yocto
<qschulz>
Guest79: dependencies of openCV might have been updated meanwhile (or its defaults changed), so checking opencv recipe may not be enough (just giving a hint of things to check next).
<JaMa>
Guest79: can you compare CC variables? IIRC DEFAULTTUNE changed for rpi machines so it might be much less optimized now
<qschulz>
Guest79: bitbake-getvar -r opencv CC (and CFLAGS, CXXFLAGS or whatever) would return what JaMa is suggesting to look at I think
<rburton>
this isn't the first time i've seen someone comment that rpi is slower when upgrading so its good to see a bit of poking at the problem
<JaMa>
can you try to downgrade the kernel in kirkstone or upgrade in dunfell?
<JaMa>
that is IIRC 5.4 to 5.15
<Guest79>
JaMa as i said, im new to Yocto. I need to check how to do "kernel downgrade", after that i will write :)
<JaMa>
copying recipes-kernel/linux/ from kirkstone to dunfell version of meta-raspberrypi might do the job (togeher with update of conf/machine/include/rpi-default-versions.inc:PREFERRED_VERSION_linux-raspberrypi ??= "5.15.%")
<qschulz>
JaMa: I suspect the overrides syntax change may make this a bit more difficult than just copying files
<JaMa>
no kirkstone syntax is compatible with dunfell
<JaMa>
so it would be an issue only in the other direction (downgrade in kirkstone)
<Guest79>
i was doing opposite and trying to fix syntax. u saved me :D
leon-anavi has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
manuel1985 has quit [Ping timeout: 252 seconds]
rfuentess has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
frieder has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 260 seconds]
Jham has quit [Quit: Leaving]
<khem>
Guest79: you seem to have your own machine config is that right ?
<khem>
KMACHINE_<yourmachine> = "raspberrypi4-64"
<khem>
should fix it in a linux-rapberrypi_%.bbappend or main kernel recipe
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Read error: Connection reset by peer]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
adams[1] has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<Guest79>
khem right. i tried your suggestion but still getting same error. am i doing something wrong? just changed "raspberrypi4-64" to "raspberrypi4" because of my config 32bit.
<khem>
yes if its 32bit then use raspberrypi4 instead of raspberrypi4-64
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
seninha has quit [Ping timeout: 248 seconds]
<Guest79>
khem also i defined it in source as you said, but i still get the same error. in "linux-raspberrypi_5.4.bb", added :
<Guest79>
KMACHINE_trueai-rp432 = "raspberrypi"
<Guest79>
*raspberrypi4
florian_kc has joined #yocto
<khem>
hmm
<Guest79>
i think, i made a mistake somewhere else, im looking at it.
odra has joined #yocto
<Guest79>
khem fixed. im dumb. i used a few lines of dunfell syntax in a recipe in kirkstone. :D
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Haxxa has joined #yocto
<khem>
yeah it should be KMACHINE:<xxx>
florian_kc has quit [Ping timeout: 246 seconds]
adams[1] has quit [Ping timeout: 260 seconds]
adams[1] has joined #yocto
florian_kc has joined #yocto
camus has quit [Ping timeout: 256 seconds]
pabigot has quit [Ping timeout: 255 seconds]
camus has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
Jham has joined #yocto
PaowZ_ has quit [Ping timeout: 260 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Lightning has joined #yocto
<Lightning>
Hopefully a quick question. I'm making some alterations to some of the cross compiling tools for a project, binutils specifically. How can I get the cross compiler tools to be rebuilt? I
<Lightning>
i'm unsure what to put as the target or how to say to rebuild the cross compiled version and not the version for my platform
azcraft has quit [Remote host closed the connection]
seninha has joined #yocto
manuel1985 has joined #yocto
manuel1985 has quit [Ping timeout: 255 seconds]
Tartarus has quit [Quit: issued !quit command]
Tartarus has joined #yocto
<rburton>
Lightning: just rebuild your target image and it will rebuild the tool chain. Yocto isn’t like some distros and knows when stuff needs to be rebuild. If you’d
<rburton>
If you changed binutils it will rebuild it, and then rebuild all the packages in your image
<Lightning>
ok
Lightning has left #yocto [Closing Window]
kscherer has quit [Quit: Konversation terminated!]
Jham has joined #yocto
Jham has quit [Client Quit]
pabigot has joined #yocto
<khem>
bitbake binutils-cross-<target> for cross compiling binutils