camus has quit [Read error: Connection reset by peer]
nucatus has quit [Ping timeout: 240 seconds]
tnovotny has joined #yocto
<LetoThe2nd>
RP: hang em higher?
<LetoThe2nd>
RP: hang on sloopy?
<LetoThe2nd>
RP: hangover?
Vonter has quit [Ping timeout: 258 seconds]
Vonter has joined #yocto
mckoan|away is now known as mckoan
florian has joined #yocto
Guest8493 has joined #yocto
Guest8493 has left #yocto [#yocto]
JM32 has joined #yocto
<JM32>
hi all -- I've got a do_image_custom that produces an image that I'd like in the DEPLOY_DIR_IMAGE directory, but with a plain copy I get the " trying to install files into a shared area when those files already exist" error. My first though was to put a check in to see if the file exist or not but that might mean it never gets updated and always
<JM32>
overwriting doesn't seem correct either. Anyone any suggestions?
<LetoThe2nd>
JM32: shouldn't you copy to IMGDEPLOYDIR?
nucatus has joined #yocto
<LetoThe2nd>
JM32: the forwarding from there to DEPLOY_DIR_IMAGE should be left to the internal mechanics, AIUI (but happy to be correcte)
<RP>
LetoThe2nd: you are correct
<LetoThe2nd>
RP: i'm really sorry.
<RP>
LetoThe2nd: :) Just be careful, it may be habit forming
<LetoThe2nd>
RP: being right? or being sorry for everything?
<JM32>
LetoThe2nd that might indeed be the issue, thank you
zyga has quit [Ping timeout: 252 seconds]
* RP
swears to himself. tune-xxx is used as an override somewhere :(
<RP>
qschulz: yes. I just thought we could probably avoid this particular issue for the first round, but no
<qschulz>
RP: I might have missed the discussion around "this particular issue" because I've no knowledge of it
<RP>
qschulz: It is inferred in my discussions with Mark. Is tune- an override or not?
<RP>
it isn't, except when it is :/
zyga has quit [Ping timeout: 276 seconds]
nucatus_ has joined #yocto
nucatus has quit [Ping timeout: 240 seconds]
jmiehe has joined #yocto
<RP>
hmm, that highlights I made a mistake in the bitbake changes
* RP
was hoping for a quieter day for a change
bizulk has joined #yocto
nucatus_ has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
<bizulk>
Hello. I'm trying to customize a vendor image file. I used the local conf file it works fine, but now I would like to share additions with the teams using the meta layer. I added a bb file in it : https://pastebin.com/DZ1eq0y4
<bizulk>
but I get a parse error : Could not include required file recipes-fsl/images/fsl-image-qt5.bb
<bizulk>
the recipe is in another meta-layer, should I give a relative path to it ?
<bizulk>
complete path to the image recipe from the meta is : meta-variscite-fslc/dynamic-layers/qt5-layer/recipes-fsl/images/
<LetoThe2nd>
ah. no idea how the path resolution works in the dynamic layers case
<bizulk>
so... it there a way so that whatever the image recipe could be I insert my "dev" package. what is I create a recipe that inherit a core-image image, will my addition be effective for any derived recipe ?
<LetoThe2nd>
bizulk: unless the derived image chooses to remove it, images can be arbitrarily extended. so, yes.
<qschulz>
bizulk: you can have bbappends for image recipes too
nucatus has joined #yocto
<bizulk>
qschulz : that's right.
<bizulk>
I even prefer that one.
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 240 seconds]
jmiehe1 is now known as jmiehe
nucatus has quit [Ping timeout: 272 seconds]
<bizulk>
the vendor already have his fsl-image-qt5.bbapend (?!), can I write mine in my layer, will bitbake join them ?
<qschulz>
bizulk: yes
bluelightning has joined #yocto
<bizulk>
thanks
Andrei[m] has quit [Quit: You have been idle for 30+ days]
nucatus has joined #yocto
<Ad0>
would config fragments work in u-boot? especially if a variable is defined from before?
<Ad0>
I need to enable debug logging
<LetoThe2nd>
Ad0: nope, they do not.
<Ad0>
ok thanks
<Ad0>
I see each layer have their own solution
<Ad0>
elaborate scripts and sed
xmn has joined #yocto
<Ad0>
unsure what file to modify, at what stage though
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
paulg has joined #yocto
jwillikers has joined #yocto
sir_cinnamon has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
<rburton>
pretty sure config fragments work in uboot
<rburton>
the hint is how do_configure calls find_cfgs() to find .cfg files in SRC_URI, and then calls merge_config.sh
<rburton>
Ad0: ^
<Ad0>
thanks
<Ad0>
merge_config right
<Ad0>
do_configure in which recipe?
<Ad0>
poky/meta/recipes-bsp/u-boot/u-boot.inc ?
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
<Ad0>
UBOOT_CONFIG variable
<Ad0>
ok that one I don't need to touch
<Ad0>
cool I will try this!
<Ad0>
maybe I should do the same with kernel config
<rburton>
it uses the same logic as the kernel classes (same code), so just add a debug.cfg fragment to SRC_URI
<Ad0>
thanks! that worked like a charm
linums has quit [Ping timeout: 246 seconds]
<smurray>
RP: any chance that hung build is still around, I'd be curious to see py-bt output of any bitbake-server processes?
<smurray>
RP: I'd need access to the builder, I guess?
<RP>
smurray: it is on a buildtools system so not sure how well it would backtrace
<smurray>
RP: hrm
zyga has joined #yocto
camus has joined #yocto
<ljh>
I'm having some troubles patching a recipe (they changed the branch from master to main) with a .bbappend and a patch file. Does anyone knows an example that I can follow?
<rburton>
in the bbappend, write a new SRC_URI which includes branch=main
<rburton>
ideally, you'd send a patch instead of appending, as everyone else needs the same fix
<ljh>
Yea, it got fixed in the upstream but I have to use this revision specifically :/
<ljh>
Did something like that, but the patch doesn't seem to be applying. Pretty much like this: ```SRC_URI += "file://0001-Fix-branch-naming-master-to-main.patch"``` (hope it's okay to send code in the chat, apologies if it isnt!)
<rburton>
what is that patching?
<ljh>
It does this: -SRC_URI = "git://${PKG_NAME}.git"
<Ad0>
I did devtool modify u-boot but it doesn't seem to pick that when I do bitbake u-boot.
<smurray>
RP: if you have time, can you pop on that builder and capture "ps axf", I'd be curious to see if it's just a bitbake-server pair spinning like before
<zeddii>
ljh: what recipe is causing the problem ?
<ljh>
We're using meta-virt a lot in our embedded project, thanks a lot, btw :-)
<zeddii>
aha. I missed that comment.
<angolini>
I'm not sure my memory is right, but I don't think 6ull has pxp @wyre, why your machine is bringing it?
<rburton>
zeddii: is there a way to use a in-tree defconfig *and* apply a config fragment on top?
<wyre>
angolini, I don't know I pasted the .conf file for the machina and I can't see anything about pxp
<wyre>
so ... is it maybe a dependency?
<zeddii>
rburton: yah, just set it, and add a fragment to your SRC_URI. works fine.
<wyre>
maybe because of the include conf/machine/include/imx-base.inc
<rburton>
zeddii: even if we have KBUILD_DEFCONFIG = "defconfig" KCONFIG_MODE = "--alldefconfig" set?
<zeddii>
merge_config still applies the fragments, so yah, it should work. That being said, it's probably been several years since I tried something like that.
<angolini>
yes, imx-base includes pxp for imx6ull, but I don't quite know 6ull by heart... I would need to double check that. Would you mind creating an issue on meta-freescale and mention me? I'm @angolini no github as well..... https://github.com/Freescale/meta-freescale/issues
<angolini>
@wyre ^^
<angolini>
I'll try to take a look on this today
* zeddii
steps out for a few
<angolini>
and I need to learn how to mention people here and how to answer as reply.......................
Jari[m] has quit [Quit: You have been idle for 30+ days]
WadeBerrier[m] has quit [Quit: You have been idle for 30+ days]
janvermaete[m] has quit [Quit: You have been idle for 30+ days]
ndec[m] has quit [Quit: You have been idle for 30+ days]
<RP>
smurray: mailed you some output
janvermaete[m] has joined #yocto
Jari[m] has joined #yocto
ndec[m] has joined #yocto
Jari[m] has left #yocto [#yocto]
WadeBerrier[m] has joined #yocto
WadeBerrier[m] has left #yocto [#yocto]
janvermaete[m] has left #yocto [#yocto]
<smurray>
RP: looking at it, it looks quite a bit different than the failures I was seeing, where some tests would fail due to not being able to start a new bitbake, oe-selftest would complete, then there'd be some processes left around
<RP>
smurray: it does look different, but this is one of the issues we saw when Paul was working on it. I've mailed you the tail end of the cooker log. Note all the parser processes hanging around not being reaped
<RP>
smurray: it is as if the parse shutdown never happens
<RP>
well, compeltes
<dl9pf>
maybe similar issue like we fixed but in other place ?
<smurray>
RP: is it the "More than one thread left?: [<_MainThread(MainThread, started 139935909099328)>, <Thread(asyncio_0, started 139935769843264)>, <Thread(asyncio_0, started 139935760250432)>]" that's indicative in there?
<RP>
smurray: that was the previous server which terminated. I included that to show "normal" shutdown
<RP>
smurray: but yes, it shows async threads hanging around at exit time :/
<smurray>
RP: I wonder if that's a red herring from creating the asyncio loop in the main process and not the child
<bizulk>
maybe a silly question, we added a bbapend to change the kernel dtp to support our display (patch list), If I want to inhibit the simplest & clean way is to rename that bbapend locally. then maybe generate simultaneously the dtb so that we can select at boot time.
<RP>
smurray: I think it may well be related to the main loop in the server but might not be a red herring
<RP>
smurray: I'm suspicious that we could get the lock and exit there :/
nucatus_ has joined #yocto
<smurray>
RP: okay, I can rework the changes I had to move it to go on top of JPEW's fix
<RP>
I suspect this is threading vs processes and that the threads don't have their own copy of the lock
JM32 has quit [Quit: Client closed]
<RP>
smurray: code for shutdown is in lib/bb/server/process.py
<smurray>
RP: unless it's specific to Python 3.9 vs earlier, I'm surprised I'd not have seen on it on my tests last week
<RP>
smurray: It could well be 3.9 specific as it sounds like a lot changed
<RP>
I think there is a pattern here that it triggers with buildtools
<smurray>
yeah
nucatus has quit [Ping timeout: 240 seconds]
<qschulz>
bizulk: then don't patch the device tree but rather create a second one, build both, deploy both and chose from your bootloader which one should be used
<smurray>
RP: I can attempt some runs with either a distro with 3.9 or the buildtools tarball, might be harder to vet locally since my build machine isn't quite big enough to handle oe-selftest with enough load w/o it blowing up
<bizulk>
qschulz yes. That what I'm going towards,
<RP>
smurray: if you sort the other patch we can try that on the AB too
<smurray>
RP: okay
* RP
isn't sure that working n32 mips is a good tradeoff against broken eSDK
<smurray>
RP: heh
<smurray>
RP: when I send the patch to move the asyncio loop creation, should I send the whole patchset again or is just that one on top fine for now?
<JPEW>
Just got caught up... is there a link to the error?
<RP>
smurray: on top is fine
argonautx has joined #yocto
<smurray>
RP: okay
<RP>
JPEW: its just a hang, no error :(
<RP>
JPEW: I forwarded the mails I sent smurray
<JPEW>
RP: ty
<RP>
10100 automatic conversion changes by the script and 34 manual ones for oe-core :)
<JPEW>
RP: Nice
<JPEW>
Is the theory that the bitbake server process can't exit because it cannot get the lock?
<RP>
JPEW: no, theory is it exits as it can get the lock when there is still something async going on with the DB
<JPEW>
Ah, it's waiting for the PR server to exit?
<RP>
JPEW: I suspect something in the parser process code not getting on well with the asyncio threads and something deadlocking
<smurray>
so one difference with these changes is the addition of some handling to cancel the async tasks before calling stop on the asyncio loop, that might be opening a window
<JPEW>
Ya, I was a little curious about that
<smurray>
but my guess is in the main process the asyncio loop would be idle
<JPEW>
smurray: It should
<JPEW>
ostensibly, the process is going to die so I'm not sure if canceling is *really* necessary
<JPEW>
It might be worth dropping that patch just to see if the problem goes away
<smurray>
yeah, that did occur to me. I guess I don't know what the potential is for breaking the db? Zero as everything is atomic?
<JPEW>
If PR server is the same as hash server, it's zero because the DB operations are not async
<JPEW>
i.e. the SQL operations on the DB are uninterruptable because they are done synchronously instead of async
<JPEW>
Double edge sword, because it means the server can't handle other clients while waiting for the SQL, but you can't do async SQL without python modules
<smurray>
JPEW: I think that's the case
tnovotny has quit [Quit: Leaving]
camus has quit [Read error: Connection reset by peer]
<wyre>
also ... will be openembedded-core treated as a layer?
<override>
not a yocto question but im really striggling with some github workflow yaml syntax error
<override>
does any one use that for ci out here?
<qschulz>
wyre: because meta-openembedded is not a layer
goliath has quit [Quit: SIGSEGV]
<wyre>
qschulz, so it's a collection of layers?
<qschulz>
meta-oe is a layer that is part of meta-openembedded collection of layers
<wyre>
oh, I see
<wyre>
so the link is generic and another layers which are inside of the collection will have the link, right?
<qschulz>
the link is the link to the repository
<qschulz>
type meta-openembedded in the search bar and you'll see for yourself what the results are :)
<qschulz>
openembedded-core is a layer indeed
<qschulz>
it is also poky/meta
Tokamak has joined #yocto
ncaidin_lf has joined #yocto
<smurray>
JPEW: the move of the forking into AsyncServer.serve_as_process makes moving the asyncio loop creation a bit more non-obvious now, any suggestions?
<wyre>
qschulz, you mean both (openembedded-core and poky/meta) are layers or both are the same?
<qschulz>
both are the same
otavio has joined #yocto
<smurray>
JPEW: I think I'll need to pull it out of the class and have it as a asyncrpc.serve_as_process func, would you be okay with that?
<JPEW>
smurray: Create it in run() in serve_as_process() ?
<wyre>
so I don't need openembedded-core, I see, thank you 😁
<JPEW>
smurray: TBH having the class "own" the aio loop was a little strange anyway :)
<smurray>
JPEW: that won't work wrt start_{tcp,unix}_server
<smurray>
JPEW: but moving the loop creation out of __init__ altogether would if that seems acceptable
<JPEW>
smurray: Hmm
<JPEW>
I think the call to start_{tcp,unix}_server needs to be deferred until serve_forever() anwyay...
<smurray>
JPEW: yeah, it's a bit tangled up. Previously, I just shifted the server object creation into the helper func given to Process
<JPEW>
... but, that means there could be a race where the server is slow and isn't ready when bitbake starts talking to it.... tricky
<JPEW>
smurray: Plus, you need the address in the main process
<smurray>
JPEW: I was passing the port back over a Queue for prserv
<JPEW>
smurray: Ya, I think that start_{tcp,unix}_server needs to change to start the server in a deferred manner (when serve_forever is called), and then server_as_process() needs to return the address (passed over a queue)
<smurray>
JPEW: does it need the address in the parent, though, I can't see where it'd be used?
zyga has joined #yocto
<JPEW>
smurray: Ah maybe not. That makes it easier
<JPEW>
smurray: The tests use it: server.address
<smurray>
JPEW: hrm
<smurray>
JPEW: that looks droppable, maybe, the test specifies the address with self.get_server_addr(self.server_index) when it calls create_server, it could just save that value, I think?
<JPEW>
smurray: Maybe. I avoided that because it gets hard with multiple tests
<JPEW>
Particularly with TCP, because you need an unused ephemeral port
<smurray>
JPEW: I'll poke around a bit, perhaps getting it back to the parent is doable
<smurray>
JPEW: I'll rebase the PR server changes on top and do some basic testing. Will have to work out how to get it all together for RP to test on the autobuilder
dmoseley has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
dmoseley has joined #yocto
zyga-mbp has joined #yocto
ljh has quit [Quit: Client closed]
bizulk has quit [Quit: Client closed]
<RP>
smurray: if you have a patch series on top of bitbake I can figure it out
zyga has joined #yocto
zpfvo has quit [Quit: Leaving.]
fitzsim` has joined #yocto
nucatus has joined #yocto
bizulk has joined #yocto
fitzsim has quit [Ping timeout: 258 seconds]
<vd>
Does ${IMAGE_LINK_NAME_pn-some-image} works from another recipe?
<vd>
(looking for a generic way to get an image name)
fitzsim` is now known as fitzsim
nucatus has quit [Ping timeout: 250 seconds]
<vd>
How do you usually reference an output image file from another recipe?
zyga has quit [Ping timeout: 250 seconds]
paulg has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 240 seconds]
paulg has quit [Ping timeout: 240 seconds]
ljh has joined #yocto
florian has quit [Quit: Ex-Chat]
bizulk has quit [Quit: Client closed]
paulg has joined #yocto
Sansveni has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 265 seconds]
mckoan is now known as mckoan|away
nucatus has joined #yocto
ncaidin_lf has quit [Quit: Client closed]
nucatus has quit [Ping timeout: 265 seconds]
prabhakarlad has quit [Quit: Client closed]
<dl9pf>
OE happy hour is on !
ljh has quit [Quit: Client closed]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
<override>
boot.scr are scripts run bu uboot? ive been messing around with bitbake -e and all to figure out recipe generates boot.scr for me. I still cant manage figuring out what recipe is generating it. any idea how I could go about it?
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
Guest26 has quit [Quit: Client closed]
nucatus has joined #yocto
<Ad0>
override, yeah it's script with some binary information in the start
<Ad0>
then for it to run it's put in a var: ./conf/machine/include/rpi-default-providers.inc:PREFERRED_PROVIDER_u-boot-default-script ??= "rpi-u-boot-scr"
nucatus has joined #yocto
jmiehe has quit [Quit: jmiehe]
<yates_work>
poky/meta/classes/meson.bbclass has a line DEPENDS_append = " meson-native ninja-native", but find . -name "meson-native*" comes back empty.
<yates_work>
isn't there supposed to be a recipe "meson-native.bb"
nucatus has quit [Ping timeout: 240 seconds]
<yates_work>
i'm also seeing a simiilar thing in the bitbake -g task-depends.dot output: xorgproto-native.do_prepare_recipe_sysroot" -> "meson-native.do_populate_sysroot"
<yates_work>
but there is not meson-native recipe!
<yates_work>
am i misinterpreting?
<rburton>
the meson recipe uses BBCLASSEXTEND to magically turn into meson-native (and nativesdk-meson)
<RP>
zeddii: that patch just allows compatibility, the pieces in master-next actually use ":" internally instead of "_"
nucatus has joined #yocto
nucatus has quit [Ping timeout: 272 seconds]
Tokamak has joined #yocto
<zeddii>
ahah. got it. I have the parsing change. at least that explains that my inspection -> commit work with the conversion is being tested (some)
<RP>
zeddii: It means people can start converting layers now, assuming we have the agreement on what we convert
Guest26 has quit [Quit: Client closed]
<zeddii>
yah. I'm doing meta-virt master, and it looks ok for the first pass. my targets all built. but there some class subtlety and other use cases that will pop out
<zeddii>
I want to at least get it up on meta-virt master-next, so people will know I've started
<RP>
zeddii: I'm curious to see how things fare with other layers
<zeddii>
yah. outside of one change to a wic file that wasn't actually overrides, so far, my inspection showed it as all good.
<smurray>
JPEW: it's interesting, behavior is definitely a bit different now, seeing (somewhat harmless, I think) CancelledError's in the logs from the shutdown code
<smurray>
JPEW: that suggests something wasn't working quite as expected before
<smurray>
RP JPEW: I need to step out, will pick it back up again tomorrow to try to get an updated patchset I'm happy with out
<JPEW>
smurray: Are you getting the cancelled error because you dropped the patch that tries to cancel everything?
<JPEW>
smurray: Or do you still have that?
<smurray>
JPEW: no, that's with it still
<JPEW>
smurray: Ya. Seems like something w.r.t. the cancelling might still be amiss then
<smurray>
JPEW: I'm definitely no expert, though. I'll bbiab, need to head out to a whisky tasting
<JPEW>
smurray: ooOOoo sounds fun!
ljh has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
vd has joined #yocto
<vd>
JPEW does whisk download layers and bitbake for you?
<JPEW>
vd: it can if you want
prabhakarlad has joined #yocto
<JPEW>
You can add a "fetch" command that gets run when you use the --fetch option
<JPEW>
A fetch command per layer set that is... We use it with submodules
<vd>
whoops, just found that in the readme, thank you
<vd>
I'll give it a try to see if I can easily replace kas with it
<vd>
I was preparing my multiconfigs with custom IMAGE_LINK_NAME, TMPDIR and all, so I figure it might be better to try out whisk now instead.
<JPEW>
Ah, nice
amitk has quit [Ping timeout: 250 seconds]
ochredoke has quit [Ping timeout: 240 seconds]
nucatus has joined #yocto
ochredoke has joined #yocto
jmiehe has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
nucatus has joined #yocto
jwillikers has quit [Remote host closed the connection]
nucatus has quit [Ping timeout: 240 seconds]
vd has quit [Quit: Client closed]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
nucatus has joined #yocto
Guest26 has quit [Quit: Client closed]
nucatus has quit [Ping timeout: 265 seconds]
<jordemort>
does anyone have any solid examples of building 3rd party kernel modules? i've got recipes that use ${KERNEL_VERSION} and it seems like there's something not quite right in the dependencies there; i.e. if i update the kernel it ends up with a different version string, but the old modules don't get rebuilt and so they're in the wrong directory in /lib/modules
<jordemort>
and vice versa, when i update the 3rd party module it gets rebuilt but KERNEL_VERSION seems different and it ends up all by itself in a unique directory in /lib/modules that doesn't match the kernel in the image