jwillikers has quit [Remote host closed the connection]
linkliu59 has quit [Quit: Lost terminal]
linkliu59 has joined #yocto
boo has quit [Ping timeout: 272 seconds]
amitk has joined #yocto
goliath has joined #yocto
rob_w has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
frieder has joined #yocto
Fanfwe42 is now known as Fanfwe
frieder has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
g0hl1n has joined #yocto
g0hl1n has quit [Client Quit]
g0hl1n has joined #yocto
g0hl1n has quit [Client Quit]
g0hl1n has joined #yocto
goliath has quit [Quit: SIGSEGV]
frieder has joined #yocto
goliath has joined #yocto
ykrons has joined #yocto
bizulk has joined #yocto
Vonter has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
florian has joined #yocto
Bardon has joined #yocto
<Bardon>
Hello, I'm trying to build an image which has dropbear in it and I'd like to enable key based authentication and disable password authentication
<Bardon>
I'm very new to yocto poky. This is my first time compiling it
<Bardon>
I have a meta/recipes-core/dropbear/ directory, in which there is a dropbear.inc file. I added a few lines in do_install(): "mkdir -p ${D}/home/root/.ssh/; echo "my_key" > ${D}/home/root/.ssh/authorized_keys:"
<Bardon>
I also added "DROPBEAR_EXTRA_ARGS="-s"" to disable password authentication in dropbear/init
<Bardon>
I tried compiling this module with bitbake -b but I get "QA Issue: dropbear: Files/directories were installes but not shipped /home /home/root /home/root/.ssh /home/root/.ssh/authorized_keys"
<Bardon>
installed*
<Bardon>
Running the command I used to build the whole image (bitbake asus-image) doesn't seem to recompile any module
<Bardon>
So I'm wondering, did I do anything wrong? Can anyone help me?
<Bardon>
I added "FILES_${PN} += "/home /home/root /home/root/.ssh /home/root/.ssh/authorized_keys"". It doesn't complain anymore, yet `bitbake asus-image` still doesn't seem to recompile any module
<Bardon>
And I don't know if I'm doing this right
<paulbarker>
Bardon: where did you add that FILES_${PN} setting?
<Bardon>
paulbarker: Right after the do_install() function, in meta/recipes-core/dropbear/dropbear.inc
<paulbarker>
Bardon: Ok. Does the dropbear recipe include that .inc file? Are you modifying this directly in the core layer or are you putting the modifications in your own layer?
<Bardon>
paulbarker: The dropbear recipe is the .bb file, right? If so, I have "require dropbear.inc" in the .bb file next to it
<Bardon>
paulbarker: I'm not familiar with layers. I'm in meta/recipes-core/dropbear/. Since it says "recipes-core", could I be in the core layer?
<paulbarker>
Bardon: By "core layer" I mean the openembedded-core or poky repositories
<Bardon>
This is a few years old I believe so this may have changed on poky's side
<paulbarker>
Bardon: The best people to give advice on that is your vendor then
<paulbarker>
I can give a couple of general tips though
<Bardon>
I'm on my own on this one I believe. There's no support from raptorengineering anymore I believe
<paulbarker>
If you look in ${TMPDIR}/work/<arch>/dropbear/<version>/temp, you should see log.do_install & run.do_install files, check those. Particularly check if your commands appear in the run file
<paulbarker>
You can also run `bitbake -e dropbear` to dump the bitbake environment (all variables and functions). Pipe that to a file and look at it to see if your modifications are applied
<paulbarker>
I also recommend following some tutorials on how to create your own layer and use bbappend files. It's not trivial but a few days of learning will get you a long way
<Bardon>
paulbarker: tmp/work/armv5e-poky-linux-gnueabi/dropbear/2014.66-r0/ only has an empty build directory. bitbake -e dropbear show my modified do_install() function
UmbrellaMan has quit [Quit: Client closed]
<Bardon>
paulbarker: Thanks a lot for your help :). I'll look into what you said
<Bardon>
Bbye
<wyre>
could I prevent to build the tar image file?
<qschulz>
wyre: don't have it in IMAGE_FSTYPES :)
<wyre>
qschulz, I'd say I haven't it ... but in my local.conf I have IMAGE_FSTYPES += "ubifs wic"
<wyre>
so I'm not sure if some recipe is bringing tar to IMAGE_FSTYPES
<qschulz>
wyre: bitbake -e <image recipe> and look for IMAGE_FSTYPES in it
<qschulz>
also, try to avoid using += in local.conf, use _append instead
<wyre>
qschulz, I can see IMAGE_FSTYPES=" ubifs wic tar.xz ubifs" but also IMAGE_FSTYPES_DEBUGFS="tar.gz"
<wyre>
I'm not sure why is ubifs duplicaded and algo which one is actually producing the tar file
<wyre>
well apparently both, because there are a tar.xz and tgz files 🤔
<qschulz>
wyre: just read above this line and you'll see the history of the variable
<wyre>
qschulz, well, I can see this https://bpa.st/FSHQ so apparently the machine conf file is appending tar.xz and ubifs, ... but where come from wic.bmap and wic.gz ?
<qschulz>
wyre: SOC_DEFAULT_IMAGE_FSTYPES
jmiehe has joined #yocto
<wyre>
qschulz, apparently when I don't set IMAGE_FSTYPES in local.conf wic image cannot be built https://bpa.st/RHOQ
<qschulz>
where did you set it?
<wyre>
qschulz, I didn't set it
<wyre>
but when I don't set it I can see it's set as IMAGE_FSTYPES="wic.bmap wic.gz tar.xz ubifs"
<qschulz>
probably an incorrect dependency in wic.gz or wic, you're missing the wks file which is required to build wic, and since wic.gz will build wic before compressing it (I assume), it fails
<qschulz>
if you want to remove tar.gz from the IMAGE_FSTYPES, you can override IMAGE_FSTYPES in your image recipe or machine configuration file
jmiehe1 has joined #yocto
<wyre>
qschulz, and what about the local.conf?
<qschulz>
wyre: what's the question?
jmiehe has quit [Ping timeout: 272 seconds]
jmiehe1 is now known as jmiehe
<wyre>
qschulz, if I could override IMAGE_FSTYPES in the local.conf
<wyre>
and how could I fix the wic dependency problem?
<wyre>
I mean, where am I missing the wks file? 🤔
<qschulz>
wyre: no, because your machine configuration is setting it and the machine configuration file is parsed after local.conf IIRC
<qschulz>
wyre: question to ask your vendor, but just add wic for now if it fixes it
<qschulz>
wyre: you could also add IMAGE_FSTYPES_remove = "tar.gz" to your local.conf but it's really not best practice
<qschulz>
(especially since you're not supposed to share your local.conf, so it's going to be lost for other devs or your build systems)
<wyre>
qschulz, so you do recommend me to set it in my image recipe, right?
<wyre>
to override it, I mean
<qschulz>
wyre: if you never want it for a given recipe, you should probably have your own machine configuration file that sets it correctly instead of your image recipe
jwillikers has joined #yocto
<wyre>
qschulz, just appending the .wks file doesn't solve the problem 🤔
<wyre>
maybe I should nuke the whole tmp folder 🤔
<wyre>
I've tried the clean command but it doesn't remove the images folder so I've used clean and remove manually the images folder
<qschulz>
wyre: appending the wks file to what?
<wyre>
qschulz, appending wic to IMAGE_FSTYPES
<wyre>
sorry, I meant appending wic to IMAGE_FSTYPES
<qschulz>
wyre: because you probably removed the wks file provided by the recipe and didn't force a deploy again
<qschulz>
just don't modify or remove things from the deploy dir
<wyre>
how can I force the deploy?
<qschulz>
clean the recipe and rebuild it I guess?
<wyre>
that's what I did, but removing the images folder
<qschulz>
but you'll just run into problems until you've done that for all missing artifacts in the deploy dir
<qschulz>
wyre: no, I assume you did that only for the image recipe
<qschulz>
you'd need to do that for the recipe providing the wks file too
<wyre>
qschulz, you mean the clean?
<qschulz>
yes
ljh has joined #yocto
<ljh>
Good morning/evening/afternoon, folks!
<wyre>
qschulz, and how can I figure out which one is that recipe?
<qschulz>
wyre: grep's your friend I guess
georgem has joined #yocto
<wyre>
qschulz, well, I guess it must be this one tmp/deploy/images/imx6ull-microgea/joifi-displays-imx-uboot-bootpart.wks
<wyre>
since I've nuked the whole tmp/deploy/images/imx6ull-microgea/ folder
UmbrellaMan has joined #yocto
jwillikers has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 272 seconds]
frieder has joined #yocto
bizulk has quit [Quit: Client closed]
otavio_ has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
argonautx has joined #yocto
yates_work has quit [Ping timeout: 252 seconds]
Acki has joined #yocto
vd has joined #yocto
<vd>
hi all -- the parent folder recipe-* doesn't matter for the location of a .bbappend file, right?
<vd>
It doesn't have to match the original path, for example I can place all my bbappend in recipes-append if I want to, correct?
ljh has quit [Quit: Client closed]
<qschulz>
vd: correct, it should just be in a path matching the BBFILES globs
<qschulz>
of the layer in which they are (can be found in conf/layer.conf of said layer)
<vd>
perfect
<qschulz>
vd: you anyway can check with bitbake-layers show-appends IIRC
<vd>
I'm using overrides and bbappend files, but it looks like the image I'm running isn't the appended one. How can I make sure the changes are applied?
<vd>
qschulz: :)
<qschulz>
you can check the value of variables and tasks/functions after parsing by running bitbake -e <recipe>
frieder has quit [Ping timeout: 256 seconds]
<vd>
thanks
<vd>
I have SSTATE_DIR outside of TOPDIR, every time I rm -rf build/ and rebuild, linux-ti-staging recompiles. It doesn't seem expected. Any idea?
<qschulz>
vd: bitbake-diffsigs to start debugging the issue, but no, no idea on my side
<vd>
bitbake -e <recipe> is like the very final instructions for a recipe?
<vd>
like a very basic bitbake implementation could do `bitbake -e recipe > recipe.bb; bitbake ./recipe.bb`?
<vd>
s/implementation/wrapper/
frieder has joined #yocto
<vd>
qschulz how's diffsigs supposed to work? should I build, dumpsig, rm rebuild and compare?
<qschulz>
save the sigdata which is in stamps directory IIRC
<qschulz>
rm
<qschulz>
then rebuild
<qschulz>
then diffsigs between both sigdata
yates_work has joined #yocto
<yates_work>
if a layer has a <name>.bbappend file, will that bbappend be applied to any version of <name>.bb? e.g., <name>_0.4.2.bb ?
<yates_work>
this appears to be the way it works, but i don't see that operation documented in the bitbake manual
<vd>
yates_work <name>_%.bbappend
<yates_work>
vd: yes, i see that's the normative way to do things. but i've created a <name>.bbappend and it is getting applied to <name>_0.4.2.bb
<yates_work>
is that a quirk?
<yates_work>
unadvertised feature? :)
<yates_work>
basically, i screwed up and found it worked!
<yates_work>
now i'm wondering why.
Acki has quit [Ping timeout: 246 seconds]
<yates_work>
specifically i'm working with poky/meta/recipes-devtools/meson/meson_0.55.1.bb. i created a poky/meta-csky/recipes-devtools/meson/meson.bbappend and it's working
<yates_work>
it has a "BBCLASSEXTEND" - i wonder if that somehow impacts how .bbappends are applied?
otavio has joined #yocto
<yates_work>
or maybe in bitbake's logic <name>.bbappend is taken to be <name>_%.bbappend?
<qschulz>
yates_work: bitbake -e meson, you'll be able to check that you really are using 0.55.1 version, and also that your bbappend is applied (with the variable history of e.g. BBCLASSEXTEND)
<yates_work>
qschulz: ok thanks - i will check it out.
<vd>
I split my custom image recipes into multiconfig appending a single generic image recipe, and total tasks went from ~5k to ~15k tasks :-S
<qschulz>
why are you using multiconfig?
sakoman has joined #yocto
<vd>
qschulz because I have various build variants, they are combinations of a machine and image tweaks for different customers (like forcing a specific package version or tweaking default values like user passwords)
<qschulz>
vd: I don't think that's a good use of multiconfig
<qschulz>
for me multiconfig is for when you have a product with multiple SoCs involved, e.g. one with some cortex-axx cores running Linux, and another possibly MCU only running something else
<qschulz>
the description of your "issue" seems to be what most people do? You just build Yocto multiple times, have separate image recipes, possibly distro and/or machine configuration files
<qschulz>
if the distro and machines are identical, you can build multiple image recipes at once by passing them to bitbake directly (it can take more than one recipe as argument)
<vd>
but since multiple build should ideally use different TMPDIR and the machine may vary, why not using multiconfig with a single bitbake invokation rather than wrapping multiple calls to bitbake with custom local.conf changes every time?
<vd>
At the moment I use kas and I could indeed have one .yml file per build variant (a.k.a. customer), but I figured using bitbake's native support for a multiconfig (referred by BB_CURRENT_MC) with its own TMPDIR and OVERRIDES was quite elegant
sgw has joined #yocto
<vd>
qschulz: also appending a common recipe avoids duplicating every recipes for every variants
matthiasklein has joined #yocto
<matthiasklein>
I want to create an image which I can specify to QEMU with the -sd option. Without "qemu-img resize ... 1024M" I get the error message: SD card size has to be a power of 2. Is it possible to specify the exact size of a WIC image?
goliath has quit [Quit: SIGSEGV]
Guest26 has joined #yocto
<RP>
michaelo: Am I up to date with the bitbake patches for the docs? Also, we're ready for the docs override translation
berton[m] has joined #yocto
<michaelo>
Hi RP. No I believe you're missing a few. Thanks for asking. I'll highlight the ones I'm missing in a private reply.
<RP>
michaelo: if you want to put together a branch somewhere... :)
<RP>
michaelo: I thought it easier just to ask which I was missing!
RobertBerger has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
<RP>
smurray: correct, as things stand those are just variables
<kergoth>
marcus65: sounds like you need to update your bitbake
<smurray>
RP: okay, just wanted to double-check I wasn't missing something
davidinux has joined #yocto
<marcus65>
kergoth: BitBake Build Tool Core version 1.46.0
<marcus65>
kergoth, this is the latest, no?
<RP>
smurray: making the overrides would be kind of cool but probably for another time
<kergoth>
it's nice that it's actually clear when overrides are used and when not, now
<smurray>
RP: at least post-conversion it can be assumed they're just variables ;)
<smurray>
oops, ninja-ed
argonautx has quit [Quit: Leaving]
<kergoth>
marcus65: not even close, no. you can't use an old stable branch bitbake with oe-core master, that's a branch mismatch
<kergoth>
marcus65: bitbake master is 1.51.1
<marcus65>
kergoth: thanks, I'll update and try again
<RP>
kergoth: I think it will raise some questions but yes, good questions to raise in some cases!
<kergoth>
yeah, there's clearly cases where we might or might not want to use it, but at least it's obvious which is the case now :)
<RP>
kergoth: I'm kind of dreading my inbox having pushed this...
<kergoth>
i'm sure there'll be fallout and complaining, because there always is with anything like this. i just hope we don't get too many folks refusing to leave an LTS now
<RP>
kergoth: right, the bigger risk in my mind is we get too afraid of change
* RP
is finding there are some nasty bugs buried in bugzilla reports :/
<yates_work>
i am sorry to report that i was totally screwed up. my filename was the expected meson_0.55.1.bbappend and not meson.bbappend
<qschulz>
yates_work: :) Case of the mondays :)
<yates_work>
in my defense, i believe i was looking at some stale emacs buffer and had tried meson.bbappend at one point.
<yates_work>
qschulz: yah, i'll go with that!
matthiasklein has quit [Quit: Client closed]
<kergoth>
recipetool newappend -e or devtool edit-recipe can be of use :)
<yates_work>
new question: is there a patch utility, outside of git, that takes as input two files and generates a patch usable by yocto?
<kergoth>
oh, now i want to watch office space. it's been a while
<kergoth>
yates_work: diff -urNd
<yates_work>
kergoth: thanks i'll give it a go
<kergoth>
N handles missing files, r recurses for directories, u is unified format, -d tries to minimize the set of changes
<yates_work>
+1
<kergoth>
for just two single files, diff -u will do
<kergoth>
that's the key, unified, not context format
<yates_work>
ha
<yates_work>
aha
<yates_work>
ok
<smurray>
RP: checking conversion after running the script on meta-agl, it did touch variables in a sub-layer layer.conf, might need to mask that out
<smurray>
RP: and I notice it's touched some blah/blah_arm64 paths inside quote strings in variable definitions
<smurray>
RP: but since it's documented that manual verification is required, not a big deal, maybe
zpfvo has quit [Quit: Leaving.]
<RP>
smurray: it is definitely not intended to be 100% automated
Guest4565 has joined #yocto
Guest4565 is now known as thierryE
ant__ has quit [Ping timeout: 272 seconds]
ant__ has joined #yocto
thierryE_ has joined #yocto
thierryE_ has quit [Client Quit]
thierryE has left #yocto [#yocto]
thierryE_ has joined #yocto
thierryE_ has quit [Client Quit]
thierryE_ has joined #yocto
thierryE_ has left #yocto [#yocto]
florian has quit [Quit: Ex-Chat]
hpsy has quit [Read error: Connection reset by peer]
thierryE has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
falk0n[m] has joined #yocto
Acki has quit [Ping timeout: 246 seconds]
UmbrellaMan has quit [Quit: Client closed]
<override>
ive tried bitbake -e etc but I cant figure out what recipe writes boot.scr
marcus65 has quit [Quit: Client closed]
Tokamak has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
florian_kc has joined #yocto
<override>
the partitions I setup using .wks file should be showing up under .dev on the board?
dtometzki has quit [Remote host closed the connection]
dtometzki has joined #yocto
florian_kc has quit [Ping timeout: 272 seconds]
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
<override>
can someone give me the idea behind mkimage ? iv usually only dealt with python packages, maybe thsts why I havent come across it before?
kroon has joined #yocto
Tokamak has quit [Ping timeout: 258 seconds]
<kroon>
I think the new warning messages about the old-style overrides needs to mention which file is causing the warning
<kroon>
"ERROR: Variable PACKAGECONFIG_append_pn-qemu-system-native contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake."
<smurray>
having hit that earlier, at least that one's not commonly used ;)
<smurray>
on a side note, if you've a custom local.conf template that sets that, bump CONF_VERSION to "2" while you're in there, as that's also required now
Tokamak has joined #yocto
_whitelogger has joined #yocto
<khem>
RP: finally I have glibc 2.34 upgrade under control, so today I updated to use new override syntax, its quite a bunch of changes but Martin has done soem prework so it helped, finally I am on way to build an image
<khem>
RP: in meta-oe we have SRCREV_opencv = "xxx" etc. should they change as well to SRCREV:opencv and so on ?
<kroon>
Xagen, if nothing else, "bitbake $(shell-magic-to-find-python-recipes) -c cleanall"
<Xagen>
that's basically the route i ended up going with as there didn't seem to be anything built in
florian_kc has joined #yocto
<khem>
Xagen: bitbake does not support wildchars for targets
<Xagen>
khem: thanks for the confirmation. i didn't find anything, but just wanted to make sure that was indeed the case.
<kroon>
smurray, yeah thanks for the reminder, i did need to refresh my local.conf aswell
xmn has joined #yocto
<RP>
khem: If opencv is used in OVERRIDES yes
<RP>
khem: It is a bit of work but hopefully manageable and worthwhile in the end
<RP>
khem: I tried the 2.34 patch but I think a patch I merged in master conflicts :/.
Tokamak has quit [Ping timeout: 240 seconds]
kroon has quit [Quit: Leaving]
Tokamak has joined #yocto
bps has quit [Ping timeout: 252 seconds]
lexano has quit [Ping timeout: 250 seconds]
Acki has joined #yocto
lexano has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
bluelightning has quit [Quit: Konversation terminated!!!111]
<khem>
yeah try the contrib branch
<khem>
RP: I realized that this will require us to create release specific branches for own layers, so far we have been keeping single branch working across multiple oe releases
<khem>
but that also has its own downsides
<khem>
I also see lot of BSP layers using similar model so it will take a while for these changes to travel to all layers
nerdboy_ is now known as nerdboy
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<smurray>
khem: hopefully dunfell and newer being forward compatible helps with that?
<khem>
how does that help
<RP>
khem: you can use the new syntax with older bitbakes as long as they're updated to the version on that series
<khem>
yeah one way it will but not two way :)
<khem>
has anyone adapted bitbake.vim
Tokamak has joined #yocto
<RP>
khem: hmm, that will probably need tweaking
<smurray>
RP: I've got meta-agl-core converted and building, but am seeing a runtime issue with one of the test images that I'm trying to pin down (might be some other change in poky master in the last week)
<RP>
smurray: hmm, what kind of issue?
<smurray>
RP: weston doesn't start in our agl-image-weston. I couldn't reproduce with core-image-weston in a standalone build, so I'm a bit puzzled
<smurray>
RP: by standalone build I mean poky on its own
<RP>
smurray: hmm, that doesn't sound very specific :/
<RP>
smurray: comapred the image manifests before/after?
<smurray>
RP: I took a glance at it and didn't see anything obvious by eye, I'll diff once I finish a test build that's running now of pre-syntax change
Tokamak has quit [Read error: Connection reset by peer]
<RP>
abelloni: I think the current -next build tagged for swat may have an issue with the datastore fix in mesa :/
<RP>
I'll look tomorrow
rpcme78 has joined #yocto
rpcme has quit [Ping timeout: 246 seconds]
florian_kc has quit [Ping timeout: 272 seconds]
rpcme78 has quit [Quit: Client closed]
rpcme has joined #yocto
Acki has quit [Ping timeout: 246 seconds]
<rpcme>
I'm working on master-next so I can rework a layer for the override change. When using bitbake on a clean run it's fine but when I run the target immediately after I'm getting a bad cache error. Any thoughts? https://gist.github.com/rpcme/0610933ead37412d21393948f0ed722d
jwillikers has joined #yocto
<rpcme>
so I went back to master and it seems like meta-openembedded has this problem ... I giess will need to fix local: meta-openembedded/meta-oe/conf/layer.conf:NON_MULTILIB_RECIPES_append = " crash"
jwillikers has quit [Remote host closed the connection]
<rpcme>
Now I have this: ERROR: Layer openembedded-layer is not compatible with the core layer which only supports these series: honister (layer is compatible with hardknott)
<rpcme>
guess go back the master-next and just remove all the build directories for every test :(