Wednesday, 2021-07-28

*** vmeson <vmeson!> has quit IRC (Ping timeout: 268 seconds)00:00
*** vmeson <vmeson!> has joined #yocto00:07
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)00:15
*** linums <linums!~linums@> has joined #yocto00:15
*** Tokamak_ <Tokamak_!> has quit IRC (Ping timeout: 255 seconds)00:16
Ad0run.do_configure:    # Copy defconfig to .config if .config does not exist.00:22
Ad0.config exists but I have no idea where it comes from00:23
*** qschulz <qschulz!> has quit IRC (Read error: Connection reset by peer)00:32
*** qschulz <qschulz!> has joined #yocto00:34
*** nucatus <nucatus!> has joined #yocto00:43
*** nucatus <nucatus!> has quit IRC (Ping timeout: 276 seconds)00:49
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)00:50
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto00:56
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)01:19
*** RobertBerger <RobertBerger!~rber|> has joined #yocto01:32
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 258 seconds)01:34
*** nucatus <nucatus!> has joined #yocto01:44
*** willo <willo!~quassel@fedora/willo> has joined #yocto01:52
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)01:54
*** zyga-mbp <zyga-mbp!> has quit IRC (Ping timeout: 268 seconds)02:05
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto02:08
*** nucatus <nucatus!> has joined #yocto02:46
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)02:52
*** nucatus <nucatus!> has joined #yocto03:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)03:55
*** paulg <paulg!> has quit IRC (Ping timeout: 258 seconds)04:03
*** nucatus <nucatus!> has joined #yocto04:06
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:37
*** xmn <xmn!> has quit IRC (Ping timeout: 276 seconds)05:28
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)05:57
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:04
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)06:06
*** tperrot <tperrot!> has quit IRC (Quit: leaving)06:22
*** frieder <frieder!> has joined #yocto06:26
*** nucatus <nucatus!> has joined #yocto06:28
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)06:32
*** tprrt <tprrt!> has joined #yocto06:36
*** tprrt is now known as tperrot06:36
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:41
*** nucatus <nucatus!> has joined #yocto06:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)06:58
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:58
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)06:58
*** amitk <amitk!~amit@> has joined #yocto07:03
*** LetoThe2nd <LetoThe2nd!> has joined #yocto07:08
*** zyga <zyga!~zyga@> has joined #yocto07:10
*** camus <camus!> has joined #yocto07:10
*** nucatus <nucatus!> has joined #yocto07:10
LetoThe2ndyo dudX07:11
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)07:17
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:31
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:38
*** nucatus <nucatus!> has joined #yocto07:48
RPsmurray: hate to say this but with the prserv patches we have another hang: :/07:48
*** camus <camus!> has quit IRC (Read error: Connection reset by peer)07:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)07:52
*** tnovotny <tnovotny!> has joined #yocto07:56
LetoThe2ndRP: hang em higher?08:15
LetoThe2ndRP: hang on sloopy?08:15
LetoThe2ndRP: hangover?08:15
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 258 seconds)08:24
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto08:27
*** mckoan|away is now known as mckoan08:31
*** florian <florian!> has joined #yocto08:47
*** Guest8493 <Guest8493!> has joined #yocto08:48
*** Guest8493 <Guest8493!> has left #yocto08:49
*** JM32 <JM32!> has joined #yocto09:06
JM32hi 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 always09:15
JM32overwriting doesn't seem correct either. Anyone any suggestions?09:15
LetoThe2ndJM32: shouldn't you copy to IMGDEPLOYDIR?09:17
*** nucatus <nucatus!> has joined #yocto09:17
LetoThe2ndJM32: the forwarding from there to DEPLOY_DIR_IMAGE should be left to the internal mechanics, AIUI (but happy to be correcte)09:18
RPLetoThe2nd: you are correct09:19
LetoThe2ndRP: i'm really sorry.09:20
RPLetoThe2nd: :) Just be careful, it may be habit forming09:21
LetoThe2ndRP: being right? or being sorry for everything?09:26
JM32LetoThe2nd that might indeed be the issue, thank you09:27
*** zyga <zyga!~zyga@> has quit IRC (Ping timeout: 252 seconds)09:34
* RP swears to himself. tune-xxx is used as an override somewhere :(09:36
*** florian_kc <florian_kc!> has joined #yocto09:37
*** zyga <zyga!~zyga@> has joined #yocto09:39
qschulzRP: used everywhere in tune conf files?09:43
RPqschulz: yes. I just thought we could probably avoid this particular issue for the first round, but no09:44
qschulzRP: I might have missed the discussion around "this particular issue" because I've no knowledge of it09:45
RPqschulz: It is inferred in my discussions with Mark. Is tune- an override or not?09:46
RPit isn't, except when it is :/09:46
*** zyga <zyga!~zyga@> has quit IRC (Ping timeout: 276 seconds)09:48
*** nucatus_ <nucatus_!> has joined #yocto09:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)09:52
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto09:53
RPhmm, that highlights I made a mistake in the bitbake changes10:01
* RP was hoping for a quieter day for a change10:01
*** bizulk <bizulk!~bizulk@> has joined #yocto10:22
*** nucatus_ <nucatus_!> has quit IRC (Remote host closed the connection)10:22
*** nucatus <nucatus!> has joined #yocto10:23
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)10:24
bizulkHello. 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 :
bizulkbut I get a parse error : Could not include required file recipes-fsl/images/fsl-image-qt5.bb10:27
bizulkthe recipe is in another meta-layer, should I give a relative path to it ?10:27
bizulkcomplete path to the image recipe from the meta is : meta-variscite-fslc/dynamic-layers/qt5-layer/recipes-fsl/images/10:30
LetoThe2ndah. no idea how the path resolution works in the dynamic layers case10:31
bizulkso... 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 ?10:35
LetoThe2ndbizulk: unless the derived image chooses to remove it, images can be arbitrarily extended. so, yes.10:37
qschulzbizulk: you can have bbappends for image recipes too10:42
*** nucatus <nucatus!> has joined #yocto10:45
bizulkqschulz : that's right.10:45
bizulkI even prefer that one.10:47
*** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto10:48
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 240 seconds)10:49
*** jmiehe1 is now known as jmiehe10:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 272 seconds)10:50
bizulkthe vendor already have his fsl-image-qt5.bbapend (?!), can I write mine in my layer, will bitbake join them ?10:50
qschulzbizulk: yes10:50
*** bluelightning <bluelightning!~paul@2406:e003:1385:8501:ad77:7a5:e243:41b9> has joined #yocto10:55
*** Andrei[m] <Andrei[m]!~andreicub@2001:470:69fc:105::c95> has quit IRC (Quit: You have been idle for 30+ days)11:13
*** nucatus <nucatus!> has joined #yocto11:19
Ad0would config fragments work in u-boot? especially if a variable is defined from before?11:24
Ad0I need to enable debug logging11:25
LetoThe2ndAd0: nope, they do not.11:33
Ad0ok thanks11:36
Ad0I see each layer have their own solution11:36
Ad0elaborate scripts and sed11:36
*** xmn <xmn!> has joined #yocto11:37
Ad0unsure what file to modify, at what stage though11:37
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto11:38
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)11:43
*** paulg <paulg!> has joined #yocto11:45
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto11:45
*** sir_cinnamon <sir_cinnamon!~sir_cinna@> has joined #yocto11:47
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)11:50
*** nucatus <nucatus!> has joined #yocto11:51
rburtonpretty sure config fragments work in uboot11:53
rburtonthe hint is how do_configure calls find_cfgs() to find .cfg files in SRC_URI, and then calls merge_config.sh11:54
rburtonAd0: ^11:55
Ad0merge_config right11:56
Ad0do_configure in which recipe?11:56
Ad0poky/meta/recipes-bsp/u-boot/ ?11:56
*** nucatus <nucatus!> has quit IRC (Remote host closed the connection)11:56
*** nucatus <nucatus!> has joined #yocto11:57
Ad0UBOOT_CONFIG variable11:59
Ad0ok that one I don't need to touch12:00
Ad0cool I will try this!12:00
Ad0maybe I should do the same with kernel config12:01
rburtonit uses the same logic as the kernel classes (same code), so just add a debug.cfg fragment to SRC_URI12:02
Ad0thanks! that worked like a charm12:07
*** linums <linums!~linums@> has quit IRC (Ping timeout: 246 seconds)12:16
smurrayRP: any chance that hung build is still around, I'd be curious to see py-bt output of any bitbake-server processes?12:16
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has joined #yocto12:20
ljhGood morning/evening/night everyone :-)12:20
RPsmurray: I left it12:21
qschulzljh: o/12:22
smurrayRP: I'd need access to the builder, I guess?12:22
RPsmurray: it is on a buildtools system so not sure how well it would backtrace12:22
smurrayRP: hrm12:22
*** zyga <zyga!~zyga@> has joined #yocto12:25
*** camus <camus!> has joined #yocto12:28
ljhI'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?12:30
rburtonin the bbappend, write a new SRC_URI which includes branch=main12:31
rburtonideally, you'd send a patch instead of appending, as everyone else needs the same fix12:31
ljhYea, it got fixed in the upstream but I have to use this revision specifically :/12:31
ljhDid 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!)12:33
rburtonwhat is that patching?12:34
ljhIt does this: -SRC_URI = "git://${PKG_NAME}.git"12:34
ljh+SRC_URI = "git://${PKG_NAME}.git;branch=main"12:34
rburtonyeah you can't do that12:34
ljhoh lol12:34
rburtonjust write a new SRC_URI in the append12:34
Ad0I did devtool modify u-boot but it doesn't seem to pick that when I do bitbake u-boot.12:35
smurrayRP: 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 before12:35
zeddiiljh: what recipe is causing the problem ?12:36
wyrehi guys, I'm having problems with imx-lib but I'm not sure why is this, because this is apparently a problem with the freescale recipe, ain't it?
Ad0ah now it did12:36
ljhzeddii it's go-systemd.12:36
zeddiithat's in meta-virt, I maintain that. what release branch are you building ?12:37
zeddiiit's easier for me to just fix it.12:37
angolini@wyre what branch and machine are you using?12:37
zeddiiljh: I'm betting an older release, since I fixed the branch to 'main' on may 10th12:38
ljhYes, it was fixed upstream hehe12:38
wyreangolini, dunfell branch and imx6ull-microgea machine
ljhWe're using meta-virt a lot in our embedded project, thanks a lot, btw :-)12:39
zeddiiaha. I missed that comment.12:39
angoliniI'm not sure my memory is right, but I don't think 6ull has pxp @wyre, why your machine is bringing it?12:39
rburtonzeddii: is there a way to use a in-tree defconfig *and* apply a config fragment on top?12:39
wyreangolini, I don't know I pasted the .conf file for the machina and I can't see anything about pxp12:40
wyreso ... is it maybe a dependency?12:40
zeddiirburton: yah, just set it, and add a fragment to your SRC_URI. works fine.12:40
wyremaybe because of the include conf/machine/include/imx-base.inc12:40
rburtonzeddii: even if we have KBUILD_DEFCONFIG = "defconfig" KCONFIG_MODE = "--alldefconfig" set?12:41
zeddiimerge_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.12:41
angoliniyes, 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.....
angolini@wyre ^^12:44
angoliniI'll try to take a look on this today12:44
* zeddii steps out for a few12:45
angoliniand I need to learn how to mention people here and how to answer as reply.......................12:45
wyreok angolini 😁12:47
bizulk@angolini : @ is the key :)12:50
smurraynot on irc ;)12:51
wyreangolini, 😉12:52
*** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has quit IRC (Quit: You have been idle for 30+ days)12:52
*** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has quit IRC (Quit: You have been idle for 30+ days)12:52
*** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has quit IRC (Quit: You have been idle for 30+ days)12:52
*** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has quit IRC (Quit: You have been idle for 30+ days)12:52
RPsmurray: mailed you some output12:52
*** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has joined #yocto12:52
*** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has joined #yocto12:52
*** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has joined #yocto12:53
*** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has left #yocto12:53
*** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has joined #yocto12:53
*** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has left #yocto12:53
*** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has left #yocto12:53
smurrayRP: 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 around12:54
RPsmurray: 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 reaped12:56
RPsmurray: it is as if the parse shutdown never happens12:56
RPwell, compeltes12:56
dl9pfmaybe similar issue like we fixed but in other place ?12:56
smurrayRP: 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?12:58
RPsmurray: that was the previous server which terminated. I included that to show "normal" shutdown12:59
RPsmurray: but yes, it shows async threads hanging around at exit time :/13:00
smurrayRP: I wonder if that's a red herring from creating the asyncio loop in the main process and not the child13:01
bizulkmaybe 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.13:01
RPsmurray: I think it may well be related to the main loop in the server but might not be a red herring13:01
RPsmurray: I'm suspicious that we could get the lock and exit there :/13:04
*** nucatus_ <nucatus_!> has joined #yocto13:04
smurrayRP: okay, I can rework the changes I had to move it to go on top of JPEW's fix13:04
RPI suspect this is threading vs processes and that the threads don't have their own copy of the lock13:04
*** JM32 <JM32!> has quit IRC (Quit: Client closed)13:04
RPsmurray: code for shutdown is in lib/bb/server/process.py13:04
smurrayRP: unless it's specific to Python 3.9 vs earlier, I'm surprised I'd not have seen on it on my tests last week13:05
RPsmurray: It could well be 3.9 specific as it sounds like a lot changed13:05
RPI think there is a pattern here that it triggers with buildtools13:05
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)13:07
qschulzbizulk: 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 used13:07
smurrayRP: 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 up13:08
bizulkqschulz yes. That what I'm going towards,13:08
RPsmurray: if you sort the other patch we can try that on the AB too13:09
smurrayRP: okay13:10
* RP isn't sure that working n32 mips is a good tradeoff against broken eSDK13:14
smurrayRP: heh13:26
smurrayRP: 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?13:28
JPEWJust got caught up... is there a link to the error?13:29
RPsmurray: on top is fine13:30
*** argonautx <argonautx!> has joined #yocto13:30
smurrayRP: okay13:30
RPJPEW: its just a hang, no error :(13:31
RPJPEW: I forwarded the mails I sent smurray13:32
JPEWRP: ty13:33
RP10100 automatic conversion changes by the script and 34 manual ones for oe-core :)13:34
JPEWRP: Nice13:35
JPEWIs the theory that the bitbake server process can't exit because it cannot get the lock?13:36
RPJPEW: no, theory is it exits as it can get the lock when there is still something async going on with the DB13:36
JPEWAh, it's waiting for the PR server to exit?13:38
RPJPEW: I suspect something in the parser process code not getting on well with the asyncio threads and something deadlocking13:39
smurrayso 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 window13:39
JPEWYa, I was a little curious about that13:39
smurraybut my guess is in the main process the asyncio loop would be idle13:40
JPEWsmurray: It should13:40
JPEWostensibly, the process is going to die so I'm not sure if canceling is *really* necessary13:40
JPEWIt might be worth dropping that patch just to see if the problem goes away13:41
smurrayyeah, that did occur to me.  I guess I don't know what the potential is for breaking the db?  Zero as everything is atomic?13:41
JPEWIf PR server is the same as hash server, it's zero because the DB operations are not async13:42
JPEWi.e. the SQL operations on the DB are uninterruptable because they are done synchronously instead of async13:43
JPEWDouble 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 modules13:44
smurrayJPEW: I think that's the case13:47
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)13:54
*** camus <camus!> has quit IRC (Read error: Connection reset by peer)14:07
*** sakoman <sakoman!> has joined #yocto14:18
*** zyga <zyga!~zyga@> has quit IRC (Ping timeout: 258 seconds)14:24
*** YogeshSiraswar_ <YogeshSiraswar_!> has joined #yocto14:26
wyrewhy I can see here the meta-openembedded layer is listed as meta-oe? this is confusing because meta-openembedded has inside another layer/folder called also meta-oe14:29
wyrealso ... will be openembedded-core treated as a layer?14:31
overridenot a yocto question but im really striggling with some github workflow yaml syntax error14:31
overridedoes any one use that for ci out here?14:31
qschulzwyre: because meta-openembedded is not a layer14:31
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:31
wyreqschulz, so it's a collection of layers?14:31
qschulzmeta-oe is a layer that is part of meta-openembedded collection of layers14:32
wyreoh, I see14:32
wyreso the link is generic and another layers which are inside of the collection will have the link, right?14:32
qschulzthe link is the link to the repository14:32
qschulztype meta-openembedded in the search bar and you'll see for yourself what the results are :)14:33
qschulzopenembedded-core is a layer indeed14:33
qschulzit is also poky/meta14:34
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto14:35
*** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::94> has joined #yocto14:36
smurrayJPEW: the move of the forking into AsyncServer.serve_as_process makes moving the asyncio loop creation a bit more non-obvious now, any suggestions?14:41
wyreqschulz, you mean both (openembedded-core and poky/meta) are layers or both are the same?14:42
qschulzboth are the same14:42
*** otavio <otavio!> has joined #yocto14:42
smurrayJPEW: 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?14:42
JPEWsmurray: Create it in run() in serve_as_process() ?14:42
wyreso I don't need openembedded-core, I see, thank you 😁14:43
JPEWsmurray: TBH having the class "own" the aio loop was a little strange anyway :)14:43
smurrayJPEW: that won't work wrt start_{tcp,unix}_server14:43
smurrayJPEW: but moving the loop creation out of __init__ altogether would if that seems acceptable14:44
JPEWsmurray: Hmm14:46
JPEWI think the call to start_{tcp,unix}_server needs to be deferred until serve_forever() anwyay...14:46
smurrayJPEW: yeah, it's a bit tangled up.  Previously, I just shifted the server object creation into the helper func given to Process14:47
JPEW... but, that means there could be a race where the server is slow and isn't ready when bitbake starts talking to it.... tricky14:47
JPEWsmurray: Plus, you need the address in the main process14:48
smurrayJPEW: I was passing the port back over a Queue for prserv14:49
JPEWsmurray: 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)14:52
smurrayJPEW: does it need the address in the parent, though, I can't see where it'd be used?14:57
*** zyga <zyga!~zyga@> has joined #yocto14:58
JPEWsmurray: Ah maybe not. That makes it easier14:58
JPEWsmurray: The tests use it: server.address14:58
smurrayJPEW: hrm14:58
smurrayJPEW: 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?15:02
JPEWsmurray: Maybe. I avoided that because it gets hard with multiple tests15:02
JPEWParticularly with TCP, because you need an unused ephemeral port15:02
smurrayJPEW: I'll poke around a bit, perhaps getting it back to the parent is doable15:03
JPEWI can send to the ML if you want15:18
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:21
smurrayJPEW: I can grab it from there, prserv will need at least one fix on top of that15:22
*** frieder <frieder!> has quit IRC (Ping timeout: 268 seconds)15:22
*** zyga <zyga!~zyga@> has quit IRC (Remote host closed the connection)15:22
*** zyga <zyga!~zyga@> has joined #yocto15:22
*** argonautx <argonautx!> has quit IRC (Quit: Leaving)15:22
smurrayJPEW: I think that breaks bin/bitbake-hashserv, it calls serve_forever directly15:26
JPEWsmurray: Ah, good call.... I ran bitbake-selftest but forgot that :)15:27
overridecurious to know what do people usually use for yocto realted CI?15:27
*** sir_cinnamon <sir_cinnamon!~sir_cinna@> has quit IRC (Quit: Client closed)15:27
*** paulg <paulg!> has quit IRC (Ping timeout: 252 seconds)15:27
smurrayJPEW: perhaps move the server start into server_forever?15:28
smurrayJPEW: err, serve_forever15:28
smurrayJPEW: that's what I was getting started on, but you're way faster than I am ;)15:28
JPEWsmurray: All the self.loop should be replaced with asyncio.get_event_loop()15:29
JPEWWhich will make it agnostic to the loop15:29
*** paulg <paulg!> has joined #yocto15:29
JPEWsmurray: Or add this to the class
smurrayJPEW: self.start would still need to be called, though, or the standalone wrapper would need to call serve_as_process, wouldn't it?15:32
JPEW... right.... OK I'll fix it quick (and actually test bitbake-hashserve :)15:33
*** frieder <frieder!> has joined #yocto15:34
*** nucatus_ <nucatus_!> has quit IRC (Remote host closed the connection)15:43
JPEWsmurray: should fix it15:44
*** zyga <zyga!~zyga@> has quit IRC (Ping timeout: 265 seconds)15:46
*** paulg <paulg!> has quit IRC (Ping timeout: 272 seconds)15:47
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: Textual IRC Client:
*** camus <camus!~Instantbi@> has joined #yocto15:48
smurrayJPEW: 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 autobuilder15:49
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Read error: Connection reset by peer)15:58
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:59
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto15:59
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto16:05
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has quit IRC (Quit: Client closed)16:06
*** bizulk <bizulk!~bizulk@> has quit IRC (Quit: Client closed)16:07
RPsmurray: if you have a patch series on top of bitbake I can figure it out16:09
*** zyga <zyga!~zyga@> has joined #yocto16:10
*** zpfvo <zpfvo!~fvo@> has quit IRC (Quit: Leaving.)16:14
*** fitzsim` <fitzsim`!> has joined #yocto16:14
*** nucatus <nucatus!> has joined #yocto16:14
*** bizulk <bizulk!~bizulk@> has joined #yocto16:15
*** fitzsim <fitzsim!> has quit IRC (Ping timeout: 258 seconds)16:15
vdDoes ${IMAGE_LINK_NAME_pn-some-image} works from another recipe?16:16
vd(looking for a generic way to get an image name)16:16
*** fitzsim` is now known as fitzsim16:18
*** nucatus <nucatus!> has quit IRC (Ping timeout: 250 seconds)16:20
vdHow do you usually reference an output image file from another recipe?16:22
*** zyga <zyga!~zyga@> has quit IRC (Ping timeout: 250 seconds)16:31
*** paulg <paulg!> has joined #yocto16:31
*** nucatus <nucatus!> has joined #yocto16:32
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)16:36
*** paulg <paulg!> has quit IRC (Ping timeout: 240 seconds)16:40
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has joined #yocto16:40
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:42
*** bizulk <bizulk!~bizulk@> has quit IRC (Quit: Client closed)16:45
*** paulg <paulg!> has joined #yocto16:45
*** Sansveni <Sansveni!~Sansveni@> has quit IRC (Quit: Client closed)16:46
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 265 seconds)16:46
*** mckoan is now known as mckoan|away16:47
*** nucatus <nucatus!> has joined #yocto16:49
*** ncaidin_lf <ncaidin_lf!~ncaidin_l@2605:380:53:794::94> has quit IRC (Quit: Client closed)16:50
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)16:54
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)16:58
dl9pfOE happy hour is on !17:02
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has quit IRC (Quit: Client closed)17:17
*** nucatus <nucatus!> has joined #yocto17:17
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)17:23
overrideboot.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?17:26
*** nucatus <nucatus!> has joined #yocto17:35
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)17:40
*** Guest26 <Guest26!~Guest26@> has quit IRC (Quit: Client closed)17:41
*** nucatus <nucatus!> has joined #yocto17:44
Ad0override, yeah it's script with some binary information in the start17:46
*** vd <vd!> has quit IRC (Quit: Client closed)17:48
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)17:49
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)17:49
Ad0boot.cmd is injected into it17:50
Ad0./recipes-bsp/rpi-u-boot-scr/    mkimage -A ${UBOOT_ARCH} -T script -C none -n "Boot script" -d "${WORKDIR}/boot.cmd" boot.scr17:51
Ad0then for it to run it's put in a var: ./conf/machine/include/ ??= "rpi-u-boot-scr"17:54
*** nucatus <nucatus!> has joined #yocto18:01
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)18:02
yates_workpoky/meta/classes/meson.bbclass has a line DEPENDS_append = " meson-native ninja-native", but find . -name "meson-native*" comes back empty.18:07
yates_workisn't there supposed to be a recipe ""18:08
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)18:08
yates_worki'm also seeing a simiilar thing in the bitbake -g output: xorgproto-native.do_prepare_recipe_sysroot" -> "meson-native.do_populate_sysroot"18:09
yates_workbut there is not meson-native recipe!18:09
yates_workam i misinterpreting?18:10
rburtonthe meson recipe uses BBCLASSEXTEND to magically turn into meson-native (and nativesdk-meson)18:13
yates_workok thanks rburton18:16
yates_workso if i wanted to .bbappend meson-native, i should create meson.bbappend?18:18
*** nucatus <nucatus!> has joined #yocto18:22
*** nucatus <nucatus!> has quit IRC (Ping timeout: 268 seconds)18:28
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)18:32
* zeddii is confused. I ran RP18:35
zeddiifat finger18:35
zeddiiRP: I ran the override script on meta-virt, but am only on poky master. I thought I'd get a parse error .. but yet, it parsed18:35
* zeddii looks to see what stupidity he's done18:35
*** rewitt3 <rewitt3!~rewitt@> has quit IRC (Remote host closed the connection)18:36
*** Guest26 <Guest26!~Guest26@> has joined #yocto18:37
*** rewitt3 <rewitt3!~rewitt@> has joined #yocto18:37
*** rewitt3 <rewitt3!~rewitt@> has quit IRC (Remote host closed the connection)18:39
*** rewitt3 <rewitt3!~rewitt@> has joined #yocto18:39
*** nucatus <nucatus!> has joined #yocto18:41
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)18:46
*** ant__ <ant__!> has joined #yocto18:52
RPzeddii: recent bitbake will work with the new syntax :)19:06
RPzeddii: I was curious how you ran me :)19:06
zeddiiI checked the history and didn't see the commit to bitbake, I'm looking again. it has to be there, it would have blow up.19:07
RPzeddii: that patch just allows compatibility, the pieces in master-next actually use ":" internally instead of "_"19:09
*** nucatus <nucatus!> has joined #yocto19:12
*** nucatus <nucatus!> has quit IRC (Ping timeout: 272 seconds)19:17
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:17
zeddiiahah. got it. I have the parsing change. at least that explains that my inspection -> commit work with the conversion is being tested (some)19:19
RPzeddii: It means people can start converting layers now, assuming we have the agreement on what we convert19:20
*** Guest26 <Guest26!~Guest26@> has quit IRC (Quit: Client closed)19:20
zeddiiyah. 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 out19:21
zeddiiI want to at least get it up on meta-virt master-next, so people will know I've started19:22
RPzeddii: I'm curious to see how things fare with other layers19:22
zeddiiyah. outside of one change to a wic file that wasn't actually overrides, so far, my inspection showed it as all good.19:23
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has joined #yocto19:31
*** nucatus <nucatus!> has joined #yocto19:41
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)19:47
*** Guest26 <Guest26!~Guest26@> has joined #yocto19:48
RPzeddii: that isn't too bad IMO :)20:02
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has quit IRC (Quit: Client closed)20:15
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: Textual IRC Client:
smurrayJPEW: it's interesting, behavior is definitely a bit different now, seeing (somewhat harmless, I think) CancelledError's in the logs from the shutdown code20:27
smurrayJPEW: that suggests something wasn't working quite as expected before20:28
smurrayRP JPEW: I need to step out, will pick it back up again tomorrow to try to get an updated patchset I'm happy with out20:30
JPEWsmurray: Are you getting the cancelled error because you dropped the patch that tries to cancel everything?20:30
JPEWsmurray: Or do you still have that?20:31
smurrayJPEW: no, that's with it still20:31
JPEWsmurray: Ya. Seems like something w.r.t. the cancelling might still be amiss then20:32
*** florian <florian!> has joined #yocto20:32
smurrayJPEW: I think it's fine now, maybe?  The technique is discussed here:
smurrayJPEW: I'm definitely no expert, though.  I'll bbiab, need to head out to a whisky tasting20:34
JPEWsmurray: ooOOoo sounds fun!20:34
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has joined #yocto20:38
*** nucatus <nucatus!> has joined #yocto20:43
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)20:48
*** vd <vd!> has joined #yocto20:53
vdJPEW does whisk download layers and bitbake for you?20:54
JPEWvd: it can if you want20:58
*** prabhakarlad <prabhakarlad!> has joined #yocto20:58
JPEWYou can add a "fetch" command that gets run when you use the --fetch option20:59
JPEWA fetch command per layer set that is... We use it with submodules21:00
vdwhoops, just found that in the readme, thank you21:03
vdI'll give it a try to see if I can easily replace kas with it21:03
vdI 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.21:04
JPEWAh, nice21:07
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 250 seconds)21:10
*** ochredoke <ochredoke!ochredoke@user/ochredoke> has quit IRC (Ping timeout: 240 seconds)21:15
*** nucatus <nucatus!> has joined #yocto21:17
*** ochredoke <ochredoke!~ochredoke@user/ochredoke> has joined #yocto21:17
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto21:21
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)21:22
*** BobPungartnik <BobPungartnik!~Pung@> has joined #yocto21:23
*** BobPungartnik <BobPungartnik!~Pung@> has quit IRC (Client Quit)21:24
*** nucatus <nucatus!> has joined #yocto21:48
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)21:49
*** nucatus <nucatus!> has quit IRC (Ping timeout: 240 seconds)21:52
*** vd <vd!> has quit IRC (Quit: Client closed)21:59
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)22:16
*** nucatus <nucatus!> has joined #yocto22:19
*** Guest26 <Guest26!~Guest26@> has quit IRC (Quit: Client closed)22:23
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)22:24
jordemortdoes 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/modules22:26
jordemortand 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 image22:26
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)22:40
*** florian <florian!> has quit IRC (Ping timeout: 265 seconds)22:49
*** nucatus <nucatus!> has joined #yocto22:51
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)22:57
*** bunk <bunk!~bunk@debian/bunk> has quit IRC (Quit: leaving)23:07
*** ljh <ljh!~ljh@2804:14d:baa3:44f4:27bf:9f7b:6e1b:870f> has quit IRC (Quit: Client closed)23:14
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto23:19
*** nucatus <nucatus!> has joined #yocto23:21
*** nucatus <nucatus!> has quit IRC (Ping timeout: 252 seconds)23:25
*** nucatus <nucatus!> has joined #yocto23:51
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)23:53
*** nucatus <nucatus!> has quit IRC (Ping timeout: 265 seconds)23:56

Generated by 2.17.2 by Marius Gedminas - find it at!