LetoThe2nd changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Community: https://www.yoctoproject.org/community | IRC logs: http://irc.yoctoproject.org/irc/ | Having difficulty on the list, with someone on the list or on IRC, contact Yocto Project Community Manager Letothe2nd | CoC: https://www.yoctoproject.org/community/code-of-conduct
florian_kc has quit [Ping timeout: 255 seconds]
mvlad has quit [Remote host closed the connection]
chep has quit [Quit: ZNC 1.8.2 - https://znc.in]
chep has joined #yocto
lexano has quit [Ping timeout: 256 seconds]
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
KhazAkar has quit [Quit: Connection closed for inactivity]
nerdboy has quit [Ping timeout: 252 seconds]
davidinux has quit [Ping timeout: 264 seconds]
starblue has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
starblue has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
ablu has quit [Ping timeout: 255 seconds]
ablu has joined #yocto
sakman has quit [Quit: Leaving]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
Vonter has quit [Ping timeout: 276 seconds]
Chaser has joined #yocto
amitk has joined #yocto
amitk has quit [Client Quit]
sakman has joined #yocto
KhazAkar has joined #yocto
nerdboy has quit [Ping timeout: 252 seconds]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
sakman has quit [Remote host closed the connection]
sakman has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
linfax has joined #yocto
frieder has joined #yocto
jmd has joined #yocto
tnovotny has joined #yocto
mckoan|away is now known as mckoan
mbulut has joined #yocto
goliath has joined #yocto
zpfvo has joined #yocto
leon-anavi has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rber|res has joined #yocto
<rber|res> Hi
<rber|res> A far as I remember some things are cross compiled within qemu in a build.
<rber|res> Here we have the problem that the cross compilation does not quite work, so a native compilation within an arm qemu would probably solve the issue.
kulos75 has joined #yocto
prabhakarlad has joined #yocto
paulg has quit [Ping timeout: 255 seconds]
kulos75 has quit [Ping timeout: 250 seconds]
kulos75 has joined #yocto
mvlad has joined #yocto
kulos39 has joined #yocto
kulos39 has quit [Client Quit]
<ablu> rber|res : Typically things are just cross-compiled with native executables (so a x86_64 gcc will build a aarch64 binary) without QEMU involved. It would probably help to explain your problem in more detail.
<LetoThe2nd> rber|res: ya some fonts use it AFAIK, and something something gobject? rburton to the rescue.
<rber|res> @ablu - cross compiling the binary results in Segfaults, compiled on the target works
<LetoThe2nd> rber|res: technically fixing the build is of course prefereable, but i know, reality and all.
<ablu> rber|res: out of interest: Segfaults during compilation or on target?
Kubu_work has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
adrian_s has joined #yocto
adrian_s has quit [Quit: This computer has gone to sleep]
adrian_s has joined #yocto
ray-san3 has joined #yocto
florian_kc has joined #yocto
ray-san2 has quit [Ping timeout: 255 seconds]
<rber|res> Segfaults on the target
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
adrian_s has quit [Quit: This computer has gone to sleep]
hays has joined #yocto
BylethTMP has joined #yocto
adrian_s has joined #yocto
florian__ has joined #yocto
gsalazar has joined #yocto
adrian_s has quit [Quit: This computer has gone to sleep]
<BylethTMP> Hey everybody ! I'm back for another problem ! I have a recipe `foo` (it's a static lib) which depends on `bar` which depends on curl. So my recipe for `bar` and my recipe for `foo` works fine. But if i try to build an application `myApp` that uses `foo` i get an error while `do_configure()` with cmake because `foo_config.cmake` does not find
<BylethTMP> `curl_config.cmake`. But `foo` recipe works fine when i do "bitbake foo". Any ideas ? :/
adrian_s has joined #yocto
adrian_s has quit [Client Quit]
adrian_s has joined #yocto
<qschulz> tlwoerner: mmm actually ddr_tool is a prebuilt binary... so this means meta-rockchip wouldn't be runnable on non-x86 platforms (well except if we qemu run that one binary... how sad)
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ptsneves has joined #yocto
hcg has joined #yocto
<mckoan> BylethTMP: the guilty should be the myApp_config.cmake
<BylethTMP> mckoan I just put `find_package(foo)` in my CMakeLists.txt...
<BylethTMP> I don't know how it creates a such file. + Call Stack tells me that error is from that find_package
Omax has quit [Read error: Connection reset by peer]
adrian_s has quit [Quit: This computer has gone to sleep]
adrian_s has joined #yocto
<BylethTMP> If `foo` is static but `bar` load dynamic libcurl. Could it be conflicting ?
Omax has joined #yocto
<ablu> rber|res: hm... I would be a bit worried that there is some undiagnosed bug around... Have you done some analysis on why this happens? Fixing that sounds like a better solution to me compared to building it in QEMU.
starblue has quit [Ping timeout: 255 seconds]
davidinux has quit [Quit: WeeChat 3.5]
starblue has joined #yocto
<rburton> rber|res: there's nothing in core which _compiles_ in qemu. we occasionally use qemu-user to run tooling which needs to know stuff like target wordsize and is too dumb to support cross, and that's probably your problem: it builds and runs a tool at build time which assumes eg sizeof(void*) or byte order is relevant for the target
<rburton> rber|res: useful if you can say what the code is though
<rber|res> @rburton: Yep I think this is what I am after. I did a quick grep on poky and saw qemu-usermode and nativesdk-qemuwrapper-cross
<rber|res> @rburton: Can you think of an example I could copy from?
<kanavin> rpm upstream has ditched autoconf
<kanavin> sadly the replacement is... cmake
<kanavin> it's going to be a bit of pain rewriting all the autoconf bits in the recipe
ad__ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
ad__ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
dacav has joined #yocto
<LetoThe2nd> kanavin: consider yourself lucky! if it were autoconf bytes in the recipe, it would be 8 times the work!
mckoan is now known as mckoan|away
dacav has quit [Quit: leaving]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ray-san3 has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
sstiller has joined #yocto
alessioigor has joined #yocto
ad__ has quit [Changing host]
ad__ has joined #yocto
<LetoThe2nd> interesting question from one of our users. they report UIDs and GIDs changing across YP releases, which makes upgrades complicated for them. has anybody run into that yet, or can share a best practise solution?
lexano has joined #yocto
<ederibaucourt> LetoThe2nd useradd-staticids should allow the user to get rid of dynamic IDs. See https://docs.yoctoproject.org/pipermail/yocto/2017-February/034561.html
Kubu_work has quit [Ping timeout: 260 seconds]
Kubu_work1 has joined #yocto
<RP> kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2473/steps/14/logs/stdio we're still seeing some weird test failures :(
<kanavin> RP: oh no. I'll try to get to it later today, should the failing build dir be saved for inspection?
<RP> kanavin: we should probably try and save one
<RP> kanavin: did we find the CDN test could be enabled or not? I've lost track of where we were on that one
<kanavin> RP: I got sick, then when I got healthy, I ran it through a few times, changing things, and then not changing things, and I couldn't trigger missing items situation
<kanavin> so it works... ish
<LetoThe2nd> ederibaucourt: having a look, thanks!
<kanavin> RP: I think you also had a commit that re-enables CDN test in your master-next for a while
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
BylethTMP has left #yocto [#yocto]
paulg has joined #yocto
<RP> kanavin: yes. It is possible the refresh of sstate and other changes I made fixed it. I should perhaps merge the re-enable
Kubu_work1 has quit [Read error: Connection reset by peer]
adrian_s has quit [Quit: This computer has gone to sleep]
Kubu_work has joined #yocto
adrian_s has joined #yocto
<sakoman> abelloni: it seems like you might have missed: vim: Upgrade 9.0.2048 -> 9.0.2068
goliath has quit [Quit: SIGSEGV]
<sakoman> it was sent for stable branches too and I've been carrying it waiting for master to accept it. fwiw no issues with the patch on the stable branches
<RP> kanavin: I saved the build on the 1804 arm worker. We can't really keep it for long on those machines though
<sakoman> abelloni: v1 was bad (missing SRCREV update), I've been testing v2
<RP> sakoman: I've merged it
<sakoman> RP: thanks!
<RP> sakoman: debuginfod patch also now in
<sakoman> RP: excellent
Chaser has quit [Quit: Chaser]
Minvera has joined #yocto
adrian_s_ has joined #yocto
adrian_s has quit [Ping timeout: 255 seconds]
zpfvo has quit [Ping timeout: 276 seconds]
zpfvo has joined #yocto
Dartmoness has joined #yocto
Dartmoness has left #yocto [#yocto]
tnovotny has quit [Quit: Leaving]
Minvera has quit [Remote host closed the connection]
adrian_s_ has quit [Quit: This computer has gone to sleep]
<chep> hi, I have a problem with bbappend files. In a layer with priority = 9 I have `PACKAGECONFIG:remove = "networkd"` in systemd_%.bbappend. In my layer with priority = 10 I have `PACKAGECONFIG:append = "networkd"` in systemd_%.bbappend. `bitbake -e systemd` shows me PACKAGECONFIG="some things but no networkd". What do I miss ?
sakman has quit [Quit: Leaving]
<RP> chep: removes are always processed last. It is one reason we try and avoid them as you can't "undo" them easily
<chep> RP: thx
<chep> so there is no way to use the 2 layers together ?
<RP> chep: probably a anonymous function in a bbappend which does a d.setVar("PACKAGECONFIG", "XXX") explicitly
<chep> RP: I see
<chep> thanks
<rburton> chep: long-term fix would be to stop that layer doing the :remove in the first place, as that's just very antisocial
<chep> :-D
<jonmason> did anyone ever try using xeon phi for building?
<rburton> oh that would be madness
<rburton> I guess you could run icecream on each core
<jonmason> they are like $30 on ebay
<jonmason> likes like $0.52/core
<jonmason> s/likes/thats/
<rburton> just stop
<jonmason> :D
<gmorell> someone asked on the intel forums a while ago, and it's not great at this kind of work
<rburton> remember each core is basically a pentium
<gmorell> you're better off gettting off some xeon/epyc 2S box
<LetoThe2nd> jonmason: can we get a talk about it at the OE workshop?
rber|res has quit [Remote host closed the connection]
adrian_s_ has joined #yocto
<jonmason> LetoThe2nd: maybe for 2024
<jonmason> I already promised something today for oe workshop, and I need to do that
<LetoThe2nd> jonmason: https://pretalx.com/oe-ws-2024/cfp ... :-)
<jonmason> no, I mean a year from today :)
<LetoThe2nd> jonmason: oh comn.
<LetoThe2nd> *cmon.
<jonmason> LetoThe2nd: I've promised to do things at last FOSDEM that I haven't started. Only got 2 months now
<LetoThe2nd> jonmason: just pulling your leg :-)
<jonmason> LetoThe2nd: I know
speeder has joined #yocto
<jonmason> It occurred to me a couple weeks ago that I promised to get Labgrid working and never even started
<LetoThe2nd> jonmason: heh i did actually, but was a rough ride. postponed a bit until hw rig is finished now.
<jonmason> my thought is I need to look hard and maybe get some parts for cheap on black friday
<RP> jonmason: I keep thinking about doing something like that. I just don't have the time though :(
<jonmason> RP: crazy idea, what if we just sent 4 to rburton. I mean, he wouldn't just throw them away
Kubu_work has quit [Quit: Leaving.]
linfax has quit [Ping timeout: 264 seconds]
Vonter has joined #yocto
leon-anavi has quit [Quit: Leaving]
zpfvo has quit [Remote host closed the connection]
mbulut has quit [Ping timeout: 264 seconds]
alessioigor has quit [Quit: alessioigor]
adrian_s_ has quit [Quit: Leaving]
alessioigor has joined #yocto
khem has quit []
khem has joined #yocto
<moto-timo> jonmason: 4 Xeon phi boards?
kulos75 has quit [Quit: Konversation terminated!]
<jonmason> moto-timo: yeah, why not. Don't tell me you have a cache of them somewhere
starblue has quit [Ping timeout: 260 seconds]
<moto-timo> jonmason: lol. no. People "Inside Blue" kept telling me it wasn't going to help my YP builds so I left it alone.
<jonmason> moto-timo: extremely light googling seems to imply they show up as extra cores. my massively stupid idea is to show those into containers. I expect the memory latency to make them almost unusable though
<moto-timo> jonmason: we just need to get the proper person thinking about it... lol
<mischief> i tried to find results on openbenchmarking for any of the socketed xeon phis and there's like no results :(
<moto-timo> gif "Run away! Run away! Run away!"
<mischief> i think that code was specifically for running the communication interface to the xeon phi pcie cards. i don't think the socketed ones have that 'problem'
florian__ has quit [Ping timeout: 256 seconds]
<rburton> jonmason: they don't show up as extra cores, they're standalone processors
mbulut has joined #yocto
<rburton> (at least thats how the phi i knew worked)
speeder has quit [Ping timeout: 255 seconds]
<mischief> very random question: does anyone think of "openssl speed" as a good performance benchmark?
<mischief> someone had the idea that we should run 32-bit arm userspace on arm64 devices and i used a 32-bit version of openssl as a point of comparison to show it was much slower
<rburton> its not a terrible benchmark, especially if its relevant to what you actually need to do
<khem> if you have h/w crypto it might not show much of a difference
<rburton> but yeah, hw offloaded crypto would change things
<rburton> then again, depending on what arm core you have, the extra instructions can make ssl a lot faster if its all in software
<rburton> mischief: point out that armv9 is the glorious future and doesn't have 32-bit support at all, so running 32-bit code on an aarch64 chip is just silly :)
<mischief> we're on qualcomm chipsets, but i don't think we've ever tried to specifically enable use of the available accelerators.
<rburton> at least i hope the machine sets the right -march so you get gcc using all the supported instructions
<khem> micro-benchmark would not show wholesome picture so consider multiple of them targetting CPU/memory/disk/io
<khem> maybe start with sysbench
<khem> and then include fio and iozone
<rburton> no khem. the correct response is a confused stare to someone asking "what if we run this 64-bit processor in 32-bit mode"
<rburton> :)
chep` has joined #yocto
<khem> lol
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
<khem> armv9 + MTE is a seller
<mischief> for one of our oldest 32 bit machines, 'openssl speed dsa' reports 100 signs/s, and for the newest arm64 machine, nearly 700
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
<khem> yeah cryptsetup benchmark might be a good one too if you are interested in ciphers more than others
mbulut has quit [Ping timeout: 255 seconds]
<mischief> we don't really do any crypto directly, just more of a proxy for general cpu performance.
<rburton> mischief: there is a very small argument for 32-bit pointers but with the 64-bit ISA. (see also, intel x32). You get more registers and better instructions but less memory usage. It's never really been enabled in linux though.
Kubu_work has joined #yocto
<khem> rburton: portability is the only argument
<khem> lot of old s/w assumed 32bit is end of world
<rburton> yeah, the gains are _really_ slim and there's a huge hit in thats codepaths nobody tests
<mischief> right.. one of the original reasons was memory usage, but that's why i tried to point out it would kneecap performance with 'openssl speed'
<rburton> khem: right. v9 is a hard sell if someone has 32-bit closed binaries they bought or can't rebuild
<mischief> people want to spend less money on memory chips of course :)
<khem> BYTE UNIX benchmark is still rocking - https://github.com/kdlucas/byte-unixbench/tree/master
<khem> this use to be my go to benchmark
gsalazar has quit [Quit: Leaving]
speeder has joined #yocto
speeder has quit [Remote host closed the connection]
speeder has joined #yocto
grma has quit [Ping timeout: 276 seconds]
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
hcg has quit [Quit: Client closed]
florian__ has joined #yocto
sstiller has quit [Quit: Leaving]
speeder has quit [Ping timeout: 246 seconds]
frieder has quit [Remote host closed the connection]
speeder has joined #yocto
mbulut has joined #yocto
Perflosopher has quit [Quit: Ping timeout (120 seconds)]
Perflosopher has joined #yocto
florian has joined #yocto
florian__ has quit [Ping timeout: 276 seconds]
<nerdboy> moin
speeder has quit [Ping timeout: 276 seconds]
wmills has quit [Read error: Connection reset by peer]
wmills has joined #yocto
adrian_s has joined #yocto
prabhakarlad has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
sakman has joined #yocto
Haxxa has joined #yocto
<Saur_Home> chep: Regarding :remove, if you have control of both layers, you can use something like `REMOVE_NETWORKD = "networkd"` and `PACKAGECONFIG:remove = "${REMOVE_NETWORKD}"`. Then if you want to enable networkd again in the other layer, it can just set `REMOVE_NETWORKD = ""`. This works pretty well, but it requires that you can prepare for it.
speeder has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
speeder has quit [Ping timeout: 268 seconds]
Wouter0100670440 has joined #yocto
Wouter0100670440 has quit [Remote host closed the connection]
Wouter0100670440 has joined #yocto
speeder has joined #yocto
starblue has joined #yocto
speeder has quit [Ping timeout: 240 seconds]
jmd has quit [Remote host closed the connection]
speeder has joined #yocto
mbulut has quit [Ping timeout: 256 seconds]
Minvera has joined #yocto
florian has quit [Ping timeout: 268 seconds]
speeder has quit [Ping timeout: 256 seconds]
speeder has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
florian has joined #yocto
adrian_s has quit [Ping timeout: 276 seconds]
starblue has joined #yocto
demirok has quit [Quit: WeeChat 4.1.0]
adrian_s has joined #yocto
demirok has joined #yocto
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
<RP> jonmason, moto-timo: I was involved in some of the early phi work before it became the phi. Lets just say it wouldn't be useful to us ;-)
<moto-timo> RP: or anyone, apparently 😈
<RP> jonmason: I was refering to labgrind and automated hardware testing FWIW :)
<RP> moto-timo: ask me about that over beer sometime ;-)
* moto-timo will continue to plan to get labgrid going in the home lab
<moto-timo> RP: hopefully that will be in a pub in the UK ;)
<jonmason> Yes, it might be good to poke around with that over this short holiday
<moto-timo> I've been at this new house for 1 1/2 years now, so moving is not longer a valid excuse.
<RP> I would love to play with it. I just know I'm "at capacity" :/
<moto-timo> "beyond capacity"
<RP> moto-timo: I did wonder about that! :)
starblue has quit [Ping timeout: 256 seconds]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
nerdboy has quit [Ping timeout: 255 seconds]
nerdboy has joined #yocto
Kubu_work has quit [Quit: Leaving.]
starblue has joined #yocto
hnez has quit [Quit: No Ping reply in 180 seconds.]
hnez has joined #yocto