Wednesday, 2021-08-18

khemalimon:  I see, I think some packaging files are different perhaps. We could move it to meta-oe dynamic layers perhaps would you mind creating a patch ?00:00
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto00:00
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)00:00
*** vd <vd!> has joined #yocto00:24
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!> has joined #yocto00:34
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)01:15
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)01:36
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)01:52
*** hpsy <hpsy!~hpsy@> has joined #yocto02:02
*** sakoman <sakoman!~steve@> has joined #yocto02:07
*** angolini <angolini!> has quit IRC (Quit: Connection closed for inactivity)02:11
*** sakoman <sakoman!~steve@> has quit IRC (Quit: Leaving.)02:30
*** zpfvo1 <zpfvo1!> has joined #yocto02:34
*** zpfvo <zpfvo!~fvo@> has quit IRC (Ping timeout: 248 seconds)02:36
*** sakoman <sakoman!~steve@> has joined #yocto02:46
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has quit IRC (Ping timeout: 245 seconds)02:50
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 245 seconds)02:53
*** camus <camus!~Instantbi@> has joined #yocto02:54
*** cocoJoe <cocoJoe!> has joined #yocto03:11
*** Xagen_ <Xagen_!> has joined #yocto03:41
*** Xagen <Xagen!> has quit IRC (Ping timeout: 245 seconds)03:43
*** amitk <amitk!~amit@> has joined #yocto03:46
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto03:54
*** paulg <paulg!> has quit IRC (Ping timeout: 240 seconds)04:28
*** sakoman <sakoman!~steve@> has quit IRC (Quit: Leaving.)04:53
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has quit IRC (Ping timeout: 245 seconds)05:01
*** hpsy <hpsy!~hpsy@> has quit IRC (Remote host closed the connection)05:09
*** roussinm <roussinm!> has quit IRC (Quit: WeeChat 3.3-dev)05:12
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:48
*** davidinux <davidinux!~davidinux@> has joined #yocto06:06
*** frieder <frieder!> has joined #yocto06:17
*** rob_w <rob_w!> has joined #yocto06:24
*** ant__ <ant__!> has quit IRC (Quit: Leaving)06:28
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:40
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:47
cocoJoegood morning06:50
*** zpfvo1 <zpfvo1!> has quit IRC (Quit: Leaving.)06:54
*** zpfvo <zpfvo!> has joined #yocto06:54
*** tre <tre!> has joined #yocto07:06
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds)07:21
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)07:25
*** xmn <xmn!> has joined #yocto07:34
*** bps <bps!> has joined #yocto07:59
*** kanavin <kanavin!~Alexander@2a02:2454:2a0:cb00:eb83:2e01:3dda:5d46> has quit IRC (Remote host closed the connection)08:00
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto08:00
*** kanavin <kanavin!~Alexander@2a02:2454:2a0:cb00:eb83:2e01:3dda:5d46> has joined #yocto08:05
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto08:06
*** prabhakarlad <prabhakarlad!> has joined #yocto08:12
*** florian <florian!> has joined #yocto08:15
*** tre <tre!> has quit IRC (Ping timeout: 240 seconds)08:26
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:28
*** tre <tre!> has joined #yocto08:40
lukmaDear Community, I do have a strange question :-)08:54
lukmaNormally I can use FOO:remove = "bar"08:54
lukmabut what if I do have the _bbappend file which inherites FOO with _many_ set values08:54
lukmaI need to remove the all and then set a few new ones08:55
lukmaI can do it with bitbake -e recipe | grep ^FOO08:55
lukmaand then manually call FOO:remove = on the result08:55
lukmabut I wondering if there is any better (i.e. more elegant way) to do it ?08:55
RPlukma: anonymous python and using setVar will reset the variable09:01
lukmaRP: Thanks :-)09:06
*** frieder <frieder!> has quit IRC (Quit: Leaving)09:07
*** frieder <frieder!> has joined #yocto09:07
lukmaRP: I've found on the Internet that _anonymous is called after the recipe is parsed09:11
lukmais it called before or after the bbappend is appended?09:11
qschulzlukma: or just FOO = "new values" ?09:14
qschulzprovided your bbappend is the last one to be parsed (in the layer with highest priority IIRC?)09:14
RPlukma: after09:14
lukmaqschulz: FOO = "new values" is not working as I do play with already set PROVIDES and RPROVIDES09:16
qschulznot following sorry :/09:23
*** hpsy <hpsy!~hpsy@> has joined #yocto09:23
RPqschulz: the issue is the setting FOO =  will not change the previous appends09:40
qschulzRP: there was no mention of _append or _prepend in the question :)09:50
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)10:13
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto10:14
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)10:20
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto10:23
RPqschulz: fair enough, I guess I assumed since it was the only way the question made sense to me10:30
qschulzRP: yup, I just didn't guess it but that is indeed the only way the question made sense :)10:31
*** hpsy <hpsy!~hpsy@> has quit IRC (Read error: Connection reset by peer)10:38
*** frieder <frieder!> has quit IRC (Ping timeout: 240 seconds)10:39
*** frieder <frieder!> has joined #yocto10:53
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto10:56
*** zpfvo <zpfvo!> has quit IRC (Quit: Leaving.)11:01
*** zpfvo <zpfvo!> has joined #yocto11:02
*** jwillikers <jwillikers!> has joined #yocto11:26
*** vmeson <vmeson!> has quit IRC (Read error: Connection reset by peer)11:28
*** vmeson <vmeson!> has joined #yocto11:28
*** angolini <angolini!> has joined #yocto11:37
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)11:40
*** jwillikers <jwillikers!> has joined #yocto11:46
*** frieder <frieder!> has quit IRC (Ping timeout: 268 seconds)11:46
*** frieder <frieder!> has joined #yocto11:47
*** frieder <frieder!> has quit IRC (Ping timeout: 248 seconds)11:53
*** frieder <frieder!> has joined #yocto11:55
*** argonautx <argonautx!> has joined #yocto12:17
*** risca <risca!> has quit IRC (Quit: - Chat comfortably. Anywhere.)12:38
*** risca <risca!> has joined #yocto12:38
*** tre <tre!> has quit IRC (Remote host closed the connection)12:42
lukmaIs Yocto/OE supporting '**' in FILES:${PN} ?12:44
lukmaI would need to extract files with a suffix scattered accross many different directories (Already copied to S{D})12:47
smurrayI believe you can do e.g. /usr/*/*.foo, but if you have different depths of directory you'll need multiple file globs12:49
lukmaFiles with suffix are placed in many different directories12:52
lukmathe depth indeed is different12:52
smurraythe perl and go recipes do what I mentioned to handle modules, so I suspect there's not something simple to handle it12:54
smurraythere are dynamically split packages for some things which use anonymous python in the recipe to build the variables, so that might be an approach12:56
qschulzyou could use the do_s[plit_packages python function indeed13:01
qschulzsince by default you pass it a regexp for the filename only13:01
*** paulg <paulg!> has joined #yocto13:03
qschulzwith do_split_packages but then it splits each file in a different might not be ideal13:03
qschulzlukma: reading the code of the handling of FILES, it seems like ** could be supported13:04
*** vmeson <vmeson!> has quit IRC (Quit: Konversation terminated!)13:06
qschulzsee files_from_filevars in oe-core/classes/package.bbclass13:07
qschulzit uses glob.glob() which supports ** since python 3.513:07
smurrayheh, I don't see any use of it in oe-core with grep, though13:09
RPsmurray: I'd never seen it before! :)13:10
smurrayRP: me either ;)13:10
wCPOIs there more to enabling a kernel config option than described here: ? I did everything as described and "test.scc" is copied to build/tmp/work/genericx86_64-poky-linux/linux-yocto/5.10.43+gitAUTOINC+3f38ad49cf_ab49d2db98-r0 but it isn't enabling the option.13:14
*** cocoJoe <cocoJoe!> has quit IRC (Quit: Client closed)13:24
*** cocoJoe <cocoJoe!> has joined #yocto13:28
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)13:31
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Read error: Connection reset by peer)13:34
*** cocoJoe <cocoJoe!> has quit IRC (Quit: Client closed)13:45
*** cocoJoe <cocoJoe!> has joined #yocto13:50
*** prabhakarlad <prabhakarlad!> has joined #yocto13:52
*** sakoman <sakoman!~steve@> has joined #yocto14:00
*** roussinm <roussinm!> has joined #yocto14:07
wCPOoh, some smart filtering is done, so if the dependencies aren't added it is silently removed14:11
JPEWRP, sakoman What layers are scanned for CVEs14:15
*** Krisso <Krisso!> has joined #yocto14:15
*** cocoJoe <cocoJoe!> has quit IRC (Quit: Client closed)14:15
sakomanJPEW: I only scan oe-core14:15
RPJPEW: core right now but we could extend that if there was interest/support for handling the issues14:21
*** cocoJoe <cocoJoe!> has joined #yocto14:22
qschulzwCPO: there's a tool to create config fragments in the kernel IIRC, use that one instead of writing config fragments by hand14:24
tlwoerneris it possible for a recipe to interrogate the kernel config?14:31
tlwoernerin other words, i want to optionally include the "kmod" package in my packageconfig, but only if zram is configured as a module14:31
tlwoernerif zram is a built-in then i don't need kmod14:31
wCPOqschulz: I would do that next time, but I kinda expected it to complain and not just silently remove kernel config options14:32
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:32
qschulzwCPO: the kernel does not complain IIRC, so Yocto can't do anything about it14:32
qschulzif it does complain (check log.do_compile to know), then maybe there's something we can do?14:33
qschulztlwoerner: you would need to read the .config of the kernel recipe to know that. Except if there's some special handling somewhere... recipe data is local, so you can't access it from another recipe.14:34
qschulzThough what you could do is deploy this .config from your kernel recipe14:34
qschulzthinking about that, PACKAGECONFIG probably needs to be set during parsing so what I was about to suggest won't work14:35
*** Guest81 <Guest81!~Guest81@> has joined #yocto14:35
zeddiiit's generally a bad idea to attempt to link packaging decisions to the .config like that. The names of the values, etc, change over time. It just needs to be explicit, with some potentially installed packages that aren't always required.14:35
wCPOqschulz: I will check tomorrow. I have powered off my server for today14:35
tlwoerneror i could just include kmod unconditionally and if it's needed it's needed, if it not it's not14:35
qschulzdon't know exactly what are the consequences of including it, but maybe you could split the outcome of that in a different package14:36
qschulzand you could have an RDEPENDS_kernel-module-zram += "your-kmod-package" in a bbappend of the kernel?14:37
tlwoerneri have a feeling module vs built-in is going to get messy14:41
barathdoes anyone here know off-hand whether sharing the a sstate-cache directory directly is safe wrt race conditions?14:41
barathie. if I share a sstate-cache directory directly, can I end up in a situation where someone downloads a sstate-cache file while it's being written, causing the downloader to attempt to use an incomplete sstate-cache file?14:42
barathsry to butt in like that14:42
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)14:43
qschulzbarath: IIRC some servers run by YP (autobuilder?) has the sstate-cache over NFS, so I'd say yes14:45
JPEWbarath: It is safe. sstate is designed to be shared that way14:45
qschulzand in any case, I've had multiple builds on my local desktop reuse the same sstate-cache without any issue :)14:45
JPEWYou need proper file locking IIRC, so either a local file syetem or NFS14:45
baraththat is very nice to hear. I couldn't find anything explicit about whether that was safe or not in the docs14:46
barathcurrently we copy the sstate-cache from several builder nodes to a central server to be served from, but it sounds like that's not even really necessary except to avoid having to query multiple sstate mirrors14:46
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection)14:46
JPEWbarath: Ya, I would recommend directly sharing it over NFS for CI-type jobs14:47
JPEWIt's much more efficient14:47
JPEWWe then export the cache via HTTP, which our developers point there local builds at as a mirror, so if CI has built something before, the developers will just download it instead of building it themselves14:48
barathyeah, we currently try to build everything during the night on those nodes and then we aggregate it by rsyncing it to a single http server. we've had weird issues sometimes where sstate-cache are seemingly corrupted, and it would be nice to exclude any unecessary steps and just point people directly to the sstate-cache directories...14:49
barathI assume there arent really any docs on how yocto writes the sstate-cache files wrt locking/atomicity other than the code itself?14:50
JPEWbarath: Probably not14:50
tlwoernercode makes good documentation ;-)14:51
barathagreed :D14:52
barathjust more work to present to people who dont want to read it14:52
JPEWbarath: Ya, we really need "A quick guide to setting up sstate"14:53
barathwell it seems an easy enough concept in itself, apparently whoever first set up our yocto workflow didn't get the message of aggressively sstate-caching and premirroring everything14:54
JPEWbarath: I suspect that is common, it just doesn't scale well :)14:55
*** cocoJoe <cocoJoe!> has quit IRC (Quit: Client closed)14:55
barath:D yes14:57
vdIs `if d.getVar('FOO') == '1':` valid?14:57
*** prabhakarlad <prabhakarlad!> has joined #yocto14:57
barathand writing recipes without regard for how the sstate cache hashes will be calculating, leading to hash invalidation when really nothing important has changed... oh well14:57
baraththanks for the quick help! :)14:57
*** vmeson <vmeson!> has joined #yocto14:59
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto14:59
qschulzvd: what's wrong with it?15:00
vdjust asking if it's valid bitbake/python15:02
*** cocoJoe <cocoJoe!> has joined #yocto15:07
*** Krisso <Krisso!> has quit IRC (Quit: Client closed)15:08
RPvd: probably, depending on where that is used15:09
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:18
vdLike BB_CURRENT_MC, is there a variable describe the bitbake target(s) being built?15:23
*** Guest81 <Guest81!~Guest81@> has quit IRC (Quit: Client closed)15:25
*** vd <vd!> has quit IRC (Quit: Client closed)15:31
*** vd <vd!> has joined #yocto15:33
tlwoernerif i do a d.setVar() with a variable that doesn't exist, will it be created?15:37
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:38
qschulztlwoerner: add it to an anonymous python function and then bitbake -e recipe to check if it does :)15:39
RPtlwoerner: yes15:39
tlwoerneryes, it's working now. i was trying a bunch of stuff and it didn't seem to be working15:40
tlwoernerbut i think bitbake didn't think my changes required a respin so the output file wasn't getting updated, but after a -c cleansstate it's working15:41
tlwoerneri was trying little incremental changes in a python __anonymous function and the output wasn't changing, but after i did a cleansstate i got the correct output15:43
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)15:43
RPtlwoerner: the hashes that represent hashes can't look into anon python so it would depend whether the variables the code is changing are already in the hash or not15:46
RPrepresent tasks15:46
tlwoernerRP: i see. originally the variable was outside the anoymous function and could be fiddled with by the user. but then i realized that it would make more sense for the variable to be set inside the anonymous function depending on a set of criteria instead15:47
tlwoernerso as i moved the variable inside the anonymous and fiddles with the correct python syntax (originally i was just trying to create/set the variable directly and not using d.setVar()) it wasn't getting updated15:48
tlwoernerwhich prompted the question :-)15:48
tlwoernerbut i got it sorted out now, thanks! :-)15:49
vdhow can I call bb.note() from a multiconfig file?16:02
tlwoernerso an IMAGE_FEATURE can't include a kernel module? only a MACHINE_FEATURE could do that?16:03
tlwoernerzeddii: that's how enabling nfs includes the nfs kernel module?16:04
RPtlwoerner: I don't see why an IMAGE_FEATURE couldn't do that16:04
RPtlwoerner: or do you mean enable rather than include?16:05
zeddiitlwoerner: there's a bugzilla that explains all the nuances to this.16:05
vdhow can I print a variable from a config file?16:05
RPvd: XX := "${@bb.warn(d.getVar('Y'))}" maybe ?16:06
tlwoernerin yesterday's call i asked about having an IMAGE_FEATURE include/rrecommend a kernel config and zeddii said this is what nfs is doing, so i was trying to track down how nfs is doing this16:06
RPtlwoerner: you only build the kernel once so IMAGE_FEATURE is too late to change kernel config16:06
zeddiitlwoerner: due to kernel versions, machine capabilities, etc, there's no universally generic way to do it. If you use kernel fragments, the closest thing is to have KERNEL_FEATURES, which error or can be checked if they aren't set. otherwise, you are binding yourself to kernel recipes, versions and mucking around.16:06
vdRP: I see, the trick is the use a dummy variable, thanks ;)16:07
tlwoernerthere's no point enabling zram-tmpfs in IMAGE_FEATURES if the kernel isn't configured with zram enabled16:07
zeddiitlwoerner: we use KERNEL_FEATURES for that, as teh decoupling mechanism.16:07
tlwoernerzeddii: ah! of course16:07
zeddiinfs isn't based on an image feature (I thought it was), sec.16:08
zeddiiwe do plenty on distro features, but there's no reason why the same for image_features isn't valid.16:08
RPzeddii: there is a reason - you can't change kernel config per image16:11
RPjust which modules are installed in the image16:11
zeddiitrue. I was just thinking of it as a variable, that someone can set to change things. but that's distro changes in this case.16:11
*** argonautx <argonautx!> has quit IRC (Quit: Leaving)16:12
tlwoernerso maybe this suggests i should be making this a DISTRO_FEATURE instead?16:15
zeddiithat's what I ended up doing in meta-virt for kubernetes, etc.16:16
tlwoernerzeddii: using a KERNEL_FEATURE means i'd have to start by submitting a .scc/.cfg option for zram to yocto-kernel-cache?16:19
vdRP: I get ERROR: Unable to parse Var <XX[:=]> with the := operator and with = I don't see the message16:19
zeddiiunless the feature is in it's own layer, yes.16:19
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds)16:26
*** zpfvo <zpfvo!> has quit IRC (Quit: Leaving.)16:27
RPvd: XX := "${@bb.warn(d.getVar('Y') or '')}"16:29
RPvd: means your variable is None ;-)16:29
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:43
*** RobR <RobR!~RobR@2601:1c0:6e00:f792:d947:be1f:674:bff3> has joined #yocto16:54
RobRI'm getting 404 with . Is there mirror anywhere?16:55
*** bps <bps!> has joined #yocto16:56
RPRobR: hmm, works here16:56
RobRnow it's resolving to a directory tree of /16:57
abellonisame for me16:57
abelloni(Index of /)16:57
RPRobR: the docs build failed and seems to have broken things :(17:04
RobRsome of the docs are still available (maybe cached17:05
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)17:05
RobRthx for taking a look @RP17:06
*** jwillikers <jwillikers!> has joined #yocto17:07
RPRobR: I think I know how to fix it, working on it :)17:08
RobR@RP (y)17:09
* RP notes meta-gplv2 broke again :(17:25
*** rmmr <rmmr!> has joined #yocto17:30
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)17:38
*** jwillikers <jwillikers!> has joined #yocto17:45
*** florian <florian!> has joined #yocto17:50
RPpaulg: meta-root-my-target :)17:55
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)18:03
alimonkhem: I can but I'm OOO for the next two weeks, may be is faster if you make it, :)18:15
JPEWRP: Can I get a AB test of master-next in meta-mingw?18:17
RPJPEW: sure18:19
RPJPEW: so queued18:20
JPEWRP ty18:20
FO3Question about multilib: We enabled, both lib get created, but bin seem to be randomly a mixt of 32 and 64bits executables. For recipes that have both libraries and bin in them (like systemd). Any idea on how to fix that ? (We tryed both IPK and RPM)18:27
RPFO3: it should be deterministic based upon policy :/18:30
FO3policy ?18:31
FO3poky, poky-tiny, poky-bleeding  stuff like ? I will look into that.18:34
RPF03: if you add lib32-openssh, you should have a 32 bit openssh binary in the image18:36
FO3yes but because we add lib32-systemd to have the lib; we get 32bit system executables18:37
FO3because we need both 32 and 64 systemd lib.  but iwould prefer to control which executable we get by default18:37
FO3there seem to be something for recipes with ALTERNATE stuff in multilib.bbclass; but not for recipes w/o18:38
*** ant__ <ant__!> has joined #yocto18:44
RPFO3: you should be able to control that by explicitly installing the one you want18:44
FO3RP: Thnaks we will do more tests, but both systemd get installed, and the 32bit one seem to win in /bin18:50
RPFO3: I think it is configurable but I don't remember how/where18:54
*** d0ku <d0ku!> has joined #yocto18:56
FO3RP: ok; i will keep looking to find how18:57
*** ant__ <ant__!> has quit IRC (Ping timeout: 252 seconds)18:58
*** d0ku <d0ku!> has quit IRC (Client Quit)18:59
*** d0ku <d0ku!> has joined #yocto18:59
khemFO3: you perhaps would need to package libs into its own package and rest of systemd binaries into separate one19:00
khem32bit bins should then not be picked up if there is library-only dependency19:01
khemonly 32 bit libs will be pulled in19:01
FO3ok; but i want to add lib32-systemd in my toolchain; so my old 32bit only app can link with it.19:03
FO3so while building image; it doesnt knw about my app that required 32bit       so we added lib32-systemd in IMAGE_INSTALL  that bring both exe; but 32bits seem to win. I saw in the doc; that for RPM; the normal one get installed firs then the multilib ones19:05
FO3we were using IPK; then tryed RPM in hope of better results; but did not change anything19:06
*** ant__ <ant__!> has joined #yocto19:12
*** vd <vd!> has quit IRC (Ping timeout: 246 seconds)19:21
RPRobR: docs are fixed19:21
RobRRP thanks19:22
FO3Thank you both; i will try to find where the rpm choose the order19:22
smurrayRP: I think I've brute forced a solution to the asyncio loop hangs19:34
RPsmurray: ah cool, that sounds good :)19:35
*** LetoThe2nd <LetoThe2nd!> has joined #yocto19:35
smurrayRP: I can sort of imagine something clever with a custom event loop policy (which in theory could transparently ensure a different loop per process/thread), but that seems like another can of worms wrt Python version19:38
JPEWsmurray: Whats the solution?19:40
LetoThe2ndJPEW: how did the townhall go?19:41
JPEWLetoThe2nd: I though it went really well19:41
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)19:41
smurrayJPEW: both client and server need to always call new_event_loop and then giving that loop in a call to set_event_loop19:41
smurrayJPEW: that makes both 3.7 and 3.9 happy19:42
LetoThe2ndJPEW: nice to hear! satisfactory attendee count?19:42
JPEWLetoThe2nd: It was between 70-100 + presenters19:43
LetoThe2ndJPEW: hey i think thats pretty good!19:44
smurrayJPEW: the wrinkle that was biting with 3.7 was repeated use of new_event_loop in the client w/o set_event_loop seems to blow up eventually in the bitbake-server processes19:44
JPEWLetoThe2nd: Ya. I think a lot of the attendees did have much familiarity with Yocto or OE, so it was good outreach :)19:45
smurrayJPEW: and get_event_loop isn't an answer as there's a usecase in the hashserv unit tests that will blow up19:45
JPEWLetoThe2nd: Sorry, they did *not* have familiarity19:46
LetoThe2ndJPEW: ya guessed that.19:46
JPEWLetoThe2nd: I sometimes type non-linerarly and it gets me into trouble :)19:46
LetoThe2ndJPEW: so do we all19:46
LetoThe2ndJPEW: i'm super curious how the count for the mentorship session will turn out.19:47
JPEWsmurray: Ya, that test cases makes some things a little more difficult, but I think it's important to have19:47
smurrayJPEW: with my changes it'll be impossible to write code that runs the server and client or even the 2 different clients in the same process w/o some potential issues, but it no longer hangs in selftests anymore...19:51
JPEWsmurray: because each client has it's own loop?19:52
smurrayJPEW: right19:52
smurrayJPEW: but the seemingly required calls to set_event_loop to make 3.7 not explode will break trying to do that19:52
JPEWsmurray: That probably means you can't have more than one asyncio loop user, not just the client/server19:53
smurrayJPEW: atm there's no other users in bitbake, I think19:54
JPEWIs the code for setting the loop in the Client or ASyncClient class?19:54
smurrayJPEW: Client19:55
JPEWsmurray: K, I don't think that one would work with multiple other asyncio users anyway... if your doing that you need to use ASyncClient (and provide your own loop) anyway19:56
smurrayJPEW: if we could force everyone to use Python 3.9 I suspect we could avoid some issues, but that's not happening anytime soon19:57
JPEWsmurray: Sure. Perhaps make sure thats documented for posterity?19:57
smurrayJPEW: the need to call set_event_loop seems very 3.7 specific, 3.9 worked w/o it in the client code AFAICT19:57
JPEWYa, are you making it version conditional?19:58
smurrayafter spending the last 3 weeks testing I can't say I feel like doing another round of tests around that, tbh19:59
smurrayit works on both 3.7 + 3.9 atm w/o it being conditional20:00
smurraywhat would be the benefit of that, exactly?20:01
JPEWIt would work with multiple clients20:01
smurrayall these task processes are short-lived effectively20:01
smurrayon the client side I actually don't quite understand how asyncio is particularly useful20:02
JPEWsmurray: Ya, fair. As long as we know what the limitations are (e.g. with a comment), we should be OK20:02
smurrayJPEW: I'll add some comments, if you want to grind on debugging it for several weeks more, you can ;)20:04
smurrayJPEW: at this point if these changes don't pass autobuilder my next step will be just dropping asyncio for PR server for now to get the read-only support in20:05
*** vd <vd!> has joined #yocto20:10
vdWhy are BUILDNAME and BBTARGETS empty?20:10
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto20:16
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)20:17
*** prabhakarlad <prabhakarlad!> has joined #yocto20:23
*** vd <vd!> has quit IRC (Quit: Client closed)20:29
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 268 seconds)20:41
*** bps <bps!> has joined #yocto20:48
*** vd <vd!> has joined #yocto21:13
*** cocoJoe <cocoJoe!> has quit IRC (Quit: Client closed)21:16
*** RobR <RobR!~RobR@2601:1c0:6e00:f792:d947:be1f:674:bff3> has quit IRC (Quit: Client closed)21:17
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Ping timeout: 240 seconds)21:52
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto21:54
vdI get a weird error with my .mount unit: "must be superuser to use mount", but there's only root on the system...21:59
*** d0ku <d0ku!> has quit IRC (Ping timeout: 268 seconds)22:07
*** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto22:09
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)22:23
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)22:32
*** prabhakarlad <prabhakarlad!> has joined #yocto22:50
tp43_I got a pl2303 cable only $122:55
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)22:56
*** jwillikers <jwillikers!> has quit IRC (Remote host closed the connection)22:58
*** florian <florian!> has quit IRC (Ping timeout: 240 seconds)23:15
*** tlwoerner <tlwoerner!> has quit IRC (Read error: Connection reset by peer)23:25
*** tlwoerner <tlwoerner!> has joined #yocto23:25
vmesonvd:  Do you have more context about: Why are BUILDNAME and BBTARGETS empty?23:37
vmesontp43_:  congrats! ;-)23:37

Generated by 2.17.2 by Marius Gedminas - find it at!