| khem | alimon: 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 #yocto | 00:00 | |
| *** xmn <xmn!~xmn@p200300c37f2e9900d5da3eae54353d65.dip0.t-ipconnect.de> has quit IRC (Quit: ZZZzzz…) | 00:00 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 00:24 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:34 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 01:15 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:36 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Read error: Connection reset by peer) | 01:52 | |
| *** hpsy <hpsy!~hpsy@85.203.20.21> has joined #yocto | 02:02 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 02:07 | |
| *** angolini <angolini!uid62003@id-62003.brockwell.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 02:11 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Quit: Leaving.) | 02:30 | |
| *** zpfvo1 <zpfvo1!~fvo@i59F44ED6.versanet.de> has joined #yocto | 02:34 | |
| *** zpfvo <zpfvo!~fvo@89.244.124.221> has quit IRC (Ping timeout: 248 seconds) | 02:36 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 02:46 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has quit IRC (Ping timeout: 245 seconds) | 02:50 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 245 seconds) | 02:53 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:54 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has joined #yocto | 03:11 | |
| *** Xagen_ <Xagen_!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 03:41 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Ping timeout: 245 seconds) | 03:43 | |
| *** amitk <amitk!~amit@103.208.69.35> has joined #yocto | 03:46 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto | 03:54 | |
| *** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds) | 04:28 | |
| *** sakoman <sakoman!~steve@172.243.4.16> 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@85.203.20.21> has quit IRC (Remote host closed the connection) | 05:09 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev) | 05:12 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 05:48 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 06:06 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has joined #yocto | 06:17 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:24 | |
| *** ant__ <ant__!~ant@host-95-237-173-57.retail.telecomitalia.it> 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 #yocto | 06:40 | |
| mihai | yo | 06:43 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 06:47 | |
| cocoJoe | good morning | 06:50 |
| *** zpfvo1 <zpfvo1!~fvo@i59F44ED6.versanet.de> has quit IRC (Quit: Leaving.) | 06:54 | |
| *** zpfvo <zpfvo!~fvo@i59F44ED6.versanet.de> has joined #yocto | 06:54 | |
| *** tre <tre!~tre@ip5f58aa1a.dynamic.kabel-deutschland.de> has joined #yocto | 07: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!~xmn@p200300c37f2e9900e11bf9577566c1c9.dip0.t-ipconnect.de> has joined #yocto | 07:34 | |
| *** bps <bps!~bps@27-reverse.bang-olufsen.dk> has joined #yocto | 07: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@31.0.173.147> has joined #yocto | 08:00 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:2a0:cb00:eb83:2e01:3dda:5d46> has joined #yocto | 08:05 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 08:06 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:12 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:15 | |
| *** tre <tre!~tre@ip5f58aa1a.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 240 seconds) | 08:26 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:28 | |
| *** tre <tre!~tre@ip5f58aa1a.dynamic.kabel-deutschland.de> has joined #yocto | 08:40 | |
| lukma | Dear Community, I do have a strange question :-) | 08:54 |
| lukma | Normally I can use FOO:remove = "bar" | 08:54 |
| lukma | but what if I do have the _bbappend file which inherites FOO with _many_ set values | 08:54 |
| lukma | I need to remove the all and then set a few new ones | 08:55 |
| lukma | I can do it with bitbake -e recipe | grep ^FOO | 08:55 |
| lukma | and then manually call FOO:remove = on the result | 08:55 |
| lukma | but I wondering if there is any better (i.e. more elegant way) to do it ? | 08:55 |
| RP | lukma: anonymous python and using setVar will reset the variable | 09:01 |
| lukma | RP: Thanks :-) | 09:06 |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has quit IRC (Quit: Leaving) | 09:07 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has joined #yocto | 09:07 | |
| lukma | RP: I've found on the Internet that _anonymous is called after the recipe is parsed | 09:11 |
| lukma | is it called before or after the bbappend is appended? | 09:11 |
| qschulz | lukma: or just FOO = "new values" ? | 09:14 |
| qschulz | provided your bbappend is the last one to be parsed (in the layer with highest priority IIRC?) | 09:14 |
| RP | lukma: after | 09:14 |
| lukma | qschulz: FOO = "new values" is not working as I do play with already set PROVIDES and RPROVIDES | 09:16 |
| qschulz | not following sorry :/ | 09:23 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 09:23 | |
| RP | qschulz: the issue is the setting FOO = will not change the previous appends | 09:40 |
| qschulz | RP: 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 #yocto | 10:14 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 10:20 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 10:23 | |
| RP | qschulz: fair enough, I guess I assumed since it was the only way the question made sense to me | 10:30 |
| qschulz | RP: yup, I just didn't guess it but that is indeed the only way the question made sense :) | 10:31 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC (Read error: Connection reset by peer) | 10:38 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has quit IRC (Ping timeout: 240 seconds) | 10:39 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has joined #yocto | 10:53 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 10:56 | |
| *** zpfvo <zpfvo!~fvo@i59F44ED6.versanet.de> has quit IRC (Quit: Leaving.) | 11:01 | |
| *** zpfvo <zpfvo!~fvo@i59F44ED6.versanet.de> has joined #yocto | 11:02 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 11:26 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Read error: Connection reset by peer) | 11:28 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 11:28 | |
| *** angolini <angolini!uid62003@id-62003.brockwell.irccloud.com> has joined #yocto | 11:37 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 11:40 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 11:46 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has quit IRC (Ping timeout: 268 seconds) | 11:46 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has joined #yocto | 11:47 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has quit IRC (Ping timeout: 248 seconds) | 11:53 | |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has joined #yocto | 11:55 | |
| *** argonautx <argonautx!~argonautx@i5E867114.versanet.de> has joined #yocto | 12:17 | |
| *** risca <risca!~quassel@h-212-85-71-156.A328.priv.bahnhof.se> has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) | 12:38 | |
| *** risca <risca!~quassel@h-212-85-71-156.A328.priv.bahnhof.se> has joined #yocto | 12:38 | |
| *** tre <tre!~tre@ip5f58aa1a.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection) | 12:42 | |
| lukma | Is Yocto/OE supporting '**' in FILES:${PN} ? | 12:44 |
| lukma | I would need to extract files with a suffix scattered accross many different directories (Already copied to S{D}) | 12:47 |
| smurray | I believe you can do e.g. /usr/*/*.foo, but if you have different depths of directory you'll need multiple file globs | 12:49 |
| lukma | Files with suffix are placed in many different directories | 12:52 |
| lukma | the depth indeed is different | 12:52 |
| smurray | the perl and go recipes do what I mentioned to handle modules, so I suspect there's not something simple to handle it | 12:54 |
| smurray | there are dynamically split packages for some things which use anonymous python in the recipe to build the variables, so that might be an approach | 12:56 |
| qschulz | you could use the do_s[plit_packages python function indeed | 13:01 |
| qschulz | since by default you pass it a regexp for the filename only | 13:01 |
| *** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:03 | |
| qschulz | with do_split_packages but then it splits each file in a different package..so might not be ideal | 13:03 |
| qschulz | lukma: reading the code of the handling of FILES, it seems like ** could be supported | 13:04 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Quit: Konversation terminated!) | 13:06 | |
| qschulz | see files_from_filevars in oe-core/classes/package.bbclass | 13:07 |
| qschulz | it uses glob.glob() which supports ** since python 3.5 | 13:07 |
| smurray | heh, I don't see any use of it in oe-core with grep, though | 13:09 |
| RP | smurray: I'd never seen it before! :) | 13:10 |
| smurray | RP: me either ;) | 13:10 |
| wCPO | Is there more to enabling a kernel config option than described here: https://docs.yoctoproject.org/kernel-dev/common.html#adding-recipe-space-kernel-features ? 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!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 13:24 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has joined #yocto | 13:28 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> 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!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 13:45 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has joined #yocto | 13:50 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 13:52 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 14:00 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto | 14:07 | |
| wCPO | oh, some smart filtering is done, so if the dependencies aren't added it is silently removed | 14:11 |
| JPEW | RP, sakoman What layers are scanned for CVEs | 14:15 |
| *** Krisso <Krisso!~Krisso@i5C744BAD.versanet.de> has joined #yocto | 14:15 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 14:15 | |
| sakoman | JPEW: I only scan oe-core | 14:15 |
| RP | JPEW: core right now but we could extend that if there was interest/support for handling the issues | 14:21 |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has joined #yocto | 14:22 | |
| qschulz | wCPO: there's a tool to create config fragments in the kernel IIRC, use that one instead of writing config fragments by hand | 14:24 |
| tlwoerner | is it possible for a recipe to interrogate the kernel config? | 14:31 |
| tlwoerner | in other words, i want to optionally include the "kmod" package in my packageconfig, but only if zram is configured as a module | 14:31 |
| tlwoerner | if zram is a built-in then i don't need kmod | 14:31 |
| wCPO | qschulz: I would do that next time, but I kinda expected it to complain and not just silently remove kernel config options | 14:32 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:32 | |
| qschulz | wCPO: the kernel does not complain IIRC, so Yocto can't do anything about it | 14:32 |
| qschulz | if it does complain (check log.do_compile to know), then maybe there's something we can do? | 14:33 |
| qschulz | tlwoerner: 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 |
| qschulz | Though what you could do is deploy this .config from your kernel recipe | 14:34 |
| qschulz | mmmmmm | 14:34 |
| qschulz | thinking about that, PACKAGECONFIG probably needs to be set during parsing so what I was about to suggest won't work | 14:35 |
| *** Guest81 <Guest81!~Guest81@64.222.164.134> has joined #yocto | 14:35 | |
| zeddii | it'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 |
| wCPO | qschulz: I will check tomorrow. I have powered off my server for today | 14:35 |
| tlwoerner | or i could just include kmod unconditionally and if it's needed it's needed, if it not it's not | 14:35 |
| qschulz | yup | 14:36 |
| qschulz | don't know exactly what are the consequences of including it, but maybe you could split the outcome of that in a different package | 14:36 |
| qschulz | and you could have an RDEPENDS_kernel-module-zram += "your-kmod-package" in a bbappend of the kernel? | 14:37 |
| tlwoerner | i have a feeling module vs built-in is going to get messy | 14:41 |
| barath | does anyone here know off-hand whether sharing the a sstate-cache directory directly is safe wrt race conditions? | 14:41 |
| barath | ie. 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 |
| barath | sry to butt in like that | 14:42 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 14:43 | |
| qschulz | barath: IIRC some servers run by YP (autobuilder?) has the sstate-cache over NFS, so I'd say yes | 14:45 |
| JPEW | barath: It is safe. sstate is designed to be shared that way | 14:45 |
| qschulz | and in any case, I've had multiple builds on my local desktop reuse the same sstate-cache without any issue :) | 14:45 |
| JPEW | You need proper file locking IIRC, so either a local file syetem or NFS | 14:45 |
| barath | that is very nice to hear. I couldn't find anything explicit about whether that was safe or not in the docs | 14:46 |
| barath | currently 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 mirrors | 14:46 |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Remote host closed the connection) | 14:46 | |
| JPEW | barath: Ya, I would recommend directly sharing it over NFS for CI-type jobs | 14:47 |
| JPEW | It's much more efficient | 14:47 |
| JPEW | We 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 themselves | 14:48 |
| barath | yeah, 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 |
| barath | I assume there arent really any docs on how yocto writes the sstate-cache files wrt locking/atomicity other than the code itself? | 14:50 |
| JPEW | barath: Probably not | 14:50 |
| tlwoerner | code makes good documentation ;-) | 14:51 |
| barath | agreed :D | 14:52 |
| barath | just more work to present to people who dont want to read it | 14:52 |
| JPEW | barath: Ya, we really need "A quick guide to setting up sstate" | 14:53 |
| barath | well 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 everything | 14:54 |
| JPEW | barath: I suspect that is common, it just doesn't scale well :) | 14:55 |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 14:55 | |
| barath | :D yes | 14:57 |
| vd | Is `if d.getVar('FOO') == '1':` valid? | 14:57 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 14:57 | |
| barath | and writing recipes without regard for how the sstate cache hashes will be calculating, leading to hash invalidation when really nothing important has changed... oh well | 14:57 |
| barath | thanks for the quick help! :) | 14:57 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 14:59 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 14:59 | |
| qschulz | vd: what's wrong with it? | 15:00 |
| vd | just asking if it's valid bitbake/python | 15:02 |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has joined #yocto | 15:07 | |
| *** Krisso <Krisso!~Krisso@i5C744BAD.versanet.de> has quit IRC (Quit: Client closed) | 15:08 | |
| RP | vd: probably, depending on where that is used | 15:09 |
| *** frieder <frieder!~frieder@mue-88-130-64-090.dsl.tropolys.de> has quit IRC (Remote host closed the connection) | 15:18 | |
| vd | Like BB_CURRENT_MC, is there a variable describe the bitbake target(s) being built? | 15:23 |
| *** Guest81 <Guest81!~Guest81@64.222.164.134> has quit IRC (Quit: Client closed) | 15:25 | |
| vd | s/describe/describing/ | 15:26 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 15:31 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 15:33 | |
| tlwoerner | if 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 #yocto | 15:38 | |
| qschulz | tlwoerner: add it to an anonymous python function and then bitbake -e recipe to check if it does :) | 15:39 |
| RP | tlwoerner: yes | 15:39 |
| tlwoerner | yes, it's working now. i was trying a bunch of stuff and it didn't seem to be working | 15:40 |
| tlwoerner | but 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 working | 15:41 |
| tlwoerner | i 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 output | 15:43 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 15:43 | |
| RP | tlwoerner: 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 not | 15:46 |
| RP | represent tasks | 15:46 |
| tlwoerner | RP: 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 instead | 15:47 |
| tlwoerner | so 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 updated | 15:48 |
| tlwoerner | which prompted the question :-) | 15:48 |
| tlwoerner | but i got it sorted out now, thanks! :-) | 15:49 |
| vd | how can I call bb.note() from a multiconfig file? | 16:02 |
| tlwoerner | so an IMAGE_FEATURE can't include a kernel module? only a MACHINE_FEATURE could do that? | 16:03 |
| tlwoerner | zeddii: that's how enabling nfs includes the nfs kernel module? | 16:04 |
| RP | tlwoerner: I don't see why an IMAGE_FEATURE couldn't do that | 16:04 |
| RP | tlwoerner: or do you mean enable rather than include? | 16:05 |
| zeddii | tlwoerner: there's a bugzilla that explains all the nuances to this. | 16:05 |
| vd | how can I print a variable from a config file? | 16:05 |
| RP | vd: XX := "${@bb.warn(d.getVar('Y'))}" maybe ? | 16:06 |
| tlwoerner | in 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 this | 16:06 |
| RP | tlwoerner: you only build the kernel once so IMAGE_FEATURE is too late to change kernel config | 16:06 |
| zeddii | tlwoerner: 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 |
| vd | RP: I see, the trick is the use a dummy variable, thanks ;) | 16:07 |
| tlwoerner | there's no point enabling zram-tmpfs in IMAGE_FEATURES if the kernel isn't configured with zram enabled | 16:07 |
| zeddii | tlwoerner: we use KERNEL_FEATURES for that, as teh decoupling mechanism. | 16:07 |
| tlwoerner | zeddii: ah! of course | 16:07 |
| zeddii | nfs isn't based on an image feature (I thought it was), sec. | 16:08 |
| zeddii | we do plenty on distro features, but there's no reason why the same for image_features isn't valid. | 16:08 |
| RP | zeddii: there is a reason - you can't change kernel config per image | 16:11 |
| RP | just which modules are installed in the image | 16:11 |
| zeddii | true. 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!~argonautx@i5E867114.versanet.de> has quit IRC (Quit: Leaving) | 16:12 | |
| tlwoerner | so maybe this suggests i should be making this a DISTRO_FEATURE instead? | 16:15 |
| zeddii | that's what I ended up doing in meta-virt for kubernetes, etc. | 16:16 |
| tlwoerner | zeddii: using a KERNEL_FEATURE means i'd have to start by submitting a .scc/.cfg option for zram to yocto-kernel-cache? | 16:19 |
| vd | RP: I get ERROR: Unable to parse Var <XX[:=]> with the := operator and with = I don't see the message | 16:19 |
| zeddii | unless 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!~fvo@i59F44ED6.versanet.de> has quit IRC (Quit: Leaving.) | 16:27 | |
| RP | vd: XX := "${@bb.warn(d.getVar('Y') or '')}" | 16:29 |
| RP | vd: means your variable is None ;-) | 16:29 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:43 | |
| *** RobR <RobR!~RobR@2601:1c0:6e00:f792:d947:be1f:674:bff3> has joined #yocto | 16:54 | |
| RobR | I'm getting 404 with https://docs.yoctoproject.org/ . Is there mirror anywhere? | 16:55 |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 16:56 | |
| RP | RobR: hmm, works here | 16:56 |
| RobR | now it's resolving to a directory tree of / | 16:57 |
| abelloni | same for me | 16:57 |
| abelloni | (Index of /) | 16:57 |
| RP | RobR: the docs build failed and seems to have broken things :( | 17:04 |
| RobR | some of the docs are still available (maybe cached | 17:05 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 17:05 | |
| RobR | thx for taking a look @RP | 17:06 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 17:07 | |
| RP | RobR: 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 | |
| paulg | meta-goldmine-of-unfixed-CVEs | 17:29 |
| *** rmmr <rmmr!sid240755@id-240755.brockwell.irccloud.com> has joined #yocto | 17:30 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 17:38 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 17:45 | |
| *** florian <florian!~florian@dynamic-078-049-129-079.78.49.pool.telefonica.de> has joined #yocto | 17:50 | |
| RP | paulg: meta-root-my-target :) | 17:55 |
| abelloni | :) | 17:55 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 18:03 | |
| alimon | khem: I can but I'm OOO for the next two weeks, may be is faster if you make it, :) | 18:15 |
| JPEW | RP: Can I get a AB test of master-next in meta-mingw? | 18:17 |
| RP | JPEW: sure | 18:19 |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/buildrequests/210741?redirect_to_build=true so queued | 18:20 |
| JPEW | RP ty | 18:20 |
| FO3 | Question 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 |
| RP | FO3: it should be deterministic based upon policy :/ | 18:30 |
| FO3 | policy ? | 18:31 |
| FO3 | poky, poky-tiny, poky-bleeding stuff like ? I will look into that. | 18:34 |
| RP | F03: if you add lib32-openssh, you should have a 32 bit openssh binary in the image | 18:36 |
| FO3 | yes but because we add lib32-systemd to have the lib; we get 32bit system executables | 18:37 |
| FO3 | because we need both 32 and 64 systemd lib. but iwould prefer to control which executable we get by default | 18:37 |
| FO3 | there seem to be something for recipes with ALTERNATE stuff in multilib.bbclass; but not for recipes w/o | 18:38 |
| *** ant__ <ant__!~ant@host-95-237-173-57.retail.telecomitalia.it> has joined #yocto | 18:44 | |
| RP | FO3: you should be able to control that by explicitly installing the one you want | 18:44 |
| FO3 | RP: Thnaks we will do more tests, but both systemd get installed, and the 32bit one seem to win in /bin | 18:50 |
| RP | FO3: I think it is configurable but I don't remember how/where | 18:54 |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has joined #yocto | 18:56 | |
| FO3 | RP: ok; i will keep looking to find how | 18:57 |
| *** ant__ <ant__!~ant@host-95-237-173-57.retail.telecomitalia.it> has quit IRC (Ping timeout: 252 seconds) | 18:58 | |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has quit IRC (Client Quit) | 18:59 | |
| *** d0ku <d0ku!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has joined #yocto | 18:59 | |
| khem | FO3: you perhaps would need to package libs into its own package and rest of systemd binaries into separate one | 19:00 |
| khem | 32bit bins should then not be picked up if there is library-only dependency | 19:01 |
| khem | only 32 bit libs will be pulled in | 19:01 |
| FO3 | ok; but i want to add lib32-systemd in my toolchain; so my old 32bit only app can link with it. | 19:03 |
| FO3 | so while building image; it doesnt knw about my app that required 32bit systemd.so 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 ones | 19:05 |
| FO3 | we were using IPK; then tryed RPM in hope of better results; but did not change anything | 19:06 |
| *** ant__ <ant__!~ant@host-95-250-170-64.retail.telecomitalia.it> has joined #yocto | 19:12 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Ping timeout: 246 seconds) | 19:21 | |
| RP | RobR: docs are fixed | 19:21 |
| RobR | RP thanks | 19:22 |
| FO3 | Thank you both; i will try to find where the rpm choose the order | 19:22 |
| smurray | RP: I think I've brute forced a solution to the asyncio loop hangs | 19:34 |
| RP | smurray: ah cool, that sounds good :) | 19:35 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 19:35 | |
| smurray | RP: 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 version | 19:38 |
| JPEW | smurray: Whats the solution? | 19:40 |
| LetoThe2nd | JPEW: how did the townhall go? | 19:41 |
| JPEW | LetoThe2nd: I though it went really well | 19:41 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 19:41 | |
| smurray | JPEW: both client and server need to always call new_event_loop and then giving that loop in a call to set_event_loop | 19:41 |
| smurray | JPEW: that makes both 3.7 and 3.9 happy | 19:42 |
| LetoThe2nd | JPEW: nice to hear! satisfactory attendee count? | 19:42 |
| JPEW | LetoThe2nd: It was between 70-100 + presenters | 19:43 |
| LetoThe2nd | JPEW: hey i think thats pretty good! | 19:44 |
| smurray | JPEW: 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 processes | 19:44 |
| JPEW | LetoThe2nd: Ya. I think a lot of the attendees did have much familiarity with Yocto or OE, so it was good outreach :) | 19:45 |
| smurray | JPEW: and get_event_loop isn't an answer as there's a usecase in the hashserv unit tests that will blow up | 19:45 |
| JPEW | LetoThe2nd: Sorry, they did *not* have familiarity | 19:46 |
| LetoThe2nd | JPEW: ya guessed that. | 19:46 |
| JPEW | LetoThe2nd: I sometimes type non-linerarly and it gets me into trouble :) | 19:46 |
| LetoThe2nd | JPEW: so do we all | 19:46 |
| LetoThe2nd | JPEW: i'm super curious how the count for the mentorship session will turn out. | 19:47 |
| JPEW | smurray: Ya, that test cases makes some things a little more difficult, but I think it's important to have | 19:47 |
| smurray | JPEW: 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 |
| JPEW | smurray: because each client has it's own loop? | 19:52 |
| smurray | JPEW: right | 19:52 |
| JPEW | hmm | 19:52 |
| smurray | JPEW: but the seemingly required calls to set_event_loop to make 3.7 not explode will break trying to do that | 19:52 |
| JPEW | smurray: That probably means you can't have more than one asyncio loop user, not just the client/server | 19:53 |
| smurray | JPEW: atm there's no other users in bitbake, I think | 19:54 |
| JPEW | Is the code for setting the loop in the Client or ASyncClient class? | 19:54 |
| smurray | JPEW: Client | 19:55 |
| JPEW | smurray: 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) anyway | 19:56 |
| smurray | JPEW: if we could force everyone to use Python 3.9 I suspect we could avoid some issues, but that's not happening anytime soon | 19:57 |
| JPEW | smurray: Sure. Perhaps make sure thats documented for posterity? | 19:57 |
| smurray | JPEW: the need to call set_event_loop seems very 3.7 specific, 3.9 worked w/o it in the client code AFAICT | 19:57 |
| JPEW | Ya, are you making it version conditional? | 19:58 |
| smurray | after spending the last 3 weeks testing I can't say I feel like doing another round of tests around that, tbh | 19:59 |
| smurray | it works on both 3.7 + 3.9 atm w/o it being conditional | 20:00 |
| JPEW | https://www.irccloud.com/pastebin/Q8F84pkT/ | 20:00 |
| smurray | what would be the benefit of that, exactly? | 20:01 |
| JPEW | It would work with multiple clients | 20:01 |
| smurray | all these task processes are short-lived effectively | 20:01 |
| smurray | on the client side I actually don't quite understand how asyncio is particularly useful | 20:02 |
| JPEW | smurray: Ya, fair. As long as we know what the limitations are (e.g. with a comment), we should be OK | 20:02 |
| smurray | JPEW: I'll add some comments, if you want to grind on debugging it for several weeks more, you can ;) | 20:04 |
| smurray | JPEW: 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 in | 20:05 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 20:10 | |
| vd | Why are BUILDNAME and BBTARGETS empty? | 20:10 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 20:16 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 20:17 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 20:23 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 20:29 | |
| *** amitk <amitk!~amit@103.208.69.35> has quit IRC (Ping timeout: 268 seconds) | 20:41 | |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 20:48 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 21:13 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> 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@31.0.173.147> has quit IRC (Ping timeout: 240 seconds) | 21:52 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 21:54 | |
| vd | I 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!~d0ku@178.43.198.70.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 268 seconds) | 22:07 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:501a:e201:7dd8:7bb5:b166:9697> has joined #yocto | 22:09 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 22:23 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 22:32 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 22:50 | |
| tp43_ | I got a pl2303 cable only $1 | 22:55 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 22:56 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 22:58 | |
| *** florian <florian!~florian@dynamic-078-049-129-079.78.49.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 23:15 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Read error: Connection reset by peer) | 23:25 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 23:25 | |
| vmeson | vd: Do you have more context about: Why are BUILDNAME and BBTARGETS empty? | 23:37 |
| vmeson | tp43_: congrats! ;-) | 23:37 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!