invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Bardon has joined #yocto
jclsn_ has quit [Ping timeout: 252 seconds]
jclsn_ has joined #yocto
seninha has quit [Remote host closed the connection]
jclsn_ has quit [Ping timeout: 260 seconds]
jclsn_ has joined #yocto
amitk has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
alessioigor has joined #yocto
davidinux has joined #yocto
olani- has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Schlumpf has joined #yocto
rob_w has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
wooosaiiii has joined #yocto
frieder has joined #yocto
mckoan|away is now known as mckoan
<LetoThe2nd>
yo dudX
<mckoan>
hi LetoThe2nd
zpfvo has joined #yocto
zpfvo1 has joined #yocto
Jham has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
<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?
<LetoThe2nd>
KareemZarka[m]: can you maybe give a one-sentence summary? we only got a link.
<landgraf>
KareemZarka[m]: most of the people in the channel are on IRC not Matrix
<landgraf>
KareemZarka[m]: So use one string messages and pastebin to paste logs etc
<LetoThe2nd>
landgraf: weren't you working on quite some autobuilder stuff lately?
<landgraf>
LetoThe2nd: No. I've not touched autobilder at all
<LetoThe2nd>
landgraf: then I'm confusing you with somebody else, sorry.
<landgraf>
LetoThe2nd: No problem. I'm used to it :D
<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
<KareemZarka[m]>
KareemZarka[m]: maybe a patch ?
gsalazar has joined #yocto
<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
<landgraf>
KareemZarka[m]: make in cofigurable (not just comment out) and submit a patch
<LetoThe2nd>
landgraf: in for some fun!
<landgraf>
if it's not already done
<KareemZarka[m]>
landgraf: can you elaborate on what you mean by 'make in configurable`?
<landgraf>
KareemZarka[m]: if bb.getVar("MY_FEATURE_FLAG"):
<frieder>
Hi, I'm using devtool upgrade && devtool finish on a recipe with git source.
<frieder>
The SRCREV is updated just fine, but devtool always rewrites my conditional SRC_URI override
<frieder>
So SRC_URI:append:test = "file://example.conf" is turned into SRC_URI += "file://example.conf"
leon-anavi has joined #yocto
<frieder>
Is there a way to make devtool preserve the SRC_URI override?
<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 ?
<KareemZarka[m]>
landgraf: right thanks , I appreciate it
prabhakarlad has joined #yocto
<landgraf>
KareemZarka[m]: np
mihai has quit [Quit: Leaving]
amitk_ has joined #yocto
florian has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
<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
davidinux has joined #yocto
<d-fens>
hmm pkg_postinst_${PN}{ looks promising
xmn has quit [Ping timeout: 248 seconds]
xmn has joined #yocto
zwelch has quit [Ping timeout: 252 seconds]
manuel1985 has joined #yocto
manuel__ has quit [Ping timeout: 252 seconds]
xmn has quit [Quit: ZZZzzz…]
zwelch has joined #yocto
ptsneves has joined #yocto
florian_kc has joined #yocto
lukma has joined #yocto
<lukma>
Dear all, I do have a question regarding kernel-devsrc
<lukma>
It looks like after the commit: 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
<lukma>
It has been adjusted (and trimmed) to only allow building modules (i.e. *.[hc] files were omitted)
<lukma>
Is there any other recipe which brings the "old behaviour" ?
<lukma>
I mean - to install all sources, so I would be able to build the linux kernel on the target system?
<lukma>
Or such recipe is not present, so I would need to tweak its do_install() function and copy all missing *.[hc] files?
tomzy_0 has joined #yocto
<qschulz>
zeddii: that's probably a question for you? ^
<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)
<RP>
lukma: I think Bruce does have such a recipe in another layer somewhere
<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?
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
<tomzy_0>
morning
<RP>
JaMa: I had to put a "-" in PV due to icu for that reason :(
<RP>
JaMa: I'm not really sure. You could just clear BB_HASH_CODEPARSER_VALS I guess as a really quick fix
<RP>
JaMa: that wasn't related but when I chose values for the new VALS, I had to pick one with a "-" in it
jclsn_ has quit [Quit: WeeChat 3.7.1]
<JaMa>
can I set BB_HASH_CODEPARSER_VALS in the bbclass? I guess it's too late, right?
<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
<RP>
JaMa: it isn't too late
<JaMa>
ok, will try that first, thanks
<RP>
JaMa: this is when you'll want to change the format so you can just change PN more easily
* RP
is torn on making it crazy complex which is where this ends up heading :(
<RP>
Clearing it just gets the original behaviour, not perfect for the cache but...
<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')?
<JaMa>
BB_HASH_CODEPARSER_VALS:remove = "PN=nopn" seems to work, thanks
<RP>
JaMa: it just means it will parse a few more expression combinations that it would have otherwise needed to
<RP>
JaMa: for a few recipes it doesn't matter, the effect is significant over a few thousand recipes
<JaMa>
OK, but does it cache the results, like Memoize decorator (so caching relevant few combinations helps later)?
<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 :/
<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.
<RP>
ptsneves: it is a value concern, I'm just hoping we can choose our values here to avoid it
<RP>
a valid concern!
<ptsneves>
Anyway i see lots of work on bitbake innards. Thank you :)
<RP>
ptsneves: np, hopefully things will improve :)
<d-fens>
whats the best way to allow a user to use sudo in yocto?
<d-fens>
went with a sudo_%.bbappend adding a file in /etc/sudoers.d
DvorkinDmitry has joined #yocto
<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?
<landgraf>
DvorkinDmitry: does your package depends on sudo?
<DvorkinDmitry>
landgraf, yes, it does
<landgraf>
(rdepends)
<DvorkinDmitry>
yes
<landgraf>
DvorkinDmitry: then dir should be owned by sudo, not your package
<DvorkinDmitry>
landgraf, I need to install 1 file to this dir from my recipe...
zhmylove has joined #yocto
<DvorkinDmitry>
landgraf, how can I do it correctly not conflicting with sudo?
<rburton>
i think you need to mark your file as a CONFFILE
<landgraf>
or install in sudo_%.bbappend instead
<rburton>
in your own package would be the right thing to do
<DvorkinDmitry>
rburton, I found DIRFILES = "1"... but my recipe contains a lot more files. Is it the only way around?
<rburton>
dirfiles is a list of paths
<rburton>
easy fix is don't use rpm :)
<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.
<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.
<rburton>
DvorkinDmitry: ah, check the perms on sudoers.d match?
<DvorkinDmitry>
rburton, good idea! they are not. Trying...
<rburton>
iirc, if they match rpm is happy
amitk__ has joined #yocto
mvlad has joined #yocto
amitk_ has quit [Ping timeout: 252 seconds]
<landgraf>
rburton: Yes. I see the comment now. this should be fixed IMO... conf.d/ is popular way of config handling
<rburton>
landgraf: aye. i think its a perms thing. hopefully good news from DvorkinDmitry in a minute.
<DvorkinDmitry>
exactly. thanks!
<ptsneves>
is there any harm in having a duplicated value in DISTRO_FEATURES?
<rburton>
urllib.request should have a __main__ for easy testing
Wouter01006704 has joined #yocto
<paulg>
There are ubu 16.04 references in there - I thought that got dropped?
<RP>
paulg: it did, they don't hurt anything
<paulg>
fair point.
<paulg>
might even still build if you beat it with a stick for an hour....
<rburton>
AHA i replicated it!
<rburton>
but that makes no sense why its only occasional
kalj has joined #yocto
olani has quit [Ping timeout: 268 seconds]
<RP>
rburton: what did you need to do to replicate?
<RP>
paulg: we use so little from the host I suspect it would still work
olani has joined #yocto
<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.
<RP>
rburton: ah. That would explain things :/
<RP>
rburton: so it only fails if the cve checks run on a buildtools host?
<rburton>
i sure hope so :)
<rburton>
i'll double check that, but i can replicate using the buildtools i happened to have to hand
sakoman has joined #yocto
<JaMa>
sakoman: Hi, was the last kirkstone merge postponed? I've seen that kirkstone-nut was moved to kirkstone-next
<sakoman>
JaMa: I think RP just forgot to do the previous pull request, so I combined it with the most recent pull request
<JaMa>
ok, fair enough, I see another "cover letter only" from yesterday which combines both
<JaMa>
so I'll be just a bit more patient for ffmpeg fix :)
<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 :-(
<alessioigor>
Hi all
<alessioigor>
Which recipe matches the (cross) compiler used in the SDK? I have to change the target triplet used...
<JaMa>
sakoman: understood and thank you
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
tomzy_0 has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 264 seconds]
xmn has joined #yocto
<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 :(
<JPEW>
RP: For example, when `OVERRIDES = "B"`, d.getVar("VAR") == "0", which makes no sense to me
florian has quit [Quit: Ex-Chat]
<JPEW>
Anyway, I pushed my test bb file to the branch; maybe I'm doing something silly there
<JPEW>
Of course! overrides have to be lower case (face palm)
kalj has quit [Quit: Client closed]
<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
<JPEW>
Ya, I've found a weird case already :)
<RP>
JPEW: in yours or bitbake? :)
<JPEW>
bitbake
<RP>
JPEW: we do have bitbake-selftest bb.tests.data FWIW
<JPEW>
Ya
<JPEW>
with `OVERRIDES="b:a"`, `d.getVar("VAR") == 2`, when I would have expected it to be `5`
<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
<RP>
JPEW: I didn't check whether you had the priority application order right
<JPEW>
I do in general
<JPEW>
It handles single depth overrides correctly
<RP>
JPEW: I suspect that :b:a was defined to win against :a:b originally and I preserved that
<RP>
JPEW: you can definitely argue that should be the other way :/
<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
<JPEW>
I don't think there is any magic data structure that can make that behavior efficient, but I'll keep looking :/
nemik has quit [Ping timeout: 264 seconds]
prabhakarlad has joined #yocto
<RP>
JPEW: this might be why the code is structured the way it is :/
<JPEW>
Yep
<RP>
JPEW: Are there any tests which check that behaviour specifically ?
xeche_ has quit [Quit: leaving]
<RP>
I'm wondering how much real world use we have of this corner case
<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 :)
<JPEW>
Let me see
nemik has joined #yocto
<JPEW>
RP: Looks like there are _no_ tests of nested overrides
<JPEW>
There are priority tests, but none that go more than one level deep
<RP>
JPEW: excellent. So if we change it, nothing regresses :D
<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`
<JPEW>
`OVERRIDES` is well ordered for us in most cases
<JPEW>
Have to think on it a little
<JPEW>
Right "the tests pass we are fine" :P
<JPEW>
"Ship It!"
<RP>
JPEW: I'm struggling to think of a case where you'd have both sets defined
<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
<JPEW>
And even when the order matters, I think it would have to be pretty esoteric for this to matter
<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
<RP>
(and assuming some build tests don't break)
<JPEW>
right
* JPEW
checks the release schedule
<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 _
<frieder>
vmeson: I also found this and I have this patch in my tree, but unfortunately it doesn't seem to cover my case.
<frieder>
vmeson: I suspect that devtool simply doesn't handle these SRC_URI overrides correctly at the moment.
Jham has quit [Quit: Leaving]
<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
<frieder>
vmeson: At least that's what I seemed to understand from looking at the code for a while
<rburton>
zeddii: did i hear you say something about meta-virt and 6.1?
<rburton>
zeddii: would it be in relation to "Couldn't find anything to satisfy 'kernel-module-xen-blkback'."
<zeddii>
I have a patch on master-next to update the kernel config to match on 6.1.
<zeddii>
it would yes
<rburton>
great, thanks :)
<zeddii>
I'll push it today, once I'm done poking at perf.
<rburton>
+1
alessioigor has quit [Quit: alessioigor]
ptsneves has quit [Ping timeout: 252 seconds]
frieder has quit [Remote host closed the connection]
florian has quit [Ping timeout: 252 seconds]
<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.
mckoan is now known as mckoan|away
<RP>
zeddii: that header difference is in kernel-devsrc, not perf :/
<RP>
zeddii: whether that leads to the perf problem, I don't know
<zeddii>
RP: that's where my grep was from. build/work-shared/ .. kernel-source, that's where perf is grabbing it from.
<zeddii>
'er wait. well, the source is there, but generated is from the artifacts. I need to check that
<RP>
zeddii: after you run "bitbake kernel-devsrc", the copy in work-shared is corrupted
<zeddii>
yah.
<RP>
zeddii: I'd guess the perf build might then corrupt if it runs after that
<zeddii>
I'm grepping the kernel build itself, and it has the consistent oe-host
<RP>
zeddii: it wasn't like that until I build kernel-devsrc
<zeddii>
devsrc isn't inheriting the class that sets it ? checking
<zeddii>
yah. I just see linux-kernel-base
<RP>
zeddii: looks likely!
zpfvo has quit [Quit: Leaving.]
<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
<RP>
zeddii: maybe we just move the export to linux-kernel-base ?
<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 :)
<zeddii>
that'd work as well, kernel.bbclass iimports that.
<RP>
zeddii: which of us wants to write a patch to test? :)
PhoenixMage has quit [Ping timeout: 252 seconds]
<zeddii>
I was sitting here trying to figure out how kernel-devsrc is triggering that build, some sort of race with perf I guess.
<RP>
zeddii: it something tramples on the builddir, it will affect anything running after it
<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.
<zeddii>
so your locale reproduce of the issue ? you just did a bitbake kernel-devsrc and looked in the kernel build artifacts ?
<zeddii>
I want to do the same, so maybe I can track down how this is now triggering in 6.
<RP>
zeddii: I ran "bitbake kernel-devsrc" and then looked at the shared workdir and saw compile.h had changed
<zeddii>
ack'd
<zeddii>
yup. I see my build host captured now.
<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).
<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
<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 :)
<zeddii>
just moving those few KBUILD values should be enough.
<paulg>
everybody else moved their SCM tracking out of the source itself by 2008.
<paulg>
Just sayin.
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
mvlad has quit [Remote host closed the connection]
<rfs613>
paulg: only to then move their CI configuration scripts into the repo, causing endless "bump X to try fixing build" commits ;-)
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<paulg>
build and config scripts are different.
<paulg>
I actually have to data mine into what changed the source and why on a regular basis.
<rfs613>
i meant build scripts, CI pipeline, travisl.yaml and whatnot.... not autoconf and friends.
<paulg>
Anything that adds noise to that path is unwelcome. Not to mention the pointless churn for maintainers.
<rfs613>
ah but how else can we gain "velocity" if we can't increase the number of commits through such tactics? :P
<paulg>
:-) If I ever use velocity in a context like that, someone please come take my keyboard.
sakoman has quit [Quit: Leaving.]
<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..."
<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).
<rfs613>
The otehr status all seem time-sensitive, eg. cannot trust them except at the moment of submission.
<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)
<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.
<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
<paulg>
I'm not questioning the value of data. Just how and where we store it.
<RP>
paulg: where else would we put it? Just the commit message?
<paulg>
Yes.
<paulg>
If you change patch foo, document the status of patch foo. Is that so unreasonable?
<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
<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
<RP>
paulg: or are you meaning Upstream-Status shouldn't be in the patch?
<paulg>
yes -exactly.
<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
<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
<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
<paulg>
It also means people get nagged about one extra hurdle they need to add before being a contributor, so they walk away.
<paulg>
SCMs exist for a reason. Don't embed that in the source/patches. It will be stale, neglected and untrustworthy.
<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
<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.
* 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
<DvorkinDmitry>
is there are any example of the simple empty image creation with predefined size ?
<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
<DvorkinDmitry>
is it possible to create and format the empty (without content) partition with WIC?
<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 :)
<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.
olani- has joined #yocto
<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
<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
<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
<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.
<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.
<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.
<RP>
paulg: I, and the other maintainers use them heavily and they are actually pretty decently maintained.
<RP>
JaMa: we're a long way off making Pending a warning
<RP>
JaMa: 279 in core alone
rob_w has quit [Quit: Leaving]
sakoman has joined #yocto
<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?
<RP>
JPEW: share on the mailing list please?
<JPEW>
OK
<RP>
JPEW: much appreciated, thanks!
goliath has joined #yocto
Minvera has joined #yocto
<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?
<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
<JaMa>
RP: I've seen that in bugzilla and I guess I agree
azcraft has joined #yocto
<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
<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
<JaMa>
pity that not all QA warnings could reasonably be on just 1 line
<RP>
JaMa: with the logfile approach you would still capture them
<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
<RP>
JaMa: the project autobuilder has the same issue
<JaMa>
e.g. linux-meson had 948 files listed in installed-vs-shipped :)
<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 :)
<RP>
JaMa: pros and cons I guess :)
<RP>
zeddii: FWIW that hacked up patch did fix reproducibility
<JaMa>
yeah, I see there is an example from JPEW on ML already, will give it a try
<zeddii>
RP: it was definitely a race.
<zeddii>
I had my build host captured, cleaned, rebuild both the kernel, and then devsrc, and it didn't break.
<RP>
zeddii: must be something about the build from scratch
<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 ?
<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
<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.
Minvera has quit [Remote host closed the connection]
<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.
<RP>
zeddii: do you want to send a patch with a proper commit message? or do you want me to make up something?
<RP>
zeddii: we could defer 6.1 until after M2 if you want to dig into it more too
<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"
<zeddii>
since I still can't say exactly HOW that is triggering.
<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!
<zeddii>
ahah. true. I will keep my build cycling here tonight, to see if I can cause it.
<RP>
zeddii: I've sent the patch. If it looks ok to you I'll merge 6.1 and then get on with M2
<zeddii>
I'll go look and follow up.
<RP>
paulg: I suppose I should throw these ppc64 patches in too...
<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.
<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)?