| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 00:17 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has quit IRC (Quit: Konversation terminated!) | 00:28 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:29 | |
| *** florian <florian!~florian@dynamic-089-013-059-224.89.13.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 00:41 | |
| *** zkrx <zkrx!~slimshady@2001:1715:9d9e:65f0:7920:e61a:8dcb:a372> has quit IRC (Ping timeout: 260 seconds) | 00:53 | |
| *** zkrx <zkrx!~slimshady@adsl-89-217-230-95.adslplus.ch> has joined #yocto | 00:59 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 01:03 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 01:03 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 01:10 | |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 01:19 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 260 seconds) | 01:39 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 01:39 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 01:40 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 01:40 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 01:43 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 246 seconds) | 01:43 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 01:44 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 268 seconds) | 01:59 | |
| *** mckoan|away <mckoan|away!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 02:00 | |
| *** davidinux <davidinux!~davidinux@81.22.36.156> has quit IRC (Ping timeout: 248 seconds) | 02:03 | |
| *** davidinux <davidinux!~davidinux@138.199.54.237> has joined #yocto | 02:05 | |
| *** Bardon_ <Bardon_!~Bardon@user/Bardon> has quit IRC (Ping timeout: 255 seconds) | 02:09 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 02:13 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 02:13 | |
| *** Bardon <Bardon!~Bardon@user/Bardon> has joined #yocto | 02:33 | |
| *** jclsn_ <jclsn_!~jclsn@2a04:4540:650b:9800:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 252 seconds) | 03:05 | |
| *** jclsn_ <jclsn_!~jclsn@2a04:4540:653a:d000:2ce:39ff:fecf:efcd> has joined #yocto | 03:07 | |
| *** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection) | 03:46 | |
| *** jclsn_ <jclsn_!~jclsn@2a04:4540:653a:d000:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds) | 04:02 | |
| *** jclsn_ <jclsn_!~jclsn@2a04:4540:651f:6700:2ce:39ff:fecf:efcd> has joined #yocto | 04:04 | |
| *** amitk <amitk!~amit@103.208.69.103> has joined #yocto | 05:09 | |
| *** davidinux <davidinux!~davidinux@138.199.54.237> has quit IRC (Quit: WeeChat 3.5) | 05:48 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:10 | |
| *** davidinux <davidinux!~davidinux@92.118.62.54> has joined #yocto | 06:22 | |
| *** olani- <olani-!~olani@66.159.215.7> has quit IRC (Ping timeout: 252 seconds) | 06:26 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:34 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:35 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 07:11 | |
| *** rob_w <rob_w!~rob@2001:a61:60dc:3e01:9d52:da62:96ab:8525> has joined #yocto | 07:13 | |
| *** davidinux <davidinux!~davidinux@92.118.62.54> has quit IRC (Ping timeout: 248 seconds) | 07:13 | |
| *** davidinux <davidinux!~davidinux@92.118.62.56> has joined #yocto | 07:15 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 07:27 | |
| *** frieder <frieder!~frieder@200116b8244fe4810000000000001cba.dip.versatel-1u1.de> has joined #yocto | 07:45 | |
| *** mckoan|away is now known as mckoan | 07:46 | |
| LetoThe2nd | yo dudX | 07:52 |
|---|---|---|
| mckoan | hi LetoThe2nd | 07:55 |
| *** zpfvo <zpfvo!~fvo@i59F5CF5B.versanet.de> has joined #yocto | 08:06 | |
| *** zpfvo1 <zpfvo1!~fvo@i59F5CF5B.versanet.de> has joined #yocto | 08:11 | |
| *** Jham <Jham!~Juba@2a01:e0a:177:a830:bd11:6f60:a3dd:e932> has joined #yocto | 08:12 | |
| *** zpfvo <zpfvo!~fvo@i59F5CF5B.versanet.de> has quit IRC (Ping timeout: 264 seconds) | 08:15 | |
| kayterina[m] | Hello, I ran 'bitbake world --dry-run' in my project. I have audio removed from DISTRO_DEATURES, is it logical that I get "Nothing RPROVIDES 'pulseaudio-<anything>" errors? | 08:19 |
| KareemZarka[m] | Hi everyone... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0ac902c139179a532754230ad485d34a9a38fe1c>) | 08:20 |
| LetoThe2nd | KareemZarka[m]: can you maybe give a one-sentence summary? we only got a link. | 08:22 |
| landgraf | KareemZarka[m]: most of the people in the channel are on IRC not Matrix | 08:23 |
| landgraf | KareemZarka[m]: So use one string messages and pastebin to paste logs etc | 08:23 |
| LetoThe2nd | landgraf: weren't you working on quite some autobuilder stuff lately? | 08:24 |
| landgraf | LetoThe2nd: No. I've not touched autobilder at all | 08:26 |
| LetoThe2nd | landgraf: then I'm confusing you with somebody else, sorry. | 08:26 |
| landgraf | LetoThe2nd: No problem. I'm used to it :D | 08:28 |
| KareemZarka[m] | so I'm asking what would be the right approach to change a behavior of a plugin ? , for example in bootimg-efi I want to comment out some lines in that class that are in charge of installing the kernel-imge into the boot partition | 08:29 |
| KareemZarka[m] | KareemZarka[m]: maybe a patch ? | 08:29 |
| *** gsalazar <gsalazar!~gsalazar@139.0.166.178.rev.vodafone.pt> has joined #yocto | 08:30 | |
| landgraf | LetoThe2nd: I worked with Douglas Landgraf at Red Hat and now I work with the guy who has exact same first name and last name at Suse. You can imagine how often people (and systems) are confused :D | 08:30 |
| landgraf | KareemZarka[m]: make in cofigurable (not just comment out) and submit a patch | 08:31 |
| LetoThe2nd | landgraf: in for some fun! | 08:31 |
| landgraf | if it's not already done | 08:31 |
| KareemZarka[m] | landgraf: can you elaborate on what you mean by 'make in configurable`? | 08:32 |
| landgraf | KareemZarka[m]: if bb.getVar("MY_FEATURE_FLAG"): | 08:34 |
| frieder | Hi, I'm using devtool upgrade && devtool finish on a recipe with git source. | 08:38 |
| frieder | The SRCREV is updated just fine, but devtool always rewrites my conditional SRC_URI override | 08:38 |
| frieder | So SRC_URI:append:test = "file://example.conf" is turned into SRC_URI += "file://example.conf" | 08:38 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:39 | |
| frieder | Is there a way to make devtool preserve the SRC_URI override? | 08:39 |
| KareemZarka[m] | <landgraf> "Kareem Zarka: if bb.getVar("..." <- so you're saying a pass a flag from the kickstart file then I check if that flag was passed ,then if so I proceed with comment changes , otherwise the plugin code contiues as it was originally ? did I get that right ? | 08:39 |
| KareemZarka[m] | s/a/I/ | 08:39 |
| landgraf | KareemZarka[m]: yes, don't break existing flow unless it's broken or unexpected already | 08:43 |
| KareemZarka[m] | landgraf: right thanks , I appreciate it | 08:43 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:45 | |
| landgraf | KareemZarka[m]: np | 08:46 |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving) | 09:00 | |
| *** amitk_ <amitk_!~amit@103.59.74.183> has joined #yocto | 09:10 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:16 | |
| *** davidinux <davidinux!~davidinux@92.118.62.56> has quit IRC (Ping timeout: 256 seconds) | 09:18 | |
| d-fens | how should wthis be handled: i have a receipt that pulls some code from git into /home/pi/code and ther is also a "chown -R pi:pi ${D}/home/pi" command which fails as the user doesn't exist yet , the image file inherits "useradd" and creates the users | 09:18 |
| *** davidinux <davidinux!~davidinux@194.147.59.205> has joined #yocto | 09:19 | |
| d-fens | hmm pkg_postinst_${PN}{ looks promising | 09:21 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 248 seconds) | 09:33 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 09:35 | |
| *** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has quit IRC (Ping timeout: 252 seconds) | 09:36 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 09:39 | |
| *** manuel__ <manuel__!~manuel198@62.99.131.178> has quit IRC (Ping timeout: 252 seconds) | 09:41 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 09:46 | |
| *** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto | 09:49 | |
| *** ptsneves <ptsneves!~Thunderbi@84.47.155.82> has joined #yocto | 09:58 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:12 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 10:24 | |
| lukma | Dear all, I do have a question regarding kernel-devsrc | 10:24 |
| lukma | It looks like after the commit: 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f | 10:25 |
| lukma | It has been adjusted (and trimmed) to only allow building modules (i.e. *.[hc] files were omitted) | 10:25 |
| lukma | Is there any other recipe which brings the "old behaviour" ? | 10:25 |
| lukma | I mean - to install all sources, so I would be able to build the linux kernel on the target system? | 10:26 |
| lukma | Or such recipe is not present, so I would need to tweak its do_install() function and copy all missing *.[hc] files? | 10:26 |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 10:27 | |
| qschulz | zeddii: that's probably a question for you? ^ | 10:28 |
| lukma | qschulz: In the old days -> I've just added kernel-devsrc and have the kernel ready to be build on the target (test purposes) | 10:31 |
| RP | lukma: I think Bruce does have such a recipe in another layer somewhere | 10:35 |
| JaMa | RP: I've quick question about BB_HASH_CODEPARSER_VALS, I have a bbclass which basically does '${BPN}'.rsplit('-', 1) which is now failing because BPN is 'nopn' at parsing time, what would be a sollution for this? | 10:36 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Remote host closed the connection) | 10:37 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 10:37 | |
| tomzy_0 | morning | 10:37 |
| RP | JaMa: I had to put a "-" in PV due to icu for that reason :( | 10:38 |
| RP | JaMa: I'm not really sure. You could just clear BB_HASH_CODEPARSER_VALS I guess as a really quick fix | 10:39 |
| JaMa | ah in this one https://git.openembedded.org/openembedded-core/commit/?id=cebe8439cdc656d53355506a31a3782312bf03c5 ? didn't notice that it's related to CODEPARSER_VALS | 10:40 |
| RP | JaMa: that wasn't related but when I chose values for the new VALS, I had to pick one with a "-" in it | 10:40 |
| *** jclsn_ <jclsn_!~jclsn@2a04:4540:651f:6700:2ce:39ff:fecf:efcd> has quit IRC (Quit: WeeChat 3.7.1) | 10:41 | |
| JaMa | can I set BB_HASH_CODEPARSER_VALS in the bbclass? I guess it's too late, right? | 10:41 |
| RP | JaMa: we could put a - into PN in the default, it is just a bit ugly and who knows what else people will want | 10:41 |
| RP | JaMa: it isn't too late | 10:41 |
| JaMa | ok, will try that first, thanks | 10:41 |
| RP | JaMa: this is when you'll want to change the format so you can just change PN more easily | 10:41 |
| * RP is torn on making it crazy complex which is where this ends up heading :( | 10:42 | |
| RP | Clearing it just gets the original behaviour, not perfect for the cache but... | 10:42 |
| JaMa | I would need to read more about what exactly is in this cache, but if the bbclass is inheritted in relatively limited number of recipes (where we will run these functions anyway) would it cache results of all "useful" inputs (instead of caching just result of 'nopn-suffix')? | 10:45 |
| JaMa | BB_HASH_CODEPARSER_VALS:remove = "PN=nopn" seems to work, thanks | 10:49 |
| RP | JaMa: it just means it will parse a few more expression combinations that it would have otherwise needed to | 10:56 |
| RP | JaMa: for a few recipes it doesn't matter, the effect is significant over a few thousand recipes | 10:56 |
| JaMa | OK, but does it cache the results, like Memoize decorator (so caching relevant few combinations helps later)? | 11:02 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:10 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:10 | |
| ptsneves | RP: On the topic of BB_HASH_CODEPARSER_VALS i left a comment on https://lore.kernel.org/bitbake-devel/b3c51ad7-da76-db80-d2ed-a2fa2df60518@myneves.com/ | 11:17 |
| RP | ptsneves: I know, I was referring to it above. I understand the idea, I just didn't want to make the code too complicated. Adding a load of getVarFlag calls doesn't really help performance :/ | 11:18 |
| ptsneves | yeah it is a hot path :( i suggested it because i have been burned with white space issues in the past. In different places that are more user facing but nonetheless, i chimed in. | 11:20 |
| RP | ptsneves: it is a value concern, I'm just hoping we can choose our values here to avoid it | 11:21 |
| RP | a valid concern! | 11:21 |
| ptsneves | Anyway i see lots of work on bitbake innards. Thank you :) | 11:22 |
| RP | ptsneves: np, hopefully things will improve :) | 11:33 |
| *** seninha <seninha!~seninha@user/seninha> has joined #yocto | 11:34 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 11:40 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 11:40 | |
| *** manuel__ <manuel__!~manuel198@62.99.131.178> has joined #yocto | 11:51 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Ping timeout: 268 seconds) | 11:54 | |
| d-fens | whats the best way to allow a user to use sudo in yocto? | 11:55 |
| d-fens | went with a sudo_%.bbappend adding a file in /etc/sudoers.d | 12:01 |
| *** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has joined #yocto | 12:05 | |
| DvorkinDmitry | in my recipe 'm trying to install /etc/sudoers.d/myfile, but getting conflict with sudo package - it says /etc/sudoers.d dir is done by sudo recipe. How can I avoid this? | 12:06 |
| landgraf | DvorkinDmitry: does your package depends on sudo? | 12:08 |
| DvorkinDmitry | landgraf, yes, it does | 12:08 |
| landgraf | (rdepends) | 12:08 |
| DvorkinDmitry | yes | 12:08 |
| landgraf | DvorkinDmitry: then dir should be owned by sudo, not your package | 12:09 |
| DvorkinDmitry | landgraf, I need to install 1 file to this dir from my recipe... | 12:10 |
| *** zhmylove <zhmylove!~zhmylove@80.254.50.216> has joined #yocto | 12:10 | |
| DvorkinDmitry | landgraf, how can I do it correctly not conflicting with sudo? | 12:12 |
| rburton | i think you need to mark your file as a CONFFILE | 12:13 |
| landgraf | or install in sudo_%.bbappend instead | 12:13 |
| rburton | in your own package would be the right thing to do | 12:14 |
| rburton | guessing this is with rpm? | 12:14 |
| DvorkinDmitry | already did: CONFFILES:${PN} += "/etc/sudoers.d/myfile" | 12:14 |
| DvorkinDmitry | rburton, yes, rpm | 12:14 |
| rburton | dir ownership is an annoying rpm thing | 12:14 |
| DvorkinDmitry | rburton, I found DIRFILES = "1"... but my recipe contains a lot more files. Is it the only way around? | 12:15 |
| rburton | dirfiles is a list of paths | 12:16 |
| rburton | easy fix is don't use rpm :) | 12:16 |
| landgraf | rburton: well. that's not rpm but yocto. DvorkinDmitry's package should not own /etc/sudoers.d and sudo.bb should not own config from the DvorkinDmitry's package. | 12:17 |
| rburton | landgraf: sure but package_rpm says the package owns every directory that files are in. there's some big map somewhere to make it work for /usr/bin etc. | 12:18 |
| rburton | DvorkinDmitry: ah, check the perms on sudoers.d match? | 12:19 |
| DvorkinDmitry | rburton, good idea! they are not. Trying... | 12:20 |
| rburton | iirc, if they match rpm is happy | 12:21 |
| *** amitk__ <amitk__!~amit@103.208.71.17> has joined #yocto | 12:22 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4c03:f700:24d7:51ff:fed6:906d> has joined #yocto | 12:23 | |
| *** amitk_ <amitk_!~amit@103.59.74.183> has quit IRC (Ping timeout: 252 seconds) | 12:25 | |
| landgraf | rburton: Yes. I see the comment now. this should be fixed IMO... conf.d/ is popular way of config handling | 12:25 |
| rburton | landgraf: aye. i think its a perms thing. hopefully good news from DvorkinDmitry in a minute. | 12:26 |
| DvorkinDmitry | exactly. thanks! | 12:27 |
| ptsneves | is there any harm in having a duplicated value in DISTRO_FEATURES? | 12:28 |
| *** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 12:30 | |
| RP | ptsneves: not really | 12:34 |
| ptsneves | thanks :) | 12:37 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 12:41 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 12:42 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 12:51 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 13:01 | |
| paulg | it will just be twice as good! | 13:02 |
| *** odra <odra!~odra@2804:431:c7e1:3221:35b7:aa73:24da:4bc9> has quit IRC (Ping timeout: 264 seconds) | 13:06 | |
| *** amitk__ <amitk__!~amit@103.208.71.17> has quit IRC (Ping timeout: 252 seconds) | 13:12 | |
| *** dev1990 <dev1990!~dev@77-254-239-123.adsl.inetia.pl> has joined #yocto | 13:13 | |
| *** dev1990 <dev1990!~dev@77-254-239-123.adsl.inetia.pl> has quit IRC (Client Quit) | 13:13 | |
| rburton | RP: suseleap 15.4 doesn't need buildtools does it? | 13:19 |
| RP | rburton: https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json says yes | 13:26 |
| rburton | hm | 13:27 |
| rburton | i should remember to check that :) | 13:27 |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed) | 13:28 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 13:30 | |
| rburton | urllib.request should have a __main__ for easy testing | 13:30 |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 13:30 | |
| paulg | There are ubu 16.04 references in there - I thought that got dropped? | 13:30 |
| RP | paulg: it did, they don't hurt anything | 13:32 |
| paulg | fair point. | 13:32 |
| paulg | might even still build if you beat it with a stick for an hour.... | 13:34 |
| rburton | AHA i replicated it! | 13:39 |
| rburton | but that makes no sense why its only occasional | 13:42 |
| *** kalj <kalj!~kalj@78-71-20-170-no193.tbcn.telia.com> has joined #yocto | 13:42 | |
| *** olani <olani!~olani@wlan-gw.se.axis.com> has quit IRC (Ping timeout: 268 seconds) | 13:50 | |
| RP | rburton: what did you need to do to replicate? | 13:51 |
| RP | paulg: we use so little from the host I suspect it would still work | 13:51 |
| *** olani <olani!~olani@wlan-gw.se.axis.com> has joined #yocto | 13:52 | |
| rburton | RP: tried again with buildtools present. that was the first thing i tried first time but something must have been different. buildtools's python looks in the wrong place for the ssl certs as we purge SSL_CERT_FILE from the environment. | 13:52 |
| RP | rburton: ah. That would explain things :/ | 13:54 |
| RP | rburton: so it only fails if the cve checks run on a buildtools host? | 13:54 |
| rburton | i sure hope so :) | 13:54 |
| rburton | i'll double check that, but i can replicate using the buildtools i happened to have to hand | 13:55 |
| *** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has joined #yocto | 13:57 | |
| JaMa | sakoman: Hi, was the last kirkstone merge postponed? I've seen that kirkstone-nut was moved to kirkstone-next | 14:00 |
| sakoman | JaMa: I think RP just forgot to do the previous pull request, so I combined it with the most recent pull request | 14:01 |
| JaMa | ok, fair enough, I see another "cover letter only" from yesterday which combines both | 14:02 |
| JaMa | so I'll be just a bit more patient for ffmpeg fix :) | 14:02 |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 14:03 | |
| *** bunk <bunk!~bunk@debian/bunk> has joined #yocto | 14:03 | |
| ptsneves | https://lore.kernel.org/bitbake-devel/20221221233507.519249-1-richard.purdie@linuxfoundation.org/T/#t perhaps add to the commit message that the functions are disabled instead of removed because they are part of the public API? At least that is what i think is the reason they were not removed | 14:04 |
| sakoman | JaMa: usually I'll remind him if he doesn't take the request in a day or two, but this time I was buried in releases plus big patch sets on a couple of branches. So I forgot the reminder :-( | 14:04 |
| alessioigor | Hi all | 14:04 |
| alessioigor | Which recipe matches the (cross) compiler used in the SDK? I have to change the target triplet used... | 14:04 |
| JaMa | sakoman: understood and thank you | 14:05 |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 248 seconds) | 14:09 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 14:09 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 14:11 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 248 seconds) | 14:14 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 14:14 | |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed) | 14:18 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 264 seconds) | 14:20 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:23 | |
| JPEW | RP: I feel like I must be doing something wrong; I wrote a little bb file to run the same test cases as my override cache script, and the answers are wildly different :( | 14:25 |
| JPEW | RP: For example, when `OVERRIDES = "B"`, d.getVar("VAR") == "0", which makes no sense to me | 14:27 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 14:29 | |
| JPEW | Anyway, I pushed my test bb file to the branch; maybe I'm doing something silly there | 14:33 |
| JPEW | Of course! overrides have to be lower case (face palm) | 14:34 |
| *** kalj <kalj!~kalj@78-71-20-170-no193.tbcn.telia.com> has quit IRC (Quit: Client closed) | 14:37 | |
| RP | JPEW: I did have a look at your test case and it looked good. I was meaning to try and experiment with deeper levels of override | 14:43 |
| JPEW | Ya, I've found a weird case already :) | 14:43 |
| RP | JPEW: in yours or bitbake? :) | 14:43 |
| JPEW | bitbake | 14:43 |
| RP | JPEW: we do have bitbake-selftest bb.tests.data FWIW | 14:44 |
| JPEW | Ya | 14:44 |
| JPEW | with `OVERRIDES="b:a"`, `d.getVar("VAR") == 2`, when I would have expected it to be `5` | 14:45 |
| JPEW | The reasoning is that "a" is higher priority than "b", so VAR:a:b should be preferred over VAR:b:a, but this doesn't appear to be the case | 14:46 |
| RP | JPEW: I didn't check whether you had the priority application order right | 14:46 |
| JPEW | I do in general | 14:47 |
| JPEW | It handles single depth overrides correctly | 14:47 |
| RP | JPEW: I suspect that :b:a was defined to win against :a:b originally and I preserved that | 14:49 |
| RP | JPEW: you can definitely argue that should be the other way :/ | 14:51 |
| JPEW | Ya. The annoying part is that means you have to transverse all the branches of the tree because you can't possibly know which value is correct otherwise | 14:52 |
| JPEW | I don't think there is any magic data structure that can make that behavior efficient, but I'll keep looking :/ | 14:53 |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 264 seconds) | 14:54 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 14:55 | |
| RP | JPEW: this might be why the code is structured the way it is :/ | 14:58 |
| JPEW | Yep | 14:58 |
| RP | JPEW: Are there any tests which check that behaviour specifically ? | 14:58 |
| *** xeche_ <xeche_!~xeche@195-159-183-44.customer.powertech.no> has quit IRC (Quit: leaving) | 14:58 | |
| RP | I'm wondering how much real world use we have of this corner case | 14:58 |
| JPEW | Right, so I think the thing to do is to "pre-compute" all branches of the tree so that yo know what the minimum priority on each leg of the branch before transversing by taking the set intersection with set of overrides.... which is almost exactly what the current code does :) | 14:59 |
| JPEW | Let me see | 14:59 |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 14:59 | |
| JPEW | RP: Looks like there are _no_ tests of nested overrides | 15:00 |
| JPEW | There are priority tests, but none that go more than one level deep | 15:02 |
| RP | JPEW: excellent. So if we change it, nothing regresses :D | 15:04 |
| JPEW | The case where it would matter is if you are using the priority of the override to expect different behavior? Like... `VAR:machine:distro` needs to be different than `VAR:distro:machine`; this has to be really rare though, because in most cases `OVERRIDES` | 15:04 |
| JPEW | `OVERRIDES` is well ordered for us in most cases | 15:04 |
| JPEW | Have to think on it a little | 15:05 |
| JPEW | Right "the tests pass we are fine" :P | 15:05 |
| JPEW | "Ship It!" | 15:05 |
| RP | JPEW: I'm struggling to think of a case where you'd have both sets defined | 15:05 |
| JPEW | RP: Right most uses of overrides are for "switch" purposes (use this thing if the override is present) and the cases where the ordering of the overrides matter is rarer | 15:07 |
| JPEW | And even when the order matters, I think it would have to be pretty esoteric for this to matter | 15:07 |
| RP | JPEW: I agree. I think as long as we go in documenting we did this deliberately and make sure we add tests, we're ok | 15:08 |
| RP | (and assuming some build tests don't break) | 15:08 |
| JPEW | right | 15:08 |
| * JPEW checks the release schedule | 15:08 | |
| zeddii | apparently I'm too stupid do get it right, and i can't locate it in the manual. What's the incantation to add to a package's PACKAGECONFIG from local.conf ? my flailing at various _pn-<recipe name>:append combos isn't working. I just realized that all my appends haven't been working since the operator change to : from _ | 15:12 |
| JPEW | zeddii: PACKAGECONFIG:pn-<recipe name>:append ? | 15:12 |
| zeddii | yah. that should work, one would assume. but yet .. I must have something else wrong. i'm starting over, and dumping the env again. | 15:13 |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto | 15:13 | |
| * zeddii goes for coffee | 15:14 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has joined #yocto | 15:15 | |
| RP | bitbake should return -EGETCOFFEE | 15:18 |
| JPEW | Gnu Hurd has -EIEIO : "Computer has bought the farm" | 15:20 |
| JaMa | PACKAGECONFIG:append:pn-<recipe name> ? | 15:20 |
| *** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed) | 15:25 | |
| *** amitk_ <amitk_!~amit@103.208.69.103> has joined #yocto | 15:25 | |
| RP | JPEW: append at the end is clearly not right ;-) | 15:25 |
| JPEW | RP: mmm, right | 15:26 |
| *** bunk <bunk!~bunk@debian/bunk> has quit IRC (Quit: leaving) | 15:33 | |
| *** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 15:36 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 255 seconds) | 15:39 | |
| *** amitk_ <amitk_!~amit@103.208.69.103> has quit IRC (Ping timeout: 248 seconds) | 15:39 | |
| *** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has joined #yocto | 15:52 | |
| DvorkinDmitry | is it possible to enable service from another recipe? | 15:52 |
| manuel__ | DvorkinDmitry: Don't think so. You could do so from local.conf, as every copy starts from a copy of local.conf afaik. | 15:58 |
| *** zpfvo1 <zpfvo1!~fvo@i59F5CF5B.versanet.de> has quit IRC (Ping timeout: 256 seconds) | 16:04 | |
| *** manuel__ <manuel__!~manuel198@62.99.131.178> has quit IRC (Ping timeout: 268 seconds) | 16:05 | |
| *** zpfvo <zpfvo!~fvo@i59F5CF5B.versanet.de> has joined #yocto | 16:07 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 248 seconds) | 16:08 | |
| mckoan | DvorkinDmitry: what do you mean with "enable service"? | 16:19 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 16:19 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 16:20 | |
| *** yssh <yssh!~yssh@2401:4900:503b:8762:33d9:875c:a1ae:f4de> has joined #yocto | 16:21 | |
| *** florian <florian!~florian@dynamic-093-133-064-056.93.133.pool.telefonica.de> has joined #yocto | 16:22 | |
| *** zhmylove <zhmylove!~zhmylove@80.254.50.216> has quit IRC (Quit: Leaving) | 16:34 | |
| vmeson | days ago: <frieder> Is there a way to make devtool preserve the SRC_URI override? See: https://git.openembedded.org/openembedded-core/commit/?id=3a8654b860fa98f94e80c3c3fff359ffed14bbe7 | 16:34 |
| vmeson | frieder: does that work for you? | 16:35 |
| frieder | vmeson: I also found this and I have this patch in my tree, but unfortunately it doesn't seem to cover my case. | 16:39 |
| frieder | vmeson: I suspect that devtool simply doesn't handle these SRC_URI overrides correctly at the moment. | 16:40 |
| *** Jham <Jham!~Juba@2a01:e0a:177:a830:bd11:6f60:a3dd:e932> has quit IRC (Quit: Leaving) | 16:42 | |
| frieder | vmeson: devtool seems to use the final, parsed value of SRC_URI including the conditional appends and when updating the recipe it can't tell what original conditions need to be preserved | 16:43 |
| frieder | vmeson: At least that's what I seemed to understand from looking at the code for a while | 16:44 |
| rburton | zeddii: did i hear you say something about meta-virt and 6.1? | 16:58 |
| rburton | zeddii: would it be in relation to "Couldn't find anything to satisfy 'kernel-module-xen-blkback'." | 16:58 |
| zeddii | I have a patch on master-next to update the kernel config to match on 6.1. | 16:59 |
| zeddii | it would yes | 16:59 |
| rburton | great, thanks :) | 16:59 |
| zeddii | I'll push it today, once I'm done poking at perf. | 16:59 |
| rburton | +1 | 17:02 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 17:06 | |
| *** ptsneves <ptsneves!~Thunderbi@84.47.155.82> has quit IRC (Ping timeout: 252 seconds) | 17:12 | |
| *** frieder <frieder!~frieder@200116b8244fe4810000000000001cba.dip.versatel-1u1.de> has quit IRC (Remote host closed the connection) | 17:15 | |
| *** florian <florian!~florian@dynamic-093-133-064-056.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 17:21 | |
| zwelch | huh, trying to build my latest tegra image gives me a dependency loop between the initiramfs and kernel. Having a hard time chasing down the cause, so wondering if anyone else might have run into this recently. | 17:26 |
| *** mckoan is now known as mckoan|away | 17:30 | |
| RP | zeddii: that header difference is in kernel-devsrc, not perf :/ | 17:32 |
| RP | zeddii: whether that leads to the perf problem, I don't know | 17:33 |
| zeddii | RP: that's where my grep was from. build/work-shared/ .. kernel-source, that's where perf is grabbing it from. | 17:34 |
| zeddii | 'er wait. well, the source is there, but generated is from the artifacts. I need to check that | 17:35 |
| RP | zeddii: after you run "bitbake kernel-devsrc", the copy in work-shared is corrupted | 17:35 |
| zeddii | yah. | 17:35 |
| RP | zeddii: I'd guess the perf build might then corrupt if it runs after that | 17:35 |
| zeddii | I'm grepping the kernel build itself, and it has the consistent oe-host | 17:36 |
| RP | zeddii: tmp/work-shared/qemux86-64/kernel-build-artifacts/include/generated$ cat compile.h | grep HOST | 17:36 |
| RP | #define LINUX_COMPILE_HOST"jet" | 17:36 |
| RP | zeddii: it wasn't like that until I build kernel-devsrc | 17:36 |
| zeddii | devsrc isn't inheriting the class that sets it ? checking | 17:37 |
| zeddii | yah. I just see linux-kernel-base | 17:38 |
| RP | zeddii: looks likely! | 17:38 |
| *** zpfvo <zpfvo!~fvo@i59F5CF5B.versanet.de> has quit IRC (Quit: Leaving.) | 17:39 | |
| zeddii | there's a lot set in kernel.bbclass that the devsrc doesn't need. may be a better idea to just grab those values into the recipe. hmm. i can't even see why it is poking at the generated file, that's what would have newly arrived in 6.1 | 17:41 |
| RP | zeddii: maybe we just move the export to linux-kernel-base ? | 17:41 |
| JaMa | heh, if someone is wondering since when kernel recipes produce kernel-dev (or ${KERNEL_PACKAGE_NAME}-dev) then it was like that in the initial commit in 2005 while meta-meson in 2021 "fixed" it from '${PN}-dev += " /usr/include/linux-meson-4.9/* "' to 'FILES_${PN}-dev += " /usr/include/linux-meson/* "' and I thought that meta-qti is the worst BSP I had to deal with :) | 17:41 |
| zeddii | that'd work as well, kernel.bbclass iimports that. | 17:41 |
| RP | zeddii: which of us wants to write a patch to test? :) | 17:50 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.234> has quit IRC (Ping timeout: 252 seconds) | 17:51 | |
| zeddii | I was sitting here trying to figure out how kernel-devsrc is triggering that build, some sort of race with perf I guess. | 17:51 |
| RP | zeddii: it something tramples on the builddir, it will affect anything running after it | 17:51 |
| zeddii | yah. this should have always been a potential problem, as near as I can tell. since kernel-devsrc does depend on virtua/kernel:do_install and do_shared_workdir but that should be by the kernel provider, and that should have the value set. | 17:53 |
| zeddii | so your locale reproduce of the issue ? you just did a bitbake kernel-devsrc and looked in the kernel build artifacts ? | 17:53 |
| zeddii | I want to do the same, so maybe I can track down how this is now triggering in 6. | 17:54 |
| RP | zeddii: I ran "bitbake kernel-devsrc" and then looked at the shared workdir and saw compile.h had changed | 17:54 |
| zeddii | ack'd | 17:55 |
| zeddii | yup. I see my build host captured now. | 17:55 |
| zeddii | I'll try a patch, but I want to get it back to the generic "oe-host", and confirm how devsrc is touching that file (it shouldn't be building anything outside of the virtual/kernel provider .. which should have that variable set). | 17:56 |
| RP | zeddii: I'm going to try a quick hacked up patch on the autobuilder as I need to head afk for a few hours and we may as well see if this fixes perf too | 17:58 |
| zeddii | sounds good to me. I'll root cause it a bit more, that way we can explain why that fixes it. assuming it does :) | 17:59 |
| zeddii | just moving those few KBUILD values should be enough. | 17:59 |
| zeddii | based on the difference we are seeing. | 17:59 |
| RP | zeddii: https://git.yoctoproject.org/poky/commit/?h=master-next&id=8bac68bca18892d5e6ab43061c9256ec79f6ca57 | 17:59 |
| zeddii | ack'd, that's what I'd start with | 17:59 |
| RP | zeddii: I'll leave it with you, I'm out of time for a bit | 18:00 |
| *** yssh <yssh!~yssh@2401:4900:503b:8762:33d9:875c:a1ae:f4de> has quit IRC (Quit: Client closed) | 18:01 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.210> has joined #yocto | 18:04 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.112.210> has quit IRC (Ping timeout: 260 seconds) | 18:11 | |
| *** florian <florian!~florian@dynamic-093-133-064-056.93.133.pool.telefonica.de> has joined #yocto | 18:12 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.142> has joined #yocto | 18:12 | |
| abelloni | RP: sorry, I should have pointed out that kernel-devsrc was also there but I already sent the mail when I saw it | 18:17 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.142> has quit IRC (Ping timeout: 260 seconds) | 18:20 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.51> has joined #yocto | 18:21 | |
| khem | RP: thanks, I will try it locally on qemx86-64 right ? | 18:23 |
| *** florian <florian!~florian@dynamic-093-133-064-056.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 18:32 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 18:47 | |
| *** AntA <AntA!~anta@217.140.99.251> has joined #yocto | 18:47 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 18:47 | |
| *** nemik <nemik!~nemik@207.237.248.190> has quit IRC (Ping timeout: 248 seconds) | 18:49 | |
| *** nemik <nemik!~nemik@76.74.126.42> has joined #yocto | 18:49 | |
| *** nemik <nemik!~nemik@76.74.126.42> has quit IRC (Ping timeout: 252 seconds) | 18:53 | |
| *** nemik <nemik!~nemik@207.237.248.190> has joined #yocto | 18:54 | |
| *** florian <florian!~florian@dynamic-093-133-064-056.93.133.pool.telefonica.de> has joined #yocto | 19:10 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 19:30 | |
| *** Wouter01006704 <Wouter01006704!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 19:30 | |
| vmeson | frieder: it worked for me when refreshing the glibc/musl patches to https://github.com/OSSystems/meta-browser/commit/f2d5539552b54099893a7339cbb2ab46b42ee754 | 19:32 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.51> has quit IRC (Ping timeout: 248 seconds) | 19:34 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.12> has joined #yocto | 19:36 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.12> has quit IRC (Ping timeout: 252 seconds) | 19:43 | |
| paulg | RP, seeing as the topic is now somewhat recent, I'll throw in my $0.02 that I've been sitting on for months (years?) | 19:45 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.95> has joined #yocto | 19:45 | |
| paulg | I get why Upstream-status was introduced, but is this the kind of crap we want to encourage? | 19:45 |
| paulg | https://lists.openembedded.org/g/openembedded-core/message/176398 | 19:45 |
| paulg | everybody else moved their SCM tracking out of the source itself by 2008. | 19:46 |
| paulg | Just sayin. | 19:47 |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.114.95> has quit IRC (Ping timeout: 252 seconds) | 19:49 | |
| *** PhoenixMage <PhoenixMage!~phoenix@206.83.113.12> has joined #yocto | 19:51 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4c03:f700:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 19:57 | |
| rfs613 | paulg: only to then move their CI configuration scripts into the repo, causing endless "bump X to try fixing build" commits ;-) | 19:57 |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 19:58 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 19:58 | |
| paulg | build and config scripts are different. | 20:00 |
| paulg | I actually have to data mine into what changed the source and why on a regular basis. | 20:01 |
| rfs613 | i meant build scripts, CI pipeline, travisl.yaml and whatnot.... not autoconf and friends. | 20:01 |
| paulg | Anything that adds noise to that path is unwelcome. Not to mention the pointless churn for maintainers. | 20:01 |
| rfs613 | ah but how else can we gain "velocity" if we can't increase the number of commits through such tactics? :P | 20:02 |
| paulg | :-) If I ever use velocity in a context like that, someone please come take my keyboard. | 20:05 |
| *** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 20:08 | |
| paulg | Anyway - not to get distracted. I'm still convinced "Upstream-status" is one of those things where you find yourself saying "well, their heart was in the right place, but..." | 20:10 |
| rfs613 | I can't speak as any sort of maintainer... but I've found it occasionally useful, esp for "local" patches which won't go back upstream (ideally it should say why, if it's not obvious). | 20:13 |
| rfs613 | The otehr status all seem time-sensitive, eg. cannot trust them except at the moment of submission. | 20:14 |
| rfs613 | For backports, the link to upstream is nice, saves some searching, but again that's something that loses value over time (upstream moves URL, changes their site layout, etc) | 20:16 |
| RP | paulg: Upsteam-Status is extremely valuable as it records what the status of a patch is upstream. If I see an upgrade removing a Backport, I know it is likely safe. If I see it remove a pending or inappropriate, I know I need to ask other questions. | 20:17 |
| RP | paulg: the key difference is we're tracking foreign SCM interactions, not our own and we have many of them for OE-Core, over a thousand | 20:18 |
| paulg | I'm not questioning the value of data. Just how and where we store it. | 20:19 |
| RP | paulg: where else would we put it? Just the commit message? | 20:19 |
| paulg | Yes. | 20:19 |
| paulg | If you change patch foo, document the status of patch foo. Is that so unreasonable? | 20:20 |
| RP | paulg: in general we don't have status changes on patches on their own. I know there is one example above but they are comparatively rare | 20:21 |
| RP | For the amount of them we get I'm happy to have the status maintained and give people recognition if they do push patches upstream | 20:22 |
| RP | paulg: or are you meaning Upstream-Status shouldn't be in the patch? | 20:23 |
| paulg | yes -exactly. | 20:23 |
| RP | Taking something like gcc, it is very helpful to be able at a glance through the patches and know what is going on with them | 20:23 |
| DvorkinDmitry | mckoan, I mean I need some service to be enabled in another recipe. Say, I have webinterface and need php-fpm to be ON in my image. I want to enable php-fpm from mywebinterface recipe | 20:24 |
| RP | It also helps to be able to know which patches need attention and which ones don't without reviewing the commit logs for every patch | 20:24 |
| paulg | It also means people get nagged about one extra hurdle they need to add before being a contributor, so they walk away. | 20:25 |
| paulg | SCMs exist for a reason. Don't embed that in the source/patches. It will be stale, neglected and untrustworthy. | 20:27 |
| JaMa | zeddii: I've one more Upstream-Status fix for xen, should I keep it local or send it? I'm not going to send fixes for missing Upstream-Status, but I believe that if it's there then it should be in machine-recognized format to avoid more QA warnings | 20:27 |
| zeddii | JaMa: agreed on that. If we've made a badly formatted attempt at it, it is worth fixing. As a reader of the patch, I'm more forgiving on the format than the regex. | 20:29 |
| * JaMa really likes Upstream-Status in .patch files I wish more people would use it (and pity that patch-status-noncore didn't make it to default WARN_QA) - even adding Pending everywhere would be better than nothing, because at least new patches would force the developer to think about it | 20:35 | |
| DvorkinDmitry | is there are any example of the simple empty image creation with predefined size ? | 20:36 |
| JaMa | I've spent too much time already trying to figure out where our internal developers got some changes (sometimes to discover that it's bunch of squashed upstream commits without commit message or straight backport but with original commit message changed to something useless and with changed Author field to make finding upstream commit even more difficult | 20:36 |
| DvorkinDmitry | is it possible to create and format the empty (without content) partition with WIC? | 20:37 |
| JaMa | I would even send changes to add Pending where it's missing completely, but then I fear that next QA check would issue warning when Pending is used :) | 20:38 |
| JaMa | to make things worse we have many .patch files for our internal repos, just because the internal repos are managed by different teams and some teams aren't very responsive :( Like couple years in their gerrit queue where I ping it every year. | 20:41 |
| *** olani- <olani-!~olani@83-233-29-230.cust.bredband2.com> has joined #yocto | 20:44 | |
| RP | paulg: Sorry, I had to move to a location I could have this conversation properly. These things have a good reason but I clearly need to explain it | 20:46 |
| RP | paulg: Imagine a patch comes in upgrading recipe XYZ. From the patch on the mailing list, I can see the upgrade removes a patch in the XYZ recipe. If there is no info in the patch, I can't tell what that patch is doing, why we have it or what the removal might mean | 20:47 |
| RP | If I have the Upstream-Status and I can see it is a backport and the change is a version upgrade, chances are we're good and I can ignore that bit. If the patch says Inappropriate or Pending, I know I have to dig deeper, what is that patch doing, why were we carrying it, was there some reason we no longer need it | 20:48 |
| RP | paulg: If someone maintains a set of recipes, they can also tell from a straight forward grep which recipes have "issues" and patches needing attention. | 20:49 |
| RP | We have a ton of these patches and we don't really want to be carrying them, they're a maintenance headache. If the contributor can't put some text in place describing why we should have the patch, we can't be expected to carry and maintain it. | 20:50 |
| RP | paulg: we're not logging the history, we have git for that and I agree that is what we want the SCM for. We're keeping a track of the last known state, a summary if you will. | 20:51 |
| RP | paulg: I, and the other maintainers use them heavily and they are actually pretty decently maintained. | 20:52 |
| RP | paulg: I can even show metrics about the current state of patches and the changes in numbers and state of them over time: https://autobuilder.yocto.io/pub/non-release/patchmetrics/ | 20:52 |
| RP | https://autobuilder.yocto.io/pub/non-release/patchmetrics/index-full.html is perhaps a better more interesting over years view | 20:53 |
| RP | JaMa: we're a long way off making Pending a warning | 20:54 |
| RP | JaMa: 279 in core alone | 20:54 |
| *** rob_w <rob_w!~rob@2001:a61:60dc:3e01:9d52:da62:96ab:8525> has quit IRC (Quit: Leaving) | 20:54 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-4-112.hawaiiantel.net> has joined #yocto | 21:13 | |
| JPEW | RP: I got the log configuration to write warnings to a file, what was I supposed to do with it besides close the ticket? | 21:13 |
| RP | JPEW: share on the mailing list please? | 21:17 |
| JPEW | OK | 21:18 |
| RP | JPEW: much appreciated, thanks! | 21:18 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 21:23 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 21:26 | |
| RP | JaMa: I know you have used qa.log a lot. I'm wondering if we can drop that if we have documented config to make bitbake save all warnings to a logfile? | 21:26 |
| JaMa | RP: yeah, but if I add 500 Pending in other layers as well (as I did with a script in meta-ros), then Pending becames even less useful and unwanted | 21:32 |
| JaMa | RP: I've seen that in bugzilla and I guess I agree | 21:33 |
| *** azcraft <azcraft!~AzCraft@195.214.252.104> has joined #yocto | 21:35 | |
| JaMa | qa.log is very usefull at times (e.g. now I wanted to quickly find all patch-status-noncore across various builds I had locally) and this was fastest way to find them *after* the builds were already finished, but it's far from perfect as it is incomplete anyway, so I wouldn't mind replacing it with better logger config | 21:36 |
| RP | JaMa: right, I think as hard as we try that solution won't every be "perfect" so I'd rather use the logging differently since we now have much better control there | 21:36 |
| JaMa | pity that not all QA warnings could reasonably be on just 1 line | 21:37 |
| RP | JaMa: with the logfile approach you would still capture them | 21:38 |
| JaMa | e.g. in jenkins builds I'm showing some stats like number of errors and warning in the qa.log and then the actuall warnings and errors in separate sections, but e.g. patch-status-noncore or patch-fuzz contain a lot of extra information which isn't so useful in that context | 21:39 |
| RP | JaMa: the project autobuilder has the same issue | 21:40 |
| JaMa | e.g. linux-meson had 948 files listed in installed-vs-shipped :) | 21:41 |
| JaMa | and buildpaths TMPDIR references often also cover a lot of files, but on the other hand these are low-hanging fruits to kill half of qa.log with just oneline fix :) | 21:42 |
| RP | JaMa: pros and cons I guess :) | 21:42 |
| RP | zeddii: FWIW that hacked up patch did fix reproducibility | 21:43 |
| JaMa | yeah, I see there is an example from JPEW on ML already, will give it a try | 21:46 |
| zeddii | RP: it was definitely a race. | 21:50 |
| zeddii | I had my build host captured, cleaned, rebuild both the kernel, and then devsrc, and it didn't break. | 21:52 |
| RP | zeddii: must be something about the build from scratch | 21:52 |
| JaMa | btw anywone seeing WARNING: oe-core/meta/recipes-kernel/linux/linux-yocto-dev.bb: Duplicate inclusion for meta-virtualization/recipes-kernel/linux/linux-yocto_virtualization.inc in meta-virtualization/recipes-kernel/linux/linux-yocto-dev.bbappend ? | 21:53 |
| JaMa | I think it started today in rpi builds, but looking at the changes I haven't noticed what would cause it, but I haven't investigated much as builds are still ongoing | 21:54 |
| zeddii | RP: yah, I now can't ever get the build host to show up, but what you did would fix any race that was somehow triggered by devsrc. so as far as I'm concerned that's the right thing. | 21:59 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 22:01 | |
| zeddii | JaMa: I just pushed the 6.1* kernel configuration .inc file to meta-virt today. Both the linux-yocto-dev and linux-yocto are 6.1 right now, but. I didn't think it would trigger that. | 22:03 |
| RP | zeddii: do you want to send a patch with a proper commit message? or do you want me to make up something? | 22:04 |
| RP | zeddii: we could defer 6.1 until after M2 if you want to dig into it more too | 22:04 |
| zeddii | I'd rather it make it in, but since i don't have a root cause, I'd just say "these should be defined for anything that might trigger the kernel to generate files, so we move it to the lowest bbclass" | 22:05 |
| zeddii | since I still can't say exactly HOW that is triggering. | 22:05 |
| RP | zeddii: fair enough. I tend to agree we should just fix this. The sad thing is we could have probably removed that class and migrated that code to lib/oe without the exports! | 22:06 |
| zeddii | ahah. true. I will keep my build cycling here tonight, to see if I can cause it. | 22:06 |
| RP | zeddii: I've sent the patch. If it looks ok to you I'll merge 6.1 and then get on with M2 | 22:10 |
| zeddii | I'll go look and follow up. | 22:10 |
| RP | paulg: I suppose I should throw these ppc64 patches in too... | 22:11 |
| paulg | RP, I won't pressure you one way or the other. I already feel bad for sandbagging you out of left field with my hate for Upstream-status. Do what you think is right. | 22:15 |
| *** ldericher <ldericher!~LDer@user/ldericher> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 22:17 | |
| *** Piraty <Piraty!~irc@user/piraty> has quit IRC (Remote host closed the connection) | 22:17 | |
| RP | paulg: I didn't say where I was throwing them into :D | 22:18 |
| *** ldericher <ldericher!~LDer@user/ldericher> has joined #yocto | 22:19 | |
| *** Piraty <Piraty!~irc@user/piraty> has joined #yocto | 22:19 | |
| *** Piraty <Piraty!~irc@user/piraty> has quit IRC (Client Quit) | 22:21 | |
| *** azcraft <azcraft!~AzCraft@195.214.252.104> has quit IRC (Remote host closed the connection) | 22:21 | |
| paulg | ah right. Dumpster fire. Clay brick oven, ... | 22:23 |
| *** Piraty <Piraty!~irc@user/piraty> has joined #yocto | 22:23 | |
| JaMa | :) | 22:24 |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-26-174-95-44-180.dsl.bell.ca> has quit IRC (Ping timeout: 248 seconds) | 22:25 | |
| *** DvorkinDmitry <DvorkinDmitry!~dvorkin@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 22:25 | |
| RP | rburton: you know that test commit you pushed a while back with build-appliance? It was wrong :( | 22:27 |
| * RP really wanted to debug combo-layer to finish off the day | 22:29 | |
| * RP tries an rc2 build for M2 | 22:51 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 23:15 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 23:18 | |
| *** invalidopcode1 <invalidopcode1!~invalidop@cpe-172-90-200-106.socal.res.rr.com> has joined #yocto | 23:18 | |
| JaMa | zeddii: I think the Duplicate inclusion is triggered because linux-yocto-dev with 6.1 version now triggers both of these: | 23:30 |
| JaMa | recipes-kernel/linux/linux-%.bbappend:include ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'linux-${KERNEL_META_TYPE}_${LINUX_MAJOR}.${LINUX_MINOR}_virtualization.inc', '', d)} | 23:30 |
| JaMa | recipes-kernel/linux/linux-yocto-dev.bbappend:require ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'linux-yocto_virtualization.inc', '', d)} | 23:30 |
| *** amitk_ <amitk_!~amit@103.208.69.103> has joined #yocto | 23:32 | |
| JaMa | zeddii: does it need to be version specific with ${LINUX_MAJOR}.${LINUX_MINOR}? now they are identical for 5.15 and 6.1 but maybe you expect them to differ again (or people providing own version specific .inc file)? | 23:33 |
| JaMa | zeddii: my WIP fix https://github.com/shr-project/meta-virtualization/commit/9817669a7924b33ebcfab167179a9123e8409911 | 23:41 |
| *** amitk_ <amitk_!~amit@103.208.69.103> has quit IRC (Ping timeout: 255 seconds) | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!