GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
gsalazar has quit [Ping timeout: 265 seconds]
ant__ has quit [Remote host closed the connection]
zpfvo has joined #yocto
Schlumpf has joined #yocto
lucaceresoli has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
mckoan|away is now known as mckoan
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
chep has quit [Ping timeout: 268 seconds]
sstiller has joined #yocto
<kriive>
Hey, I'm trying to add firewalld to my image, but it fails with ERROR: '/usr/sbin/nft add table inet firewalld' failed: Error: Could not process rule: Operation not supported
chep has joined #yocto
<kriive>
I fear that the nftables kernel module is not enabled
<kriive>
I tried to add a kernel-module-nf-table to PACKAGES, but Yocto doesn't seem to like it. This makes me wonder where should I look for kernel-modules
rob_w has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
mvlad has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Read error: Connection reset by peer]
<qschulz>
kriive: oe-pkgdata-util find-path '*.ko' and then add the package to your image
<qschulz>
most of the time the kernel-module-X package is auto-generated by the kernel recipe depending on .ko files it creates
<qschulz>
so 1) you don't use the correct name for the package in your image, or 2) nftable is built-in or disabled in your kernel, or 3) both 1 and 2
<kriive>
qschulz: thank you very much
chep has quit [Ping timeout: 250 seconds]
chep has joined #yocto
kroon has joined #yocto
kroon has quit [Client Quit]
kroon has joined #yocto
kroon has quit [Client Quit]
kroon has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
florian has joined #yocto
leon-anavi has joined #yocto
manuel1985 has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
adrian__ has joined #yocto
zpfvo has joined #yocto
adrian_ has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
oberon has joined #yocto
<oberon>
hi
<oberon>
I'm writing a recipe that compiles a makefile based source code
<kroon>
I'd question what the point of that check is
<RP>
also working for me
<RP>
kroon: before it existed, people would try running builds on machines which couldn't access the internet and it failed in non-obvious ways. That check was meant to allow network issues to be detected and reported to the user
<RP>
kroon: it is configurable so you can disable it if it bothers you
<kroon>
RP, ok, fair enough
<oberon>
How should I handle this:
<oberon>
ERROR: arad-1.0-r0 do_package: QA Issue: arad: Files/directories were installed but not shipped in any package:
<oberon>
/usr/sbin/.debug
<oberon>
/usr/sbin/.debug/aradrouterd
<oberon>
/usr/sbin/.debug/packetreader
<oberon>
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
<oberon>
arad: 3 installed and not shipped files. [installed-vs-shipped]
<JosefHolzmayrThe>
oberon: essentially you're experiencing all the reasons why hand-carving makefiles is a bad idea these days.
<oberon>
the make file doesnt have a line that creates it ?!
<oberon>
only 3 install lines that I pasted here
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
<JosefHolzmayrThe>
it maybe isn't obviously visible. and the Makefile certainly is more than those three lines.
<kroon>
oberon, the yocto post-install processing creates the .debug/ files, if thats what you're wondering
<oberon>
oh, how do I get rid of them ?
<oberon>
will they be in the final image ?
<JosefHolzmayrThe>
kroon: oh it does? interesting. then i guess that is usually packed away by the default FILES:* in the classes, which in turn doesn't show up when you're using raw makefiles?
<kroon>
they should be automatically put in a -dbg package
<kroon>
but it sounds like that is not happening here
<oberon>
maybe because of this line ? :
<oberon>
PACKAGES = "${PN}"
<qschulz>
oberon: well, that's lready not good so yes :)
<qschulz>
I assume we could replace the middle part of the code added in the commit you linked with a recusrive glob in files_from_filesvar
<qschulz>
now if it's going to impact the perfs (negatively or positively) I don't know and I'm not sure we care enough to try :)
<rburton>
less code in package.py is good
<rburton>
** is new in 3.5 so didn't exist when that code was added
<qschulz>
rburton: are you trying to get me hyped enough to try it :p ?
<qschulz>
rburton: and since we require >= 3.6 now...
<kroon>
Anyone chance someone will make bitbake 1.50 (hardknott) work with python 3.10 .. ?
<RP>
kroon: does master work and if so which patches need backporting?
<kroon>
RP, master doesn't work: ERROR: Variable NON_MULTILIB_RECIPES_append contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.
<oberon>
useradd: Warning: missing or non-executable shell '/bin/sh'
<jaskij[m]>
<qschulz> "mmmm, let's check, you might..." <- I'm using new syntax with Hardknott
<qschulz>
jaskij[m]: I answered right after with the link to the commit in hardknott allowing the new syntax, but I should have been a bit more explicit I can agree on that :)
rob_w has joined #yocto
<angolini>
is there any difference, in the new override syntax, that the order of remove is important?
<angolini>
I mean, VARIABLE:remove:machine and VARIABLE:machine:remove
<qschulz>
angolini: shouldn't change anything compared to the old syntax
<qschulz>
and yes, they are different
sakoman has joined #yocto
<qschulz>
understand "the order of remove always mattered"
<angolini>
oh! So this is something that I have to learn, because I thought they would act the same way
<qschulz>
angolini: old syntax but same logic applies
zpfvo has joined #yocto
<angolini>
<3
<qschulz>
if it does not, please tell us and/or open a bug, this shouldn't be the case (though there is some limitations added now (specifically, _append can't be followed by +=)) but if you followed best practices, you never used those anyway :)
<qschulz>
(and it results in an error so don't worry about missing this change)
zyga-mbp has joined #yocto
<qschulz>
I guess I need to revamp the talk and do a v2 next YP Days :)
<qschulz>
well, next next
<jaskij[m]>
urgh, seems like an update to meta-freescale caused my board to stop booting (newer dunfell commit)
<ernstp>
suddenly getting a lot of pseudo aborts when pulling in the latest dunfell updates
<manuel1985>
oberon: Did you check '/bin/sh' exists and is executable?
<kroon>
RP, i'll send a "bitbake/python3.10" series for hardknott/1.50 to bitbake-devel
akica has joined #yocto
oberon has joined #yocto
<kroon>
although im not sure wether the changes will be backwards compatible with the oldest supported hardknott distro
<oberon>
amm *cough*
<oberon>
anyone knows the answer to this ?:
<oberon>
[15:56:53] → davidinux has joined
<oberon>
[16:03:52] <oberon> I'm trying to add user with:
codavi has joined #yocto
<RP>
kroon: sounds good, thanks. I think most of these should be ok as long as they're python 3.6 compatible
akica has quit [Ping timeout: 265 seconds]
<kroon>
RP, I guess the autobuilder will test for that ?
<RP>
kroon: it probably would spot it, yes
<kroon>
RP, cool
rob_w has quit [Remote host closed the connection]
lucaceresoli has quit [Remote host closed the connection]
dmoseley has quit [Ping timeout: 268 seconds]
dmoseley has joined #yocto
michalkotyla has quit [Quit: michalkotyla]
<manuel1985>
oberon
<manuel1985>
I already replied to you
<oberon>
didnt notice, sorry
<manuel1985>
No worries
pgowda_ has joined #yocto
chep has quit [Ping timeout: 265 seconds]
chep has joined #yocto
sstiller has quit [Ping timeout: 250 seconds]
jmlemetayer[m] has quit [Quit: You have been kicked for being idle]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
kroon has quit [Quit: Leaving]
chep has quit [Ping timeout: 265 seconds]
chep has joined #yocto
dev1990 has joined #yocto
JavierPeces[m] has quit [K-Lined]
shoragan[m] has quit [K-Lined]
WadeBerrier[m] has quit [K-Lined]
doquiros[m] has quit [K-Lined]
dunfell[m] has quit [K-Lined]
jwillikers[m] has quit [K-Lined]
Emantor[m] has quit [K-Lined]
kayterina[m] has quit [K-Lined]
jaskij[m] has quit [K-Lined]
janvermaete[m] has quit [K-Lined]
JosefHolzmayrThe has quit [K-Lined]
Spectrejan[m] has quit [K-Lined]
Alban[m] has quit [K-Lined]
hmw[m] has quit [K-Lined]
AlejandroExojo[m has quit [K-Lined]
dwagenk has quit [K-Lined]
Perceval[m] has quit [K-Lined]
Artzaik[m] has quit [K-Lined]
glembo[m] has quit [K-Lined]
meck[m] has quit [K-Lined]
k4wsys[m] has quit [K-Lined]
alvaropg[m] has quit [K-Lined]
hpsy[m] has quit [K-Lined]
hjones2199[m] has quit [K-Lined]
barath has quit [K-Lined]
khem has quit [K-Lined]
banana_smoothie[ has quit [K-Lined]
berton[m] has quit [K-Lined]
lexano[m] has quit [K-Lined]
zagor has quit [K-Lined]
t_unix[m] has quit [K-Lined]
xicopitz[m] has quit [K-Lined]
olani[m] has quit [K-Lined]
filipm[m] has quit [K-Lined]
coldspark29[m] has quit [K-Lined]
ejoerns[m] has quit [K-Lined]
jonesv[m] has quit [K-Lined]
PascalBach[m] has quit [K-Lined]
jqua[m] has quit [K-Lined]
Jari[m] has quit [K-Lined]
Barry[m] has quit [K-Lined]
jordemort has quit [K-Lined]
ericson2314 has quit [K-Lined]
moto_timo[m] has quit [K-Lined]
agherzan has quit [K-Lined]
falk0n[m] has quit [K-Lined]
chep has quit [Ping timeout: 260 seconds]
<paulg>
$ bitbake cube-builder-initramfs
<paulg>
/usr/lib/python3.6/importlib/_bootstrap.py:219: RuntimeWarning: compiletime version %d. of module 'lxml.etree' does not match runtime version 3.6
<paulg>
I've seen this before --- so is it our job to clean up stale pyc files, or is it reasonable to expect python to do it ?
YogeshSiraswar_ has quit [Ping timeout: 264 seconds]
YogeshSiraswar_ has joined #yocto
dl9pf has quit [Ping timeout: 264 seconds]
rmmr has quit [Ping timeout: 264 seconds]
cengiz_io has quit [Ping timeout: 264 seconds]
NishanthMenon has quit [Ping timeout: 264 seconds]
Spectrejan[m] has joined #yocto
madisox has quit [Ping timeout: 264 seconds]
jordemort has joined #yocto
mithro has quit [Ping timeout: 264 seconds]
madisox has joined #yocto
Ad0 has joined #yocto
agrue has joined #yocto
dagmcr has quit [Ping timeout: 240 seconds]
ldts has quit [Ping timeout: 240 seconds]
bradfa has quit [Ping timeout: 256 seconds]
Crofton has quit [Ping timeout: 268 seconds]
nohit has quit [Ping timeout: 265 seconds]
ernstp has quit [Ping timeout: 264 seconds]
JPEW has quit [Read error: Connection reset by peer]
jonmason has quit [Read error: Connection reset by peer]
angolini has quit [Read error: Connection reset by peer]
rburton has quit [Read error: Connection reset by peer]
drewfustini has quit [Read error: Connection reset by peer]
elfenix|cloud has quit [Read error: Connection reset by peer]
rhadye has quit [Read error: Connection reset by peer]
georgem has quit [Read error: Connection reset by peer]
jamestperk has quit [Read error: Connection reset by peer]
YogeshSiraswar_ has quit [Read error: Connection reset by peer]
fancer has quit [Read error: Connection reset by peer]
thierryE has quit [Read error: Connection reset by peer]
flynn378 has quit [Read error: Connection reset by peer]
pgowda_ has quit [Read error: Connection reset by peer]
halstead has quit [Read error: Connection reset by peer]
smurray has quit [Read error: Connection reset by peer]
CosmicPenguin has quit [Read error: Connection reset by peer]
paulbarker has quit [Read error: Connection reset by peer]
aeroraptor has quit [Read error: Connection reset by peer]
oberon has quit [Quit: Client closed]
ldts has joined #yocto
moto-timo has quit [Ping timeout: 250 seconds]
kroon has joined #yocto
dl9pf has joined #yocto
madisox has quit [Ping timeout: 260 seconds]
rhadye has joined #yocto
CosmicPenguin has joined #yocto
Crofton has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
jonmason has joined #yocto
elfenix|cloud has joined #yocto
thierryE has joined #yocto
halstead has joined #yocto
ernstp has joined #yocto
madisox has joined #yocto
YogeshSiraswar_ has joined #yocto
JPEW has joined #yocto
bradfa has joined #yocto
fancer has joined #yocto
aeroraptor has joined #yocto
drewfustini has joined #yocto
zpfvo has joined #yocto
mithro has joined #yocto
rburton has joined #yocto
flynn378 has joined #yocto
angolini has joined #yocto
NishanthMenon has joined #yocto
cengiz_io has joined #yocto
dagmcr has joined #yocto
jamestperk has joined #yocto
paulbarker has joined #yocto
georgem has joined #yocto
camus1 has joined #yocto
nohit has joined #yocto
smurray has joined #yocto
pgowda_ has joined #yocto
kayterina[m] has joined #yocto
dwagenk has joined #yocto
ejoerns[m] has joined #yocto
Emantor[m] has joined #yocto
khem has joined #yocto
t_unix[m] has joined #yocto
moto_timo[m] has joined #yocto
shoragan[m] has joined #yocto
Barry[m] has joined #yocto
barath has joined #yocto
jonesv[m] has joined #yocto
jwillikers[m] has joined #yocto
hjones2199[m] has joined #yocto
zagor has joined #yocto
JosefHolzmayrThe has joined #yocto
AlejandroExojo[m has joined #yocto
hmw[m] has joined #yocto
ericson2314 has joined #yocto
berton[m] has joined #yocto
doquiros[m] has joined #yocto
hpsy[m] has joined #yocto
alvaropg[m] has joined #yocto
Jari[m] has joined #yocto
jqua[m] has joined #yocto
k4wsys[m] has joined #yocto
coldspark29[m] has joined #yocto
glembo[m] has joined #yocto
meck[m] has joined #yocto
dunfell[m] has joined #yocto
falk0n[m] has joined #yocto
PascalBach[m] has joined #yocto
filipm[m] has joined #yocto
Perceval[m] has joined #yocto
janvermaete[m] has joined #yocto
xicopitz[m] has joined #yocto
banana_smoothie[ has joined #yocto
jaskij[m] has joined #yocto
Artzaik[m] has joined #yocto
WadeBerrier[m] has joined #yocto
JavierPeces[m] has joined #yocto
olani[m] has joined #yocto
camus has quit [Ping timeout: 256 seconds]
agherzan has joined #yocto
camus1 is now known as camus
moto-timo has joined #yocto
<paulg>
(at the risk of stating the obvious - python isn't doing the cleanup itself)
lexano[m] has joined #yocto
Alban[m] has joined #yocto
<JPEW>
paulg: My understanding was that python would regenerate the pyc files if needed
zpfvo has quit [Ping timeout: 260 seconds]
<JPEW>
The time when you can get in trouble is when you have a pyc file without .py file it came from
rmmr has joined #yocto
<paulg>
I'm guessing I do things that other people dont encounter -- like keeping the same old build directory forever -- even across dist upgrades which change the python version.
<kroon>
paulg, that is brave you you
<paulg>
keeping the same build directory forever seems to be a good way to uncover all sorts of bitbake quirks and issues. :-P
<kroon>
*of you*
<paulg>
kroon, yeah - there is probably a component of self inflicted torture lurking in that decision if one digs deep enough.
<kroon>
paulg, I admire that. If only python devs were as disciplined as the kernel or glibc in not breaking API
lexano[m] has quit [Quit: Client limit exceeded: 20000]
jordemort has quit [Quit: Client limit exceeded: 20000]
shoragan[m] has quit [Quit: Client limit exceeded: 20000]
zagor has quit [Quit: Client limit exceeded: 20000]
Barry[m] has quit [Quit: Client limit exceeded: 20000]
ericson2314 has quit [Quit: Client limit exceeded: 20000]
Emantor[m] has quit [Quit: Client limit exceeded: 20000]
t_unix[m] has quit [Quit: Client limit exceeded: 20000]
lexano[m] has joined #yocto
Spectrejan[m] has quit [Quit: Client limit exceeded: 20000]
kayterina[m] has quit [Quit: Client limit exceeded: 20000]
barath has quit [Quit: Client limit exceeded: 20000]
jonesv[m] has quit [Quit: Client limit exceeded: 20000]
dwagenk has quit [Quit: Client limit exceeded: 20000]
florian has quit [Quit: Ex-Chat]
<vd>
Do you guys recommend a particular Amazon EC2 machine (within reason) to build?
jordemort has joined #yocto
Spectrejan[m] has joined #yocto
kayterina[m] has joined #yocto
Emantor[m] has joined #yocto
shoragan[m] has joined #yocto
dwagenk has joined #yocto
t_unix[m] has joined #yocto
zpfvo has joined #yocto
jonesv[m] has joined #yocto
zagor has joined #yocto
barath has joined #yocto
ericson2314 has joined #yocto
Barry[m] has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
GNUmoon has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
<JPEW>
vd: I'd recommend 8-16 CPUs and at least 2GB RAM per CPU
<ad__>
is there a way to set a layer as compatible with dunfell without touching the layer layer.conf ?
prabhakarlad has quit [Quit: Client closed]
<JPEW>
ad__: You *might* be able to override `LAYERSERIES_COMPAT_your-layer` from somewhere... but I wouldn't really recommend it
<smurray>
it does work, I've appended LAYERSERIES_COMPAT_layer in bblayers.conf for one of the layers we pull into AGL (meta-aac from alexa-auto-sdk)
<smurray>
definitely should be considered a very last resort, though
<ad__>
JPEW: mmm ok. i have meta-imx compatible with "zeus warrior gatesgarth" but not dunfell
<smurray>
ad__: for a BSP layer like that, you might be opening up a bigger can of worms wrt compatibility
<ad__>
smurray: ok. What you suggest ? To move all other layers to gatesgarth ?
<smurray>
ad__: if that's an option for you, it'd definitely be better wrt expectations of things working and the chances of getting help (though not necessarily support, since gatesgarth is now EOL)
<smurray>
ad__: another thing to maybe look at is if you can get by with just meta-freescale instead of using meta-imx on top
<ad__>
smurray: thanks
<smurray>
ad__: looking at meta-imx, they do have a couple of hardknott release branches, from a support perspective one of those would likely be better, hardknott EOL was just pushed to March 2022
<smurray>
ad__: though you jump to a 5.10 kernel with either gatesgarth or hardknott, which might be effort depending on what your h/w is
<kroon>
smurray, oh, how come ?
<kroon>
(hardknott EOL)
<smurray>
kroon: I believe it was described as "by community request" on the call on Tuesday and the status sent to the ml
<kroon>
smurray, ok
manuel1985 has quit [Quit: Leaving]
<kroon>
hmm which mailing list ?
<smurray>
kroon: Stephen sends the Yocto weekly status to oe-core & yocto mls
mvlad has quit [Remote host closed the connection]
kroon has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
troth has joined #yocto
<sgw>
JPEW: Hi There, just wanted to let you know that I am making slow progress on the kernel spdx work. I have DEBUG_INFO getting built correctly and whacked on package.bbclass to get splitting and stripping working! I have been able to get vmlinux.spdx.json to populate with a files list(in comments), but not the actual file reference yet. Looks like we need to deal with getting spdx to understand work-shared better (and deal with generate
<sgw>
d code).
<JPEW>
sgw: Excellet!
<sgw>
Oh and then deal with kernel-modules!
vd has quit [Quit: Client closed]
vd has joined #yocto
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
<paulg>
best kernel patch I ever did - making module support optional.
xmn has joined #yocto
<jaskij[m]>
I thought it was configurable via kconfig?
chep has quit [Ping timeout: 264 seconds]
florian has quit [Ping timeout: 268 seconds]
chep has joined #yocto
florian has joined #yocto
Tokamak has joined #yocto
<paulg>
it is - because I made it so - circa 1995.
<Tokamak>
What does it mean when a task is both covered and notcovered?
chep has quit [Ping timeout: 264 seconds]
kiran has quit [Ping timeout: 264 seconds]
florian has quit [Ping timeout: 264 seconds]
chep has joined #yocto
leon-anavi has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 260 seconds]
amitk has joined #yocto
<bq>
Hi all, I've noticed that setting REPRODUCIBLE_TIMESTAMP_ROOTFS causes a kernel rebuild - is this a bug or a feature? looks like the do_kernel_compile task's hash would depend on this variable even if it's not used because the SDE comes from kernel git
<bq>
Can I somehow mark the variable as not feeding into the task hash?
<JPEW>
bq: That's kinda on purpose since it's the fallback if the kernel repo is not a git repo
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
<JPEW>
moto-timo: Well, I tried to get squeekboard to compile.... and it's a mess. It's dynamically generating a Cargo.toml file from meson... I don't even know how to reasonable deal with that in a recipe
florian has joined #yocto
chep has quit [Ping timeout: 256 seconds]
<vd>
Do you need to set PREFERRED_PROVIDER_psplash even though you choose your target package with the image SPLASH variable?
chep has joined #yocto
<moto-timo>
JPEW: not too surprised. I don’t even remember how far I got. It was roughly the same time kanavin said it was too aggressive about taking over user input
<JPEW>
Ah. It's failing to fetch crates. Perhaps that's on purpose? I'm trying to see if I can build it locally to generate the crate:// definitons for the SRC_URI
troth has quit [Ping timeout: 268 seconds]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
adrian__ has quit [Ping timeout: 265 seconds]
angolini has quit [Quit: Connection closed for inactivity]
troth has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
Jdrol has quit [Quit: Leaving]
codavi has quit [Ping timeout: 256 seconds]
troth has quit [Ping timeout: 240 seconds]
<armpit>
have you seen all the creates pilled up in Long Beach?