Thursday, 2023-01-26

*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)00:17
*** kscherer <kscherer!> has quit IRC (Quit: Konversation terminated!)00:28
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:29
*** florian <florian!> 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!> has joined #yocto00:59
*** invalidopcode1 <invalidopcode1!> has quit IRC (Remote host closed the connection)01:03
*** invalidopcode1 <invalidopcode1!> has joined #yocto01:03
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)01:10
*** seninha <seninha!~seninha@user/seninha> has joined #yocto01:19
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)01:39
*** nemik <nemik!~nemik@> has joined #yocto01:39
*** Wouter01006704 <Wouter01006704!> has quit IRC (Quit: The Lounge -
*** Wouter01006704 <Wouter01006704!> has joined #yocto01:40
*** xmn <xmn!> has joined #yocto01:43
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)01:43
*** nemik <nemik!~nemik@> has joined #yocto01:44
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 268 seconds)01:59
*** mckoan|away <mckoan|away!> has joined #yocto02:00
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 248 seconds)02:03
*** davidinux <davidinux!~davidinux@> has joined #yocto02:05
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has quit IRC (Ping timeout: 255 seconds)02:09
*** invalidopcode1 <invalidopcode1!> has quit IRC (Remote host closed the connection)02:13
*** invalidopcode1 <invalidopcode1!> has joined #yocto02:13
*** Bardon <Bardon!~Bardon@user/Bardon> has joined #yocto02: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 #yocto03: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 #yocto04:04
*** amitk <amitk!~amit@> has joined #yocto05:09
*** davidinux <davidinux!~davidinux@> has quit IRC (Quit: WeeChat 3.5)05:48
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:10
*** davidinux <davidinux!~davidinux@> has joined #yocto06:22
*** olani- <olani-!~olani@> has quit IRC (Ping timeout: 252 seconds)06:26
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:34
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:35
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto07:11
*** rob_w <rob_w!~rob@2001:a61:60dc:3e01:9d52:da62:96ab:8525> has joined #yocto07:13
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 248 seconds)07:13
*** davidinux <davidinux!~davidinux@> has joined #yocto07:15
*** wooosaiiii <wooosaiiii!> has joined #yocto07:27
*** frieder <frieder!> has joined #yocto07:45
*** mckoan|away is now known as mckoan07:46
LetoThe2ndyo dudX07:52
mckoanhi LetoThe2nd07:55
*** zpfvo <zpfvo!> has joined #yocto08:06
*** zpfvo1 <zpfvo1!> has joined #yocto08:11
*** Jham <Jham!~Juba@2a01:e0a:177:a830:bd11:6f60:a3dd:e932> has joined #yocto08:12
*** zpfvo <zpfvo!> 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 <>)08:20
LetoThe2ndKareemZarka[m]: can you maybe give a one-sentence summary? we only got a link.08:22
landgrafKareemZarka[m]: most of the people in the channel are on IRC not Matrix08:23
landgrafKareemZarka[m]: So use one string messages and pastebin to paste logs etc08:23
LetoThe2ndlandgraf: weren't you working on quite some autobuilder stuff lately?08:24
landgrafLetoThe2nd: No. I've not touched autobilder at all08:26
LetoThe2ndlandgraf: then I'm confusing you with somebody else, sorry.08:26
landgrafLetoThe2nd: No problem. I'm used to it :D08: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 partition08:29
KareemZarka[m]KareemZarka[m]: maybe a patch ?08:29
*** gsalazar <gsalazar!> has joined #yocto08:30
landgrafLetoThe2nd: 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 :D08:30
landgrafKareemZarka[m]: make in cofigurable (not just comment out) and submit a patch08:31
LetoThe2ndlandgraf: in for some fun!08:31
landgrafif it's not already done08:31
KareemZarka[m]landgraf: can you elaborate on what you mean by 'make in configurable`?08:32
landgrafKareemZarka[m]: if bb.getVar("MY_FEATURE_FLAG"):08:34
friederHi, I'm using devtool upgrade && devtool finish on a recipe with git source.08:38
friederThe SRCREV is updated just fine, but devtool always rewrites my conditional SRC_URI override08:38
friederSo SRC_URI:append:test = "file://example.conf" is turned into SRC_URI += "file://example.conf"08:38
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:39
friederIs 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
landgrafKareemZarka[m]: yes, don't break existing flow unless it's broken or unexpected already08:43
KareemZarka[m]landgraf: right thanks , I appreciate it08:43
*** prabhakarlad <prabhakarlad!> has joined #yocto08:45
landgrafKareemZarka[m]: np08:46
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving)09:00
*** amitk_ <amitk_!~amit@> has joined #yocto09:10
*** florian <florian!> has joined #yocto09:16
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)09:18
d-fenshow 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 users09:18
*** davidinux <davidinux!~davidinux@> has joined #yocto09:19
d-fenshmm pkg_postinst_${PN}{ looks promising09:21
*** xmn <xmn!> has quit IRC (Ping timeout: 248 seconds)09:33
*** xmn <xmn!> has joined #yocto09:35
*** zwelch <zwelch!> has quit IRC (Ping timeout: 252 seconds)09:36
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto09:39
*** manuel__ <manuel__!~manuel198@> has quit IRC (Ping timeout: 252 seconds)09:41
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)09:46
*** zwelch <zwelch!> has joined #yocto09:49
*** ptsneves <ptsneves!~Thunderbi@> has joined #yocto09:58
*** florian_kc <florian_kc!> has joined #yocto10:12
*** lukma <lukma!> has joined #yocto10:24
lukmaDear all, I do have a question regarding kernel-devsrc10:24
lukmaIt looks like after the commit: 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f10:25
lukmaIt has been adjusted (and trimmed) to only allow building modules (i.e. *.[hc] files were omitted)10:25
lukmaIs there any other recipe which brings the "old behaviour" ?10:25
lukmaI mean - to install all sources, so I would be able to build the linux kernel on the target system?10:26
lukmaOr 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!> has joined #yocto10:27
qschulzzeddii: that's probably a question for you? ^10:28
lukmaqschulz: 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
RPlukma: I think Bruce does have such a recipe in another layer somewhere10:35
JaMaRP: 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@> has quit IRC (Remote host closed the connection)10:37
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto10:37
RPJaMa: I had to put a "-" in PV due to icu for that reason :(10:38
RPJaMa: I'm not really sure. You could just clear  BB_HASH_CODEPARSER_VALS I guess as a really quick fix10:39
JaMaah in this one ? didn't notice that it's related to CODEPARSER_VALS10:40
RPJaMa: that wasn't related but when I chose values for the new VALS, I had to pick one with a "-" in it10:40
*** jclsn_ <jclsn_!~jclsn@2a04:4540:651f:6700:2ce:39ff:fecf:efcd> has quit IRC (Quit: WeeChat 3.7.1)10:41
JaMacan I set BB_HASH_CODEPARSER_VALS in the bbclass? I guess it's too late, right?10:41
RPJaMa: we could put a - into PN in the default, it is just a bit ugly and who knows what else people will want10:41
RPJaMa: it isn't too late10:41
JaMaok, will try that first, thanks10:41
RPJaMa: this is when you'll want to change the format so you can just change PN more easily10:41
* RP is torn on making it crazy complex which is where this ends up heading :(10:42
RPClearing it just gets the original behaviour, not perfect for the cache but...10:42
JaMaI 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
JaMaBB_HASH_CODEPARSER_VALS:remove = "PN=nopn" seems to work, thanks10:49
RPJaMa: it just means it will parse a few more expression combinations that it would have otherwise needed to10:56
RPJaMa: for a few recipes it doesn't matter, the effect is significant over a few thousand recipes10:56
JaMaOK, but does it cache the results, like Memoize decorator (so caching relevant few combinations helps later)?11:02
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)11:10
*** alessioigor <alessioigor!~alessioig@> has joined #yocto11:10
ptsnevesRP: On the topic of BB_HASH_CODEPARSER_VALS i left a comment on
RPptsneves: 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
ptsnevesyeah 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
RPptsneves:  it is a value concern, I'm just hoping we can choose our values here to avoid it11:21
RPa valid concern!11:21
ptsnevesAnyway i see lots of work on bitbake innards. Thank you :)11:22
RPptsneves: np, hopefully things will improve :)11:33
*** seninha <seninha!~seninha@user/seninha> has joined #yocto11:34
*** Wouter01006704 <Wouter01006704!> has quit IRC (Quit: The Lounge -
*** Wouter01006704 <Wouter01006704!> has joined #yocto11:40
*** manuel__ <manuel__!~manuel198@> has joined #yocto11:51
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Ping timeout: 268 seconds)11:54
d-fenswhats the best way to allow  a user to use sudo in yocto?11:55
d-fenswent with a sudo_%.bbappend adding a file in /etc/sudoers.d12:01
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@> has joined #yocto12:05
DvorkinDmitryin 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
landgrafDvorkinDmitry: does your package depends on sudo?12:08
DvorkinDmitrylandgraf, yes, it does12:08
landgrafDvorkinDmitry: then dir should be owned by sudo, not your package12:09
DvorkinDmitrylandgraf, I need to install 1 file to this dir from my recipe...12:10
*** zhmylove <zhmylove!~zhmylove@> has joined #yocto12:10
DvorkinDmitrylandgraf, how can I do it correctly not conflicting with sudo?12:12
rburtoni think you need to mark your file as a CONFFILE12:13
landgrafor install in sudo_%.bbappend instead12:13
rburtonin your own package would be the right thing to do12:14
rburtonguessing this is with rpm?12:14
DvorkinDmitryalready did: CONFFILES:${PN} += "/etc/sudoers.d/myfile"12:14
DvorkinDmitryrburton, yes, rpm12:14
rburtondir ownership is an annoying rpm thing12:14
DvorkinDmitryrburton, I found DIRFILES = "1"... but my recipe contains a lot more files. Is it the only way around?12:15
rburtondirfiles is a list of paths12:16
rburtoneasy fix is don't use rpm :)12:16
landgrafrburton: well. that's not rpm but yocto. DvorkinDmitry's package should not own /etc/sudoers.d and should not own config from the DvorkinDmitry's package.12:17
rburtonlandgraf: 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
rburtonDvorkinDmitry: ah, check the perms on sudoers.d match?12:19
DvorkinDmitryrburton, good idea! they are not. Trying...12:20
rburtoniirc, if they match rpm is happy12:21
*** amitk__ <amitk__!~amit@> has joined #yocto12:22
*** mvlad <mvlad!~mvlad@2a02:2f08:4c03:f700:24d7:51ff:fed6:906d> has joined #yocto12:23
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 252 seconds)12:25
landgrafrburton: Yes. I see the comment now. this should be fixed IMO... conf.d/ is popular way of config handling12:25
rburtonlandgraf: aye.  i think its a perms thing.  hopefully good news from DvorkinDmitry in a minute.12:26
DvorkinDmitryexactly. thanks!12:27
ptsnevesis there any harm in having a duplicated value in DISTRO_FEATURES?12:28
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@> has quit IRC (Quit: KVIrc 5.0.0 Aria
RPptsneves: not really12:34
ptsnevesthanks :)12:37
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)12:41
*** prabhakarlad <prabhakarlad!> has joined #yocto12:42
*** goliath <goliath!~goliath@user/goliath> has joined #yocto12:51
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)13:01
paulgit 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@> has quit IRC (Ping timeout: 252 seconds)13:12
*** dev1990 <dev1990!> has joined #yocto13:13
*** dev1990 <dev1990!> has quit IRC (Client Quit)13:13
rburtonRP: suseleap 15.4 doesn't need buildtools does it?13:19
RPrburton: says yes13:26
rburtoni should remember to check that :)13:27
*** tomzy_0 <tomzy_0!> has quit IRC (Quit: Client closed)13:28
*** Wouter01006704 <Wouter01006704!> has quit IRC (Quit: The Lounge -
rburtonurllib.request should have a __main__ for easy testing13:30
*** Wouter01006704 <Wouter01006704!> has joined #yocto13:30
paulgThere are ubu 16.04 references in there - I thought that got dropped?13:30
RPpaulg: it did, they don't hurt anything13:32
paulgfair point.13:32
paulgmight even still build if you beat it with a stick for an hour....13:34
rburtonAHA i replicated it!13:39
rburtonbut that makes no sense why its only occasional13:42
*** kalj <kalj!> has joined #yocto13:42
*** olani <olani!> has quit IRC (Ping timeout: 268 seconds)13:50
RPrburton: what did you need to do to replicate?13:51
RPpaulg: we use so little from the host I suspect it would still work13:51
*** olani <olani!> has joined #yocto13:52
rburtonRP: 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
RPrburton: ah. That would explain things :/13:54
RPrburton: so it only fails if the cve checks run on a buildtools host?13:54
rburtoni sure hope so :)13:54
rburtoni'll double check that, but i can replicate using the buildtools i happened to have to hand13:55
*** sakoman <sakoman!> has joined #yocto13:57
JaMasakoman: Hi, was the last kirkstone merge postponed? I've seen that kirkstone-nut was moved to kirkstone-next14:00
sakomanJaMa: I think RP just forgot to do the previous pull request, so I combined it with the most recent pull request14:01
JaMaok, fair enough, I see another "cover letter only" from yesterday which combines both14:02
JaMaso I'll be just a bit more patient for ffmpeg fix :)14:02
*** tomzy_0 <tomzy_0!> has joined #yocto14:03
*** bunk <bunk!~bunk@debian/bunk> has joined #yocto14:03
ptsneves 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 removed14:04
sakomanJaMa: 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
alessioigorHi all14:04
alessioigorWhich recipe matches the (cross) compiler used in the SDK? I have to change the target triplet used...14:04
JaMasakoman: understood and thank you14:05
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)14:09
*** nemik <nemik!~nemik@> has joined #yocto14:09
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)14:11
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)14:14
*** nemik <nemik!~nemik@> has joined #yocto14:14
*** tomzy_0 <tomzy_0!> has quit IRC (Quit: Client closed)14:18
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 264 seconds)14:20
*** xmn <xmn!> has joined #yocto14:23
JPEWRP: 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
JPEWRP: For example, when `OVERRIDES = "B"`, d.getVar("VAR") == "0", which makes no sense to me14:27
*** florian <florian!> has quit IRC (Quit: Ex-Chat)14:29
JPEWAnyway, I pushed my test bb file to the branch; maybe I'm doing something silly there14:33
JPEWOf course! overrides have to be lower case (face palm)14:34
*** kalj <kalj!> has quit IRC (Quit: Client closed)14:37
RPJPEW: I did have a look at your test case and it looked good. I was meaning to try and experiment with deeper levels of override14:43
JPEWYa, I've found a weird case already :)14:43
RPJPEW: in yours or bitbake? :)14:43
RPJPEW: we do have bitbake-selftest FWIW14:44
JPEWwith `OVERRIDES="b:a"`, `d.getVar("VAR") == 2`, when I would have expected it to be `5`14:45
JPEWThe 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 case14:46
RPJPEW: I didn't check whether you had the priority application order right14:46
JPEWI do in general14:47
JPEWIt handles single depth overrides correctly14:47
RPJPEW: I suspect that :b:a was defined to win against :a:b originally and I preserved that14:49
RPJPEW: you can definitely argue that should be the other way :/14:51
JPEWYa. 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 otherwise14:52
JPEWI 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@> has quit IRC (Ping timeout: 264 seconds)14:54
*** prabhakarlad <prabhakarlad!> has joined #yocto14:55
RPJPEW: this might be why the code is structured the way it is :/14:58
RPJPEW: Are there any tests which check that behaviour specifically ?14:58
*** xeche_ <xeche_!> has quit IRC (Quit: leaving)14:58
RPI'm wondering how much real world use we have of this corner case14:58
JPEWRight, 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
JPEWLet me see14:59
*** nemik <nemik!~nemik@> has joined #yocto14:59
JPEWRP: Looks like there are _no_ tests of nested overrides15:00
JPEWThere are priority tests, but none that go more than one level deep15:02
RPJPEW: excellent. So if we change it, nothing regresses :D15:04
JPEWThe 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 cases15:04
JPEWHave to think on it a little15:05
JPEWRight "the tests pass we are fine" :P15:05
JPEW"Ship It!"15:05
RPJPEW: I'm struggling to think of a case where you'd have both sets defined15:05
JPEWRP: 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 rarer15:07
JPEWAnd even when the order matters, I think it would have to be pretty esoteric for this to matter15:07
RPJPEW: I agree. I think as long as we go in documenting we did this deliberately and make sure we add tests, we're ok15:08
RP(and assuming some build tests don't break)15:08
* JPEW checks the release schedule15:08
zeddiiapparently 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
JPEWzeddii: PACKAGECONFIG:pn-<recipe name>:append ?15:12
zeddiiyah. 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!> has joined #yocto15:13
* zeddii goes for coffee15:14
*** kscherer <kscherer!> has joined #yocto15:15
RPbitbake should return -EGETCOFFEE15:18
JPEWGnu Hurd has -EIEIO : "Computer has bought the farm"15:20
JaMaPACKAGECONFIG:append:pn-<recipe name> ?15:20
*** tomzy_0 <tomzy_0!> has quit IRC (Quit: Client closed)15:25
*** amitk_ <amitk_!~amit@> has joined #yocto15:25
RPJPEW: append at the end is clearly not right ;-)15:25
JPEWRP: mmm, right15:26
*** bunk <bunk!~bunk@debian/bunk> has quit IRC (Quit: leaving)15:33
*** GNUmoon2 <GNUmoon2!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto15:36
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 255 seconds)15:39
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 248 seconds)15:39
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@> has joined #yocto15:52
DvorkinDmitryis 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!> has quit IRC (Ping timeout: 256 seconds)16:04
*** manuel__ <manuel__!~manuel198@> has quit IRC (Ping timeout: 268 seconds)16:05
*** zpfvo <zpfvo!> has joined #yocto16:07
*** xmn <xmn!> has quit IRC (Ping timeout: 248 seconds)16:08
mckoanDvorkinDmitry: what do you mean with "enable service"?16:19
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:19
*** xmn <xmn!> has joined #yocto16:20
*** yssh <yssh!~yssh@2401:4900:503b:8762:33d9:875c:a1ae:f4de> has joined #yocto16:21
*** florian <florian!> has joined #yocto16:22
*** zhmylove <zhmylove!~zhmylove@> has quit IRC (Quit: Leaving)16:34
vmesondays ago:  <frieder> Is there a way to make devtool preserve the SRC_URI override?  See:
vmesonfrieder: does that work for you?16:35
friedervmeson: I also found this and I have this patch in my tree, but unfortunately it doesn't seem to cover my case.16:39
friedervmeson: 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
friedervmeson: 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 preserved16:43
friedervmeson: At least that's what I seemed to understand from looking at the code for a while16:44
rburtonzeddii: did i hear you say something about meta-virt and 6.1?16:58
rburtonzeddii: would it be in relation to "Couldn't find anything to satisfy 'kernel-module-xen-blkback'."16:58
zeddiiI have a patch on master-next to update the kernel config to match on 6.1.16:59
zeddiiit would yes16:59
rburtongreat, thanks :)16:59
zeddiiI'll push it today, once I'm done poking at perf.16:59
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)17:06
*** ptsneves <ptsneves!~Thunderbi@> has quit IRC (Ping timeout: 252 seconds)17:12
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:15
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)17:21
zwelchhuh, 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|away17:30
RPzeddii: that header difference is in kernel-devsrc, not perf :/17:32
RPzeddii: whether that leads to the perf problem, I don't know17:33
zeddiiRP: 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 that17:35
RPzeddii: after you run "bitbake kernel-devsrc", the copy in work-shared is corrupted17:35
RPzeddii: I'd guess the perf build might then corrupt if it runs after that17:35
zeddiiI'm grepping the kernel build itself, and it has the consistent oe-host17:36
RPzeddii: tmp/work-shared/qemux86-64/kernel-build-artifacts/include/generated$ cat compile.h | grep HOST17:36
RP#define LINUX_COMPILE_HOST"jet"17:36
RPzeddii: it wasn't like that until I build kernel-devsrc17:36
zeddiidevsrc isn't inheriting the class that sets it ? checking17:37
zeddiiyah. I just see linux-kernel-base17:38
RPzeddii: looks likely!17:38
*** zpfvo <zpfvo!> has quit IRC (Quit: Leaving.)17:39
zeddiithere'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.117:41
RPzeddii: maybe we just move the export to linux-kernel-base ?17:41
JaMaheh, 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
zeddiithat'd work as well, kernel.bbclass iimports that.17:41
RPzeddii: which of us wants to write a patch to test? :)17:50
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 252 seconds)17:51
zeddiiI was sitting here trying to figure out how kernel-devsrc is triggering that build, some sort of race with perf I guess.17:51
RPzeddii: it something tramples on the builddir, it will affect anything running after it17:51
zeddiiyah. 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
zeddiiso your locale reproduce of the issue ? you just did a bitbake kernel-devsrc and looked in the kernel build artifacts ?17:53
zeddiiI want to do the same, so maybe I can track down how this is now triggering in 6.17:54
RPzeddii: I ran "bitbake kernel-devsrc" and then looked at the shared workdir and saw compile.h had changed17:54
zeddiiyup. I see my build host captured now.17:55
zeddiiI'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
RPzeddii: 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 too17:58
zeddiisounds 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
zeddiijust moving those few KBUILD values should be enough.17:59
zeddiibased on the difference we are seeing.17:59
zeddiiack'd, that's what I'd start with17:59
RPzeddii: I'll leave it with you, I'm out of time for a bit18:00
*** yssh <yssh!~yssh@2401:4900:503b:8762:33d9:875c:a1ae:f4de> has quit IRC (Quit: Client closed)18:01
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18:04
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 260 seconds)18:11
*** florian <florian!> has joined #yocto18:12
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18:12
abelloniRP: sorry, I should have pointed out that kernel-devsrc was also there but I already sent the mail when I saw it18:17
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 260 seconds)18:20
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto18:21
khemRP: thanks, I will try it locally on qemx86-64 right ?18:23
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)18:32
*** invalidopcode1 <invalidopcode1!> has quit IRC (Remote host closed the connection)18:47
*** AntA <AntA!~anta@> has joined #yocto18:47
*** invalidopcode1 <invalidopcode1!> has joined #yocto18:47
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)18:49
*** nemik <nemik!~nemik@> has joined #yocto18:49
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 252 seconds)18:53
*** nemik <nemik!~nemik@> has joined #yocto18:54
*** florian <florian!> has joined #yocto19:10
*** Wouter01006704 <Wouter01006704!> has quit IRC (Quit: The Lounge -
*** Wouter01006704 <Wouter01006704!> has joined #yocto19:30
vmesonfrieder: it worked for me when refreshing the glibc/musl patches to
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 248 seconds)19:34
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto19:36
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 252 seconds)19:43
paulgRP, 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@> has joined #yocto19:45
paulgI get why Upstream-status was introduced, but is this the kind of crap we want to encourage?19:45
paulgeverybody else moved their SCM tracking out of the source itself by 2008.19:46
paulgJust sayin.19:47
*** PhoenixMage <PhoenixMage!~phoenix@> has quit IRC (Ping timeout: 252 seconds)19:49
*** PhoenixMage <PhoenixMage!~phoenix@> has joined #yocto19:51
*** mvlad <mvlad!~mvlad@2a02:2f08:4c03:f700:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)19:57
rfs613paulg: only to then move their CI configuration scripts into the repo, causing endless "bump X to try fixing build" commits ;-)19:57
*** invalidopcode1 <invalidopcode1!> has quit IRC (Remote host closed the connection)19:58
*** invalidopcode1 <invalidopcode1!> has joined #yocto19:58
paulgbuild and config scripts are different.20:00
paulgI actually have to data mine into what changed the source and why on a regular basis.20:01
rfs613i meant build scripts, CI pipeline, travisl.yaml and whatnot....  not autoconf and friends.20:01
paulgAnything that adds noise to that path is unwelcome.  Not to mention the pointless churn for maintainers.20:01
rfs613ah but how else can we gain "velocity" if we can't increase the number of commits through such tactics? :P20:02
paulg:-)  If I ever use velocity in a context like that, someone please come take my keyboard.20:05
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)20:08
paulgAnyway - 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
rfs613I 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
rfs613The otehr status all seem time-sensitive, eg. cannot trust them except at the moment of submission.20:14
rfs613For 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
RPpaulg: 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
RPpaulg: the key difference is we're tracking foreign SCM interactions, not our own and we have many of them for OE-Core, over a thousand20:18
paulgI'm not questioning the value of data.  Just how and where we store it.20:19
RPpaulg: where else would we put it? Just the commit message?20:19
paulgIf you change patch foo, document the status of patch foo.  Is that so unreasonable?20:20
RPpaulg: in general we don't have status changes on patches on their own. I know there is one example above but they are comparatively rare20:21
RPFor the amount of them we get I'm happy to have the status maintained and give people recognition if they do push patches upstream20:22
RPpaulg: or are you meaning Upstream-Status shouldn't be in the patch?20:23
paulgyes -exactly.20:23
RPTaking something like gcc, it is very helpful to be able at a glance through the patches and know what is going on with them20:23
DvorkinDmitrymckoan, 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 recipe20:24
RPIt also helps to be able to know which patches need attention and which ones don't without reviewing the commit logs for every patch20:24
paulgIt also means people get nagged about one extra hurdle they need to add before being a contributor, so they walk away.20:25
paulgSCMs exist for a reason.  Don't embed that in the source/patches.  It will be stale, neglected and untrustworthy.20:27
JaMazeddii: 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 warnings20:27
zeddiiJaMa: 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 it20:35
DvorkinDmitryis there are any example of the simple empty image creation with predefined size ?20:36
JaMaI'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 difficult20:36
DvorkinDmitryis it possible to create and format the empty (without content) partition with WIC?20:37
JaMaI 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
JaMato 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-!> has joined #yocto20:44
RPpaulg: 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 it20:46
RPpaulg: 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 mean20:47
RPIf 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 it20:48
RPpaulg: 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
RPWe 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
RPpaulg: 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
RPpaulg: I, and the other maintainers use them heavily and they are actually pretty decently maintained.20:52
RPpaulg: I can even show metrics about the current state of patches and the changes in numbers and state of them over time:
RP is perhaps a better more interesting over years view20:53
RPJaMa: we're a long way off making Pending a warning20:54
RPJaMa: 279 in core alone20:54
*** rob_w <rob_w!~rob@2001:a61:60dc:3e01:9d52:da62:96ab:8525> has quit IRC (Quit: Leaving)20:54
*** sakoman <sakoman!> has joined #yocto21:13
JPEWRP: 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
RPJPEW: share on the mailing list please?21:17
RPJPEW: much appreciated, thanks!21:18
*** goliath <goliath!~goliath@user/goliath> has joined #yocto21:23
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto21:26
RPJaMa: 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
JaMaRP: 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 unwanted21:32
JaMaRP: I've seen that in bugzilla and I guess I agree21:33
*** azcraft <azcraft!~AzCraft@> has joined #yocto21:35
JaMaqa.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 config21:36
RPJaMa: 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 there21:36
JaMapity that not all QA warnings could reasonably be on just 1 line21:37
RPJaMa: with the logfile approach you would still capture them21:38
JaMae.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 context21:39
RPJaMa: the project autobuilder has the same issue21:40
JaMae.g. linux-meson had 948 files listed in installed-vs-shipped :)21:41
JaMaand 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
RPJaMa: pros and cons I guess :)21:42
RPzeddii: FWIW that hacked up patch did fix reproducibility21:43
JaMayeah, I see there is an example from JPEW on ML already, will give it a try21:46
zeddiiRP: it was definitely a race.21:50
zeddiiI had my build host captured, cleaned, rebuild both the kernel, and then devsrc, and it didn't break.21:52
RPzeddii: must be something about the build from scratch21:52
JaMabtw anywone seeing WARNING: oe-core/meta/recipes-kernel/linux/ Duplicate inclusion for meta-virtualization/recipes-kernel/linux/ in meta-virtualization/recipes-kernel/linux/linux-yocto-dev.bbappend ?21:53
JaMaI 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 ongoing21:54
zeddiiRP: 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
zeddiiJaMa: 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
RPzeddii: do you want to send a patch with a proper commit message? or do you want me to make up something?22:04
RPzeddii: we could defer 6.1 until after M2 if you want to dig into it more too22:04
zeddiiI'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
zeddiisince I still can't say exactly HOW that is triggering.22:05
RPzeddii: 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
zeddiiahah. true. I will keep my build cycling here tonight, to see if I can cause it.22:06
RPzeddii: I've sent the patch. If it looks ok to you I'll merge 6.1 and then get on with M222:10
zeddiiI'll go look and follow up.22:10
RPpaulg: I suppose I should throw these ppc64 patches in too...22:11
paulgRP, 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 -
*** Piraty <Piraty!~irc@user/piraty> has quit IRC (Remote host closed the connection)22:17
RPpaulg: I didn't say where I was throwing them into :D22:18
*** ldericher <ldericher!~LDer@user/ldericher> has joined #yocto22:19
*** Piraty <Piraty!~irc@user/piraty> has joined #yocto22:19
*** Piraty <Piraty!~irc@user/piraty> has quit IRC (Client Quit)22:21
*** azcraft <azcraft!~AzCraft@> has quit IRC (Remote host closed the connection)22:21
paulgah right.  Dumpster fire.  Clay brick oven, ...22:23
*** Piraty <Piraty!~irc@user/piraty> has joined #yocto22:23
*** kscherer <kscherer!> has quit IRC (Ping timeout: 248 seconds)22:25
*** DvorkinDmitry <DvorkinDmitry!~dvorkin@> has quit IRC (Quit: KVIrc 5.0.0 Aria
RPrburton: 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 day22:29
* RP tries an rc2 build for M222:51
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)23:15
*** invalidopcode1 <invalidopcode1!> has quit IRC (Remote host closed the connection)23:18
*** invalidopcode1 <invalidopcode1!> has joined #yocto23:18
JaMazeddii: I think the Duplicate inclusion is triggered because linux-yocto-dev with 6.1 version now triggers both of these:23:30
JaMarecipes-kernel/linux/linux-%.bbappend:include ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'linux-${KERNEL_META_TYPE}_${LINUX_MAJOR}.${LINUX_MINOR}', '', d)}23:30
JaMarecipes-kernel/linux/linux-yocto-dev.bbappend:require ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', '', '', d)}23:30
*** amitk_ <amitk_!~amit@> has joined #yocto23:32
JaMazeddii: 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
JaMazeddii: my WIP fix
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 255 seconds)23:57

Generated by 2.17.2 by Marius Gedminas - find it at!