<vmeson>
RP thanks I was going to apply that elfutils patch but you have it in master-next already !
otavio has quit [Read error: Connection reset by peer]
otavio has joined #yocto
wing0 has quit [Quit: WeeChat 3.1]
stwcx has joined #yocto
nerdboy_ has joined #yocto
nerdboy has quit [Ping timeout: 265 seconds]
nerdboy_ is now known as nerdboy
nerdboy has quit [Changing host]
nerdboy has joined #yocto
sakoman has quit [Quit: Leaving.]
boo has quit [Ping timeout: 258 seconds]
amitk has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
roussinm has quit [Quit: WeeChat 3.3-dev]
rpcme has quit [Ping timeout: 246 seconds]
stwcx has quit [Quit: Ping timeout (120 seconds)]
rob_w has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
lexano has quit [Ping timeout: 276 seconds]
frieder has joined #yocto
lexano has joined #yocto
goliath has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
LetoThe2nd has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
zpfvo has joined #yocto
ant__ has quit [Ping timeout: 252 seconds]
<LetoThe2nd>
yo dudX and mckoans
hpsy has joined #yocto
goliath has quit [Quit: SIGSEGV]
<RP>
vmeson: it fixes x86 but not arm :/
prabhakarlad has joined #yocto
<mihai>
yo
<LetoThe2nd>
yö, even!
ant__ has joined #yocto
goliath has joined #yocto
florian has joined #yocto
leon-anavi has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
mckoan has quit [Ping timeout: 276 seconds]
mckoan has joined #yocto
ant__ has quit [Quit: Leaving]
jwillikers has joined #yocto
<override>
/window 3
rpcme has joined #yocto
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
boo has joined #yocto
mckoan has quit [Quit: Quitting irssi IRC Client, bye.]
mckoan has joined #yocto
goliath has quit [Quit: SIGSEGV]
sakoman has joined #yocto
prabhakarlad has quit [Quit: Client closed]
rpcme has quit [Quit: Client closed]
roussinm has joined #yocto
bps has quit [Ping timeout: 256 seconds]
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
mseeber has joined #yocto
<mseeber>
in case a machine config file is present in two layers, how does bitbake determine which file to use? From testing, it seems to me, that the layer priority is ignored but ordering of the layers inside bblayers.conf determines which config file is used. Is this the intended behavior? (tested on on zeus)
frieder has quit [Ping timeout: 272 seconds]
<qschulz>
mseeber: it is based on BBPATH defined in layer.conf
<qschulz>
since each layer is appending by default to the existing BBPATH, the consequence is that indeed, the "precedence" depends on the order from BBLAYERS in bbalyers.conf
<qschulz>
s/appending by default/by default appending/
<qschulz>
specifically leaving out an important piece of information
<mseeber>
That sounds to me, that there is no way to prioritize machine configs through layer priorities, which means the only safe way is to include the old config in the new one (with the same file name) and override the variables.
frieder has joined #yocto
<qschulz>
as for bbclasses, conf files aren't meant to be extended
<qschulz>
so you have to write a new one which include the other
<qschulz>
please use different names
<mseeber>
ah, that makes sense
<qschulz>
but you can use MACHINEOVERRIDES to tell Yocto that they are in fact of the same "family"
<mseeber>
thanks a lot! i will look into that
<qschulz>
mseeber: my pleasure, have fun!
<mseeber>
3rd party bsps are always fun ;)
<qschulz>
that's not the word I would have used :)
florian_kc has joined #yocto
<RP>
moto-timo: I don't think we show the output of the link I posted to in triage so vmeson's approach to addressing this may be better, not sure
frieder has quit [Remote host closed the connection]
mseeber has quit [Quit: Ping timeout (120 seconds)]
mseeber has joined #yocto
halstead[m] has joined #yocto
mseeber has quit [Quit: Ping timeout (120 seconds)]
<moto_timo[m]>
halstead: pretty sure shoragan was involved?
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 268 seconds]
hpsy has quit [Remote host closed the connection]
<shoragan>
moto_timo[m], hmm, according to the #libera-matrix topic, the bridge is up and running...
<halstead[m]>
shoragan: Could you respond the the bug asking for whatever detail might help?
mckoan is now known as mckoan|away
<shoragan>
halstead[m], hmm, need to create a bugzilla account first....
zpfvo has quit [Remote host closed the connection]
<RP>
halstead, shoragan: michaelo is here FWIW
<shoragan>
halstead[m], RP: i've replied to the bug
<RP>
shoragan: thanks
<shoragan>
michaelo, if you notice anything strange, you can also ping me here
<michaelo>
shoragan: thanks for your help.
<michaelo>
shoragan: the issue may be on my side, but on my Matrix client (element.io), the last message I see is the "shoragan: Could you respond..." one from almost 20 minutes ago.
<michaelo>
Anybody else on Matrix? khem? Do you have all the latest messages?
jmiehe has joined #yocto
mseeber has quit [Quit: Ping timeout (120 seconds)]
<shoragan[m]>
michaelo: It works fine for me.
<shoragan[m]>
And I'm on element.io as well.
<michaelo>
Just received all the messages in a burst. Maybe that's because my element.io client is dealing with more than one Matrix server at the same time (which I was surprised it could do). Let me check in a dedicated tab.
<shoragan|m>
This is from a federated matrix server.
<shoragan[m]>
So currently it seems to work fine at least for my two matrix accounts.
mseeber has joined #yocto
<halstead>
michaelo: Your last message on the Matrix side still hasn't arrived here. Hrmm..
<michaelo[m]>
Thanks for confirming this!
michaelo[m]1 has joined #yocto
<shoragan>
michaelo[m], your last message took a long time...
<michaelo[m]1>
Yes, indeed
<shoragan>
maybe federation between matrix.bootlin.com and libera.chat is not good?
<michaelo[m]1>
But not these two ones 🙃
<michaelo[m]1>
shoragan: right, that must be because of the way matrix.bootlin.com is configured.
<michaelo[m]1>
Because when I use my matrix.org account, everything just works smoothly.
<michaelo>
halstead, shoragan: many thanks for your help and for testing on your side. I can fix the bug now.
<shoragan[m]>
michael.o: check if your synapse instance has enough disk IO and RAM. we had similar issues last year when the stratum0.org instance was still running on HDDs.
vd has joined #yocto
<michaelo>
... while we address the matrix.bootlin.com issues.
<vd>
is do_image_squashfs_append_override supposed to work, given "override" is in OVERRIDES?
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<vd>
how can I append a task for a specific override?
jmiehe has quit [Quit: jmiehe]
<override>
how can I see what PACKAGECONFIG gets resolved to for openembedded-core/meta/recipes-gnome/gtk+/gtk+3.inc
<rpcme>
Is there an estimate of a target date for yocto-check-layer to go active for dunfell? I will want to ensure that I am available when it goes live "just in case"...
prabhakarlad has joined #yocto
<RP>
sakoman: see rpcme above
<sakoman>
rpcme: The patches were sent to the mailing list for review this morning. If there are no objections I'll send a pull request to Richard at end of day Monday, and they will go live once he takes the pull request
<sakoman>
The 3.1.10 QA report comes out tomorrow, so I have been avoiding pushing anything to dunfell just in case they find an issue at the last minute
<sakoman>
fwiw, meta-aws, meta-intel, and meta-openembedded all passed the check-layer-nightly build in my test branch
frieder has quit [Remote host closed the connection]
xtopher_ has quit [Ping timeout: 272 seconds]
ndec has quit [Ping timeout: 272 seconds]
nohit has quit [Ping timeout: 256 seconds]
fancer has quit [Ping timeout: 256 seconds]
georgem has quit [Ping timeout: 251 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
<yates_work>
there is a recipe for libffi in oe: meta/recipes-support/libffi/libffi_3.3.bb
xtopher_ has joined #yocto
<yates_work>
is there anything anywhere else in oe that depends on libffi being version 3.3?
<yates_work>
asked another way, is the mere presence of the libffi_3.3.bb recipe what establishes version 3.3 of libffi?
<yates_work>
i ask because i need to use a newer version
<rpcme>
sakoman: thank you very much - love the progress - will ensure I'm around Monday
georgem has joined #yocto
fancer has joined #yocto
<Xagen>
yates_work: I've upgraded versions before by simply changing the version in the recipe filename as that's what is used when it's pulling it from the repo
<Xagen>
yates_work: i've generally only ever had to do that and change checksums if it's not pulling from a git repo
<yates_work>
Xagen: thanks. so if you have version 3.3 in one layer and version 3.4 in another, yocto will choose the latest version?
vd has quit [Quit: Client closed]
ndec has joined #yocto
<Xagen>
you can set your PREFERRED_VERSION_libffi to your target version if there are multiple ones available
vd has joined #yocto
<vd>
FOO ??= "A" ; FOO_append = "B"; would FOO equal "AB"?
<kergoth>
yes
<vd>
ok, _append really happens after the assignment, regardless the assignment was weak or not.
amitk has quit [Ping timeout: 272 seconds]
rpcme has quit [Quit: Client closed]
yates_work has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
jwillikers has quit [Remote host closed the connection]