<agherzan>
And from there I would expect only very minor things to deal with on the image side.
<LetoThe2nd>
agherzan: thanks!
<agherzan>
Sure.
<agherzan>
LetoThe2nd: keep in mind that there could be another moving part on your board - the firmware version on EEPROM.
simonew has joined #yocto
<agherzan>
I'd look into that only if things don't work as you expect.
<LetoThe2nd>
agherzan: okay, understood. I just wanted to get a rough idea of the state. because if there are hard blockers ahead I'd like to rather not waste time on it :)
<amahnui[m]>
> amahnui: then you know where to look for next changes to be made: scripts/oe-setup-builddir line 45 in poky git repo
<RP>
amahnui[m]: since that is a patch to openembedded-core and not the docs, there is a different mailing list that needs to go to
<RP>
amahnui[m]: also, you need to have a look at the submitting patches docs as you need to write a proper summary line for the patch
<amahnui[m]>
> amahnui: since that is a patch to openembedded-core and not the docs, there is a different mailing list that needs to go to
<amahnui[m]>
RP Your'e right. I will delete that one right away and direct it to the `openembedded-core@lists.openembedded.org` I think
<amahnui[m]>
> amahnui: also, you need to have a look at the submitting patches docs as you need to write a proper summary line for the patch
<amahnui[m]>
I will do that right away before sending the next patch
<RP>
amahnui[m]: you don't need to quote me here on irc, you can just reply using my nickname as a prefix as you've been doing
bonalais has joined #yocto
<amahnui[m]>
RP: Okay I understand
bps has joined #yocto
bps has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
huseyinkozan has joined #yocto
kranzo has quit [Quit: Client closed]
<LetoThe2nd>
is it normal for bitbake core-image-minimal -cdo_image_bootimg -Sprintdiff to crank away for minutes?
camus has quit [Ping timeout: 272 seconds]
<RP>
LetoThe2nd: usually it will take around two parse times
<RP>
that code doesn't function well :(
<LetoThe2nd>
still, something feels fishy about it. my local run, that is.
Schlumpf has quit [Ping timeout: 250 seconds]
<BignauxRonan[m]>
i still can't find a compatible qemu cpu to pass glib-2.0 configure test with meson qemuwrapper thing. if anyone has idea of disable such test for uncompatible machine.
<rburton>
why do you need to run glib checks in qemu?
<BignauxRonan[m]>
that's meson build that do that ..
<BignauxRonan[m]>
glib use now meson, and meson checks with qemu to look if elf is runnable
<rburton>
our glib has been using meson for a long time
<rburton>
it knows its in a cross build and doesn't run things
<qschulz>
amahnui[m]: if there are changes to the patch/commit title/commit log, a newer version needs to be sent instead of just answering to the original mail with a modified version
<rburton>
setting a qemu wrapper complicates things because qemu isn't perfect
<BignauxRonan[m]>
i don't write it, that's default behavior
<rburton>
BignauxRonan[m]: i guarantee you that out of the box in yocto, glib doesn't try to run stuff in qemu
<LetoThe2nd>
rburton: and in the box? (badum-tsh!)
<LetoThe2nd>
RP: the fun part is that the diffsigs seems to block forever on "writing locked sigs to ... .inc"
<amahnui[m]>
After the `source oe-init-build-env` command worked, I ran `bitbake core-image-sato` and got the error `ERROR: The bblayers.conf file doesn't contain any BBLAYERS definition`. after checking the file, I found out that the bblayers.conf file was empty
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
<rburton>
sounds like the bit of code that writes the initial bblayers.conf needs to handle whitespace in directories too
alicef has quit [Quit: install gentoo]
<amahnui[m]>
rburton: Please which code handles that, So I can check it and try to solve it.
alicef has joined #yocto
GNUmoon has joined #yocto
<rburton>
amahnui[m]: the same code, oe-setup-builddir specifically
<rburton>
note that the code checks for a file existing at all, so you'll likely want to delete the existing build directory each time as you fix issues
<amahnui[m]>
rburton: thanks I'll get on it right away
<rburton>
hm definitely seeing rust-native build more often than i'd like
<rburton>
i swear it just rebuilt because i changed target distro features
jclsn90 is now known as jclsn
<amahnui[m]>
rburton: please are you speaking about the bblayers.conf error?
<rburton>
no
<amahnui[m]>
Okay I'm asking beacause I was somehow lost
<RP>
rburton: we should audit it's hash data
Guest11 has joined #yocto
selff has joined #yocto
<selff>
hi, everyone
<selff>
when i write yocto image to 16gb sd card with wic --auto expend option, the filesystem can only use 7gb. does not expand the rest of the space. i have x6 100mb partitions. i want all the remaining space to go to filesystem. what could it be caused by?
Guest11 has quit [Quit: Connection closed]
<rburton>
RP: hm, fun. poky.conf uses package_ipk by default but the local.conf in poky uses package_rpm
<rburton>
so if you use poky but not the template local.conf you get different behaviour
kroon_ has quit [Quit: Leaving]
Schlumpf has joined #yocto
prabhakarlad has joined #yocto
xmn has joined #yocto
kroon has joined #yocto
<LetoThe2nd>
RP: diffsigs is now stuck since an hour or so.
MrSaturn has quit [Quit: leaving]
kroon has quit [Quit: Leaving]
codavi has joined #yocto
<RP>
LetoThe2nd: obviously something badly wrong there :(
<RP>
rburton: hmm, that isn't expected
<LetoThe2nd>
RP: might be related to docker. maybe i'll actually find it.
<vvn>
rburton: following yesterday's conversation about the distro being the integration point, if you have a proprietary product using a open-source distro, would you write your own distro based on the public one, similar to how poky-altcfg requires poky.conf?
ar__ has joined #yocto
<rburton>
if you're actually deriving from it, sure
codavi has quit [Ping timeout: 250 seconds]
selff has quit [Ping timeout: 250 seconds]
hushmoney has joined #yocto
sakoman has joined #yocto
rob_w has quit [Remote host closed the connection]
<RP>
I'm thinking, pseudo fix, lidsdl unwind dependency removal, the apt patches but not the test and then build rc1 ?
<LetoThe2nd>
RP: thinking is overrated.
simonew has quit [Ping timeout: 250 seconds]
<sgw>
RP: abelloni: Ignore the patches I just sent!
<sgw>
too early to be sending those emails.
<tgamblin>
zeddii: hypothetically, how much of a pain would it be to add features/nf_tables/nf_tables.scc to the linux-yocto KERNEL_FEATURES list in a future release?
<zeddii>
tgamblin. it's easy enough to do, but if we add it by default, it should be to support some sort of core functionality, or be enabled by distro/machine configuration.
<tgamblin>
zeddii: Right now I am only aware of iptables-nft relying on it in oe-core, which is not (yet) the default build for that recipe
bonalais has quit [Quit: Connection closed for inactivity]
GLumen has joined #yocto
GLumen_ has joined #yocto
Schiller has quit [Ping timeout: 250 seconds]
<LetoThe2nd>
i've got a changed sig error and did bitbake core-image-minimal -cdo_image_bootimg -Snone, then bitbake core-image-minimal -cdo_image_bootimg -Sprintdiff. I got The differences between the current build and any cached tasks start at the following tasks:
GLumen has quit [Ping timeout: 246 seconds]
<LetoThe2nd>
/data/imx7/kirkstone-build/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_qaThe differences between the current build and any cached tasks start at the following tasks:
<fray>
I'm seeing cases where I do something like: SRC_URI = "file:///foo/bar/my_file.c" that the file ends up (after do_fetch) in ${WORKDIR}/foo/bar/my_file.c Why isn't it directly in ${WORKDIR}? Or is there a simple way I can get it to end up directly in WORKDIR?
<fray>
(the issue is a user has to pass in a preparsed .c file for a utility, and this file could be passed in from anywhere on the disk.. so this moving path is driving me nuts)
frieder has quit [Remote host closed the connection]
florian_kc has joined #yocto
<amahnui[m]>
I manually added the quotes around the `test repo` in the bblayer.conf file to see how it will react gave the same error
goliath has joined #yocto
camus has quit [Ping timeout: 246 seconds]
<amahnui[m]>
I think the file that grabs those directories from bblayer.conf when bitbake command is run is where the issue comes from, but I can't find the exact file that handles that operation.
rfuentess has quit [Remote host closed the connection]
elfenix|cloud has left #yocto [#yocto]
<amahnui[m]>
Please which mailing list accepts changes to bitbake/toaster?
<Saur[m]>
amahnui: The problem is that the `BBLAYERS` variable is a whitespace separated list of paths, i.e., the first thing bitbake does when using it is calling `split()` on it, which obviously is not compatible with trying to use paths that contain spaces in it...
<amahnui[m]>
* list accepts patches for changes to
<amahnui[m]>
Saur: That makes a lot of sense I saw the python script and did not see a way to get arround that issue
<amahnui[m]>
What if a condition was made to check for quotes and not to split at a white space until it meets the second quote.
<Saur[m]>
amahnui: I believe the only solution is to detect the problem sooner, i.e., in the `oe-init-build-env` code itself.
<Saur[m]>
There is really no point in generating the bblayers.conf file with such paths in it as it will never be usable anyway.
kevinrowland has joined #yocto
<amahnui[m]>
Saur: Thats right.
<fray>
SRC_URI = .... ;subdir=${WORKDIR} doesn't work. It complains about a circular dependency
<vvn>
fray: a quick and dirty fix I have for your problem is to use a symlink my_file.c -> /foo/bar/my_file.c and use SRC_URI = "file://my_file.c" instead of the full path.
<NishanthMenon>
just curious - is there a standard name (suffix/prefix) folks use for machine names when a single build can support multiple boards?
<fray>
my worry is that I need to use the exact file the user passes in, but there is a default version already in the system.. otherwise I'd add the users path to FILESEXTRAPATHS
<fray>
I suppose what I can do is just pass it in that way and if the user has other files in the directory that conflict they'll just get errors..
<fray>
but ya, something is really broken. file://foo/bar/foo.c results in ${WORKDIR}/foo/bar/foo.c being created. If I do subdir=.., it creates ${WORKDIR}/../foo/bar/foo.c
<fray>
that seems broken it me (not the subdir part) but that it puts files into subdirectories without that being specified
<amahnui[m]>
Please which mailing list accepts patches for bitbake changes
<fray>
bitbake-devel see lists.openembedded.org
<amahnui[m]>
fray: Thanks
<moto-timo>
RP: with the patch I just sent to bb and toaster MLs, hardknott and honister both build via the UI on the honister branch
<moto-timo>
I always build 'quilt-native' as the target... as that is what the toaster-container smoketests build
<LetoThe2nd>
anybody around who can give me some pointers on a changing basehash problem? already did the -Snone + -Sprintdiff dance, but that only gave me a "starts in task"
<LetoThe2nd>
ah found it
<LetoThe2nd>
it seems like ${BB_CURRENTTASK} is not expanded on the second parse? is that posssible?
shaysenberg has joined #yocto
shaysenberg has left #yocto [Leaving]
skoech[m] has joined #yocto
<RP>
moto-timo: I think the master fails is because you didn't clear the environment between the two builds and it's the pre renaming envvars?
<moto-timo>
RP: ah... possibly... that has happened before ;)
<RP>
moto-timo: thanks for testing hardknott and honister though, that sounds promising
<moto-timo>
RP: hardknott also passes on hardknott branch with what I have in contrib timo/hardknott/toaster-fixes... not sure if the last two commits there are needed or not
<RP>
moto-timo: I think those are "nice to have" but probably don't break toaster. I'm leaning to not risking them on hardknott at this point
<moto-timo>
RP: fair enough... that is a rebased "old" branch
<RP>
I'm trying to fix it without risking anything else
GillesMM has joined #yocto
GillesMM has quit [Remote host closed the connection]
<cambrian_invader>
GLumen_: bitbake-whatchanged always says the same things have changed, whether run before or after a complete build
<RP>
moto-timo: I merged the honister patch thanks
<moto-timo>
RP: testing hardknott similar patch now (rebased again)
<GillesM>
Hello how can I use keymaps receipe ?
<sotaoverride>
trying to add a super simple bash script to target (runs some nmcli commands). What's the RDEPENDS for bash scripts that would take care of the "requires /bin/bash" bitbake error?
<RP>
sotaoverride: RDEPENDS_${PN} += "bash" ?
<LetoThe2nd>
RP: dang you typed faster
<LetoThe2nd>
RP: as compensation you owe me a hint on the BB_CURRENTTASK-in-reparse phenomenon ;-)
leon-anavi has quit [Ping timeout: 260 seconds]
leon-anavi has joined #yocto
<vvn>
if you have a machine specific service (e.g. install stuffs on a partition, etc.) do you usually write an explicit recipe for it (e.g. install-on-emmc.bb) or do you append such script/service to a generic recipe?
<Saur[m]>
RP: Btw, regarding the mail discussion we had the other day regarding appending to `PREMIRRORS`, I just realized that it was all based on a mistake on my part. I had mixed up the problem with combining ??= and += for ?= and +=. It is ??= with += that is problematic, but since we use `PREMIRRORS ?= ...` in our configuration, adding the sourceware URLS using += is not problem (for us). Sorry for the noise.
<LetoThe2nd>
vvn: depends - if it is something that has value of its own, or that relates to an existing recipe, basically.
<moto-timo>
RP: hardknott patch sent
<moto-timo>
RP: still fails on master branch but I'm going to take the win for hardknott/honister working and move on
<vvn>
LetoThe2nd: e.g. my system can run on the SD card (default) or the eMMC (requires to run a service). How would you personally package such systemd service?
<LetoThe2nd>
vvn: i personally would probably put it into a recipe of its own, just gut feeling without knowing more about it.
<RP>
LetoThe2nd: I'm missing context, I guess I need to scroll back?
<RP>
Saur[m]: ah, right. I was thinking something didn't seem quite right
<RP>
moto-timo: I don't understand master not working :/
<RP>
LetoThe2nd: BB_CURRENTTASK would only be set in the running task context maybe?
<vvn>
LetoThe2nd: I see. I like that it is very explicit, but I struggle to figure out how to organize the code. Would you add this recipe in a BSP layer's recipes-bsp or on your distro layer?
<RP>
in a general metadata parse, it would have no correct value
<LetoThe2nd>
RP: in a nutshell: i'm having a basehash changed error, and it seems that BB_CURRENTTASK is not expanded in the reparse. diffsigs gave me image_task vs ${BB_CURRENTTAST}
<moto-timo>
RP: me either. Punting at this point. Dunfell and kirkstone work and those are what matter the most.
<LetoThe2nd>
vvn: very generically, i would put it into the bsp, and at to MACHINE_RDEPENDS (or whatsitcalled) for the MACHINE conf that needs it.
<RP>
moto-timo: person on the list said master worked for them
<RP>
LetoThe2nd: BB_CURRENTTASK wouldn't get set at parse time at all
<vvn>
LetoThe2nd: it makes a lot of sense, I will do that thank you.
<LetoThe2nd>
RP: so the conclusion would be that BB_CURRENTTASK must not be used in a recipe at all, because it would always fall over?
<LetoThe2nd>
vvn: have fun
<RP>
LetoThe2nd: I didn't say that, I'm sure we have users
<RP>
LetoThe2nd: I'd suspect it is a red herring
<vvn>
LetoThe2nd: I wouldn't call that fun, but anything that ease the maintenance is a win
<moto-timo>
RP: yeah, it's only a 'master' project on hardknott or honister branch that fails... 'master' on 'master' is fine, 'master' or 'dunfell' on 'dunfell' are fine. shrug.
<LetoThe2nd>
RP: i know you didn't say that, let me try to rephrase. it would always fail the diffsig when used - exception: in python code, because thats the only usage i could easily spot in actual artifact generation.
<LetoThe2nd>
RP: or do you mean this actually hides a completely different problem?
<RP>
moto-timo: oh, right. In that case I'm not worrying about that, yes
<RP>
moto-timo: will be the variable renaming
<moto-timo>
RP: yep, let it go :)
<moto-timo>
happy to have achieved what we did :)
* LetoThe2nd
congratulates moto-timo and RP without knowing the archievement, but hey! awesome!
<RP>
LetoThe2nd: we have recipes using BB_CURRENTTASK. Note that BB_HASHEXCLUDE_COMMON includes BB_CURRENTTASK
<LetoThe2nd>
RP: ok, then I'll dig a bit more. thanks! (bedtime, finally)
<RP>
LetoThe2nd: so I think the idea this is your problem is incorrect
<LetoThe2nd>
kthx :-(
<RP>
LetoThe2nd: it could be but I can't really see it
<RP>
LetoThe2nd: sorry, you did ask my view though :)
florian_kc has joined #yocto
<GLumen_>
cambrian_invader: Sanity check, you have `CACHE` defined, right? (I mostly spend my time debugging why SSTATE caching fails, and am less familiar with the logic around re-use of the working directories)
<cambrian_invader>
yes
goliath has quit [Quit: SIGSEGV]
<GLumen_>
cambrian_invader: Does `bitbake -S printdiff <image>` tell you anything interesting?
<vvn>
LetoThe2nd: actually MACHINE_EXTRA_RDEPENDS += "specific-package1 specific-package2" avoids the need for .bbappend and overrides, or using generic scripts in machine-specific path (e.g. generic-package/beaglebone/install-script)
<cambrian_invader>
not really
florian_kc has quit [Ping timeout: 272 seconds]
<cambrian_invader>
this time I added UBOOT_SIGN_ENABLE=1 in my loca.conf and now gcc is getting rebuilt
<cambrian_invader>
I just hate how a one line config change can literally turn into a lost hour\
<RP>
moto-timo: thanks, I merged hardknott too
<moto-timo>
RP: thank you! I couldn't test those changes prevously :)
Minvera has quit [Remote host closed the connection]
florian_kc has joined #yocto
huseyinkozan has quit [Quit: Konversation terminated!]
* RP
builds 4.0 rc1
* RP
can't help thinking there was something I'm forgetting to do
* vvn
concludes one year later that trying to maintain a generic machine configuration file is a bad idea because machine-level tweaks are often needed and thus these files are product specific
florian_kc has quit [Ping timeout: 250 seconds]
ar__ has quit [Ping timeout: 268 seconds]
goliath has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
<GLumen_>
I'm trying to debug an issue with `bitbake --dump-signatures=printdiff` and Multiconfig: I'm building an initramfs config alongside the normal device config, and for ...reasons... I have different TMPDIRs for each config. `write_diffscenetasks` is choking on the stampsfile for `core-image-tiny-initramfs:do_rootfs` which is correctly placed under the initramfs TMPDIR, but `find_siginfo` is only searching under the TMPDIR for the device config.
<GLumen_>
Any advice?
<kergoth>
if your'e using multiconfig, you probably need to specify the multiconfig when using -S printdiff.
<GLumen_>
kergoth: Unfortunately I'm using `INITRAMFS_IMAGE_BUNDLE = "1"`, so even when specifying `mc::image` I hit the same error. I guess I could temporarily disable INITRAMFS_IMAGE_BUNDLE and then run dump-signatures separately on core-image-tiny-initramfs and my device recipe.