qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
mranostaj has quit [Remote host closed the connection]
mranostaj has joined #yocto
FredO has quit [Read error: Connection reset by peer]
jwillikers has quit [Remote host closed the connection]
d0ku has quit [Ping timeout: 252 seconds]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
FredO has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
sakoman has quit [Quit: Leaving.]
te_johan has quit [Remote host closed the connection]
te_johan has joined #yocto
te_johan has quit [Ping timeout: 256 seconds]
te_johan has joined #yocto
te_johan has quit [Ping timeout: 245 seconds]
cocoJoe has joined #yocto
amitk has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
<dwagenk>
Good morning! Trying to get some feedback whether the following would be a welcome change to openembedded-core:
<dwagenk>
openembedded-core/meta/classes/mirrors.bbclass already contains a rule to fetch git repos via https if git protocol fails (common due to corporate firewalls).
<dwagenk>
This logic works, if the URI for both protocols is identical.
<dwagenk>
On many servers (using cgit as WebUI) the URI for fetching via https contains a "git/" as first part of the path. See the following line from mirrors.bbclass thast handles this rewrite for git.yoctoproject.org:
<dwagenk>
I suggest to add a general rule for these cases to mirrors.bbclass
<dwagenk>
and remove the then obsolete server-specific rewrite rules.
<dwagenk>
Has this been discussed and dismissed before? Or should I send a patch?
manuel_ has quit [Remote host closed the connection]
ndec[m] has left #yocto [#yocto]
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
frieder has joined #yocto
wwilly has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
te_johan has quit [Remote host closed the connection]
te_johan has joined #yocto
<wCPO>
Can a PACKAGECONFIG have another PACKAGECONFIG as dependency?
LetoThe2nd has joined #yocto
LetoThe2nd has left #yocto [#yocto]
<JosefHolzmayr[m]>
yo dudX
rfuentess has joined #yocto
<mihai>
yo
<mihai>
wCPO: nope
bps has quit [Ping timeout: 244 seconds]
florian has joined #yocto
manuel1985 has joined #yocto
<JosefHolzmayr[m]>
wCPO: you could add a function to the recipe that checks the packageconfig and errs out on an invalid combination.
<qschulz>
JosefHolzmayr[m]: wth happened to your nick :o
<JosefHolzmayr[m]>
qschulz: currently on a matrix/element test
<qschulz>
best of luck
<JosefHolzmayr[m]>
so far its ok. not overwhelming, but interesting.
Belsirk has joined #yocto
Belsirk has quit [Client Quit]
mihai- has joined #yocto
rfuentess has quit [Ping timeout: 252 seconds]
mihai has quit [Ping timeout: 240 seconds]
d0ku has joined #yocto
<RP>
vmeson: FWIW the issues are because LD_LIBRARY_PATH is being set and confusing the binaries
<zyga-mbp>
zeddii I had a look at a go fetcher
<zyga-mbp>
I think it's relatively easy
<zyga-mbp>
some things suck though, mostly licenses
<zyga-mbp>
while the go system explicitly packages LICENSE in addition to the sources
<JosefHolzmayr[m]>
"go fetcher" sounds almost like "sudo make me a sandwich"
<zyga-mbp>
some projects have a different file in their tree
<zyga-mbp>
I will spend time _next week_ on a prototype
<zyga-mbp>
but it seems highly doable with this assumption:
<zyga-mbp>
the fetcher will be like npm fetcher
<zyga-mbp>
each recipe will describe a go module like what you can specify to go install or go download
<zyga-mbp>
each recipe will fetch the go module cache and keep _that_ as the source
<zyga-mbp>
the -dev and -src and other binary packages will change for sure
<zyga-mbp>
the up side is that we stay compatible with the go ecosystem
<zyga-mbp>
there's exactly zero things that are custom since go does all the hard work
<zyga-mbp>
and multi-version problem in avoided
<zyga-mbp>
packages should be also quite easy to maintain, with the exception of license checker that may need to be a bit more elaborate
<zyga-mbp>
as any non trivial recipe will have dozens of licenses
<zyga-mbp>
JosefHolzmayr[m] I wish go made me a sandwitch now ;)
<JosefHolzmayr[m]>
"go fetch me a beer"
<zyga-mbp>
another consequence is that the fetcher will be a separate ecosystem from the go.bbclass and go-mod.bbclass packages
<zyga-mbp>
and I honestly would deprecate them
<zyga-mbp>
since it seems like a dead-end
<zyga-mbp>
I did not look at cgo but apart from a set of variables to set, I don't expect problems yet
bps has joined #yocto
bps has joined #yocto
<te_johan>
in a older yocto version i used IMAGE_POSTPROCESS_COMMAND to zip some files from DEPLOY_DIR_IMAGE. the files are now deployed later so that does not work.
<JosefHolzmayr[m]>
te_johan: "older" means "pre-morty", right? ;-)
<te_johan>
that would be sumo :)
<JosefHolzmayr[m]>
te_johan: that sounds strange. but anyways you usually want to use IMGDEPLOYDIR for algorithmic use, not DEPLOY_DIR_IMAGE
<te_johan>
ok thanks
camus has quit [Quit: camus]
camus has joined #yocto
<RP>
Well, I can see why cargo-native breaks on centos7. How to fix it? No idea :(
tnovotny has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
BCMM has joined #yocto
<JosefHolzmayr[m]>
RP: when cargo is broken, one usually puts it into a container and ships it back,
<Guest28>
How can I execute shell or python script from conf file?
<JosefHolzmayr[m]>
Guest28: what are you trying to archieve?
<Guest28>
JosefHolzmayr[m] get hostname
<JosefHolzmayr[m]>
Guest28: why would one want that?
<JosefHolzmayr[m]>
such would sabotage build reproducibility.
<Guest28>
JosefHolzmayr[m] I want to fill in PACKAGE_FEED_URIS to the hostname currently building.
<JosefHolzmayr[m]>
Guest28: better approach. set it to a variable, maybe "MYMAGICPACKAGEFEEDSOURCE". whitelist that variable, and pass it in through the environment.
<JosefHolzmayr[m]>
and voila, you can both have the cake (reproducible, host independent build) and eat it (set PACKAGE_FEED_URIS)
<Guest28>
JosefHolzmayr[m] you men set variable in local.conf and then pick it up in conf file?
<JosefHolzmayr[m]>
erm, what "conf" file are you talking about?
<qschulz>
Is the conf file a bitbake conf file? (i.e. distro.conf, <machine>.conf local.conf, layer.conf, ...)
<JosefHolzmayr[m]>
like i said. set it in the environment, example: "MYMAGICPACKAGEFEEDYOURCE=$(hostname) bitbake my-cool-image"
mihai- is now known as mihai
<JosefHolzmayr[m]>
add MYMAGICPACKAGEFEEDSOURCE to BB_ENV_WHITELIST for your build, and you can use it everywhere.
<Guest28>
can BB_ENV_WHITELIST be put in build/local.conf file?
<qschulz>
I think you might be able to set PACKAGE_FEED_URIS from an image recipe directly
<JosefHolzmayr[m]>
qschulz: it might indeed have special properties. a good example for checking the actual situation first instead of going for the first solution that comes to mind ("executing random code in local.conf")
<qschulz>
nope never mind, it's globally inherited
<qschulz>
(the class rootfs_ipk that is using this variable)
<qschulz>
but this is going to destroy the sstate-cache
rber|res has joined #yocto
<qschulz>
also why should the hostname matter to the package feed?
<Guest28>
wanted to append package feed with local build machine that developer is sitting on and building from
<JosefHolzmayr[m]>
i guess that this for local dev images that should be automagically be able to use a package feed.
<Guest28>
JosefHolzmayr[m]correct
<JosefHolzmayr[m]>
which is a legit usecase to me, but the approach is not a good one.
<qschulz>
I think you should add an init script (which can have some build machine specific settings) that is configuring the package feed at runtime
<qschulz>
and this init script would be provided in one recipe only, reading the hostname from within an anonymous python function I guess
<qschulz>
and inserting it in the init script
<qschulz>
which is installed via the package created by the recipe included inside the image recipe
<mcfrisk>
hi, could/should "seccomp" be one of DISTRO_FEATURES?
<qschulz>
if the anonymous python cannot for some reason get the hostname of the build machine, then use the mechanism provided by JosefHolzmayr[m] but still use a separate recipe as I explained above
<qschulz>
I think it's the less intrusive solution, still being able to use a global sstate-cache in your company but have the ability for developers to use packages they built locally
<Guest28>
qschulz ok, thanks the proposal. the procedure is a bit involved. could i not then just append the file /etc/opkg/base-feeds.conf directly with an append file?
<qschulz>
i rechecked again and I think you don't need any of this and going with the original solution suggested by JosefHolzmayr[m] (BB_ENV_WHITELIST + MYMAGICPACKAGEFEEDSOURCE)
<qschulz>
should work just fine
<qschulz>
this is because the rootfs_ipk.bbclass which is inherited globally just sets flags for the do_rootfs task, which means it applies to recipes with a rootfs task only
<qschulz>
but you should check by yourself if it does not trigger a full rebuild
<qschulz>
otherwise, I think it's safe to just modify the PACKAGE_FEED_URIS from the image recipe directly
<RP>
mcfrisk: possibly
<qschulz>
which means only the image recipe will be impacted with the PACKAGE_FEED_URIS change and lose the benefit of sstate-cache
goliath has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
xmn has joined #yocto
* RP
might have a fix for cargo on centos7. I hate it though :/
<qschulz>
RP: and if my understanding is correct, if a package is put into an RDEPENDS whose name only exists in RPROVIDES, the build will fail because bitbake is not in charge of resolving RDEPENDS but the package manager, so bitbake sees it exists in some recipe so confirms RDEPENDS is valid but the recipe won't be built so the package manager will fail
<RP>
qschulz: the build won't fail, you need to think about the case two packages put the same entry in RPROVIDES
<RP>
then what happens?
<qschulz>
basically it depends on the recipe (or one of its package, without RPROVIDES "mechanism") being pulled in as a (runtime/build time) dependency to have this "RPROVIDES package" built and available to the package manager
<RP>
qschulz: if there is just one entry, things are fine and bitbake and the package manager will agree
<RP>
well, you hope they would
<qschulz>
if there are two (which I assume is often the case, otherwise RPROVIDES has a limited usecase?), then bitbake can't know but knows it can be satisfied so it'll be up to the package manager to pick the package. Assuming of course only one of the packages RPROVIDES'ing the same string is built
<RP>
qschulz: right, but that is the issue? Which one does bitbake choose and would the package manager choose the same one?
<qschulz>
My assumption is that if you have two packages RPROVIDES'ing the same thing (during parsing!), RDEPENDS mechanism will not trigger a build of one of the recipes
<qschulz>
of either of the recipes*
<RP>
qschulz: I'm not actually sure what bitbake does with that to be honest
<qschulz>
so then it depends on one of the recipes to be built so that one package is built and available to the package manager, which will then take care of fulfilling the RDEPENDS
<qschulz>
but all just guesses :)
<qschulz>
and it seems to be a rather complex topic, so should definitely be documented (better?) :)
<RP>
qschulz: I think bitbake could allow multiple providers of the thing to built. It would then be up to the package manager
<qschulz>
but then how would the package manager pick the appropriate package to use since we don't have PREFERRED_RPROVIDER?
<qschulz>
so many questions /o\
<RP>
qschulz: this is why it is not supported
<qschulz>
I need to re-read your mail I think because I don';t see why the ability to specify RPROVIDES was ever given
<RP>
qschulz: package managers need RPROVIDES+RREPLACES to replace other older packages with newly named ones
<qschulz>
now it clicks :)
<qschulz>
Thanks!
bps has quit [Ping timeout: 252 seconds]
<RP>
zeddii: it is something in the last changes in meta-oe :(
<RP>
khem: something in meta-oe that changed recently is breaking meta-virt in yocto-check-layer :(
manuel_ has quit [Remote host closed the connection]
<RP>
zeddii, khem, tgamblin: Looks like two copies of a python recipe, one in meta-oe, one in meta-virt. Can you resolve this between you and stop breaking the autobuilder, please? :)
<tgamblin>
RP: zeddii: echoing here but it's because python3-cached-property was recently added to meta-python with the same version but different recipe content
<tgamblin>
RP: zeddii: khem: yes. I think we should remove it from meta-virtualization now that it's in meta-python, unless having BBCLASSEXTEND = "native" is a dealbreaker for meta-virtualization
<tgamblin>
Both layers carry the same version. The only difference is that the meta-python one includes that BBCLASSEXTEND line, and adds DESCRIPTION and SECTION
manuel1985 has joined #yocto
<zeddii>
I'd prefer not to remove it.
otavio has joined #yocto
<zeddii>
it has had some specifc version dependencies in the past, and I can't chase version bumps constantly in meta-python.
<RP>
zeddii: this could be a bit tricky given there are other recipes in meta-python that now appear to depend on it :(
<zeddii>
queue my complaint about 'language layers'
<tgamblin>
RP: zeddii: the other solution would be setting BBFILE_PRIORITY, but which should be higher?
<RP>
tgamblin: It won't help pass the compat tests
<zeddii>
I can always rename mine to something else, and/or start copying more of the dependencies into meta-virt to avoid meta-oe
<RP>
zeddii: I suspect you hit the same issue even if you don't have language layers as soon as you have two "topic layers" using the same thing :(
<RP>
zeddii: copying dependencies will just make meta-virt and meta-oe not get on :/
<RP>
I suspect if you make the recipes match, the layer check will be ok again
<RP>
until one upgrades and the other doesn't
<tgamblin>
I can send a patch to meta-virtualization to make the changes, and after that I'll have to keep an eye out for it or something
<zeddii>
tgamblin: I'll just give the meta-virt one a different name with -virt- or something similar in the middle. Saves me adding a pinned version in the meta-virt conf files as well.
<RP>
zeddii: won't that cause problems on target trying to install both together?
<RP>
I think I need to keep out of this one! :)
<zeddii>
hmm. I suppose so. I can just figure out what is using it in meta-oe, see if it is needed for meta-virt and blacklist it if virt is enabled in distro features.
<JPEW>
ACK, ELC requires pre-recorded virtual talks by the 7th!. I just started my slides last night!
<JosefHolzmayr[m]>
JPEW: wut ELC is prerecorded?
<zeddii>
JPEW: I'm in tough on that as well :D
<zeddii>
And I just had to record my linaro connect one yesterday, which means I haven't done anything on ELC
<JPEW>
JosefHolzmayr[m]: If you are doing it virtually
<JosefHolzmayr[m]>
JPEW: yay for hybri.
<JosefHolzmayr[m]>
+d
<JPEW>
I thought they would have a virtual live option so I could be lazy and not finish my talk until the day before :)
<tgamblin>
zeddii: Alright, let me know if I can help
<JosefHolzmayr[m]>
JPEW: d'oh. at least for the mentorship session they don't "require" more than a quick check 30 minutes early and just going on zoom.
<tgamblin>
As mentioned the only functional difference I see is BBCLASSEXTEND = "native", there are no distinct DEPENDS/RDEPENDS
<RP>
zeddii, tgamblin: if you could make the DESCRIPTION/SUMMARY match for now that will probably silence the autobuilder issue for a bit :)
paulg has joined #yocto
<JPEW>
RP: poky-contrib/jpew/sbom is ready for me to send a PR for; I have a lot of changes to create-sdpx.bbclass as we found issues. Do you want all those squashed into a single commit?
mxang has joined #yocto
<RP>
JPEW: it depends if you think the development history is useful
<RP>
JPEW: can you change "Fix BSD license" to "Use a specific BSD license variant"?
<JPEW>
Yes
<RP>
JPEW: those commits could do with a long log "Make the license more accurate by specifying the variant of the BSD license rather than the generic one" too
<RP>
or similar
goliath has quit [Quit: SIGSEGV]
<JPEW>
I can do that too
<RP>
JPEW: the changes to create-spdx do tell a story so may be useful to preserve, at least some of it
<JPEW>
K, sounds good to me
<rburton>
RP: is it too late to rip out the 'BSD' license from common-licenses?
<RP>
rburton: how close are we to cleaning up core?
<rburton>
a quick grep said ~15 instances in core, so if jpew fixed most of them then close
<RP>
vmeson: rust fix sent out. Please don't judge it too harshly, it is horrible
<rburton>
biggest problem would be a selftest refers to it, but that might be trivial
<RP>
rburton: I'd be happy to see it removed and I think there is just time if the patches get here now
<RP>
will cause some complaining no doubt
<rburton>
there's still some left in core
<RP>
heh, and bad RP didn't check the malloc return code
* RP
tries to decide if he cares
<rburton>
but shouldn't be *too* much effort to sort
<RP>
rburton: I've had a lot of "not too much effort" recently ;-)
<rburton>
lol
* paulg
thinks RP just called rust "horrible". :)
<RP>
paulg: My hack to it is horrible, I try not to comment on rust itself
<RP>
assuming you have the checkout set with an email address for patches
<JPEW>
RP: Ya. I thought I could be tricky and use the script :)
<JPEW>
I'll just send them the usual way
<vmeson>
RP: paulg: lol! RP: makes sense to me, even before coffee!
<rburton>
JPEW: looked at three "BSD" using recipes, and ran away screaming twice. hdparm and lsof both use 'bsd-like' custom licenses
<JPEW>
rburton: Ya, some of they are bad
<JPEW>
I *think* what you do in that case is add a custom license to the SPDX document
<rburton>
need to represent that in yocto first really though
<JPEW>
RIght
<JPEW>
Maybe "BSD-like" ?
<JPEW>
I had a really hard time finding what license some arbitrary license text should be called. Does anyone know if there is some "licence fragment search engine"?
dlan has quit [Remote host closed the connection]
<rburton>
there is but i can't remember what its calld
<rburton>
need a better way to handle totally custom licenses per recipe
<vmeson>
and here I was going to make a flattering comment about how I test drove a Golf R (hot hatch) last night with a friend and was thinking that an Golf RP would be even more powerful^Hannoying.
<RP>
vmeson: Sorry, I'm really not happy with rust atm
<RP>
sgw: I've hopefully sorted out my swat flagged builds
* RP
is back to another rebuild on the AB. I pulled the license stuff in so it will be a while
<RP>
vmeson: I've revised the cargo change to apply to rust-common instead
<qschulz>
wCPO: you could do an anonymous python function which checks if repart is in PACKAGECONFIG and if so, checks that openssl is in it too otherwise fails with bbfatal
<qschulz>
another way could be to add the content of the PACKAGECONFIG[openssl] to repart too
<qschulz>
but the first one feels better :)
<qschulz>
you could even add openssl to PACKAGECONFIG from the anonymous function!
<wCPO>
I think that would be the most ideal solution
<mihai>
wCPO: you can also add another line in systemd's PACKAGECONFIG, to check if said PACKAGECONFIG contains repart then enable repart and openssl
<JPEW>
wCPO: IMHO I'd make it error instead of adding it implicilty. Don't want to accidently do something the user doesn't want
<mihai>
but I'm not sure if this will create a loop
<mihai>
or maybe it makes more sense to have "repart" as a distro feature so you can check for it there
frieder has quit [Remote host closed the connection]
<qschulz>
overkill to have a distro feature for that
<qschulz>
I agree with JPEW :)
* RP
would just add the anon python to error if the config is wrong
<mihai>
this could also turn intro a feature request, as long as there's a field for conflicting packageconfig options, there could be one for dependent options too :)
linkliu60 has joined #yocto
tepperson has joined #yocto
<tepperson>
is it possible to modify the /etc/fstab file based on the image type? my wic files have a good fstab, but my ext4.gz needs fstab modification.
<rburton>
smurray: when i next looked at the version report i'd have noticed
<rburton>
JPEW: awesome
<smurray>
rburton: heh, someone's asking about it wrt AGL so I did a test build and happened to notice
<JPEW>
SPDX does some different line wrapping/formatting, so it will rewrite most of the generic license files the first time
amitk has quit [Ping timeout: 240 seconds]
<vmeson>
RP, abelloni, tgamblin, sgw: Sadly, I don't have a shiny new graph for the "YP AB INT" meeting tomorrow. ;-) Unless someone has made some progress to report or really want to discuss something, I'll cancel this week's meeting.
<tgamblin>
vmeson: I was going to discuss my latest attempts with our internal AB, but I can just bring it up after the bug triage if that is going to be the only topic
florian has joined #yocto
<RP>
vmeson: I think we're all a bit rusty so probably not a lot to report
<vmeson>
RP lol! tgamblin: yeah, let's do that!
<RP>
abelloni: you are sending me a ptest patch right? :)
<abelloni>
I'm on it and I'm not progressing as fast as I would like ;)
<RP>
abelloni: cool. I'd just hate you to think I'd forgotten! ;-)
<rburton>
JPEW: two commits, one to sync formatting and one to add new licenses, seems sensible and easy to review
<RP>
rburton: Is there a patch ready to merge? If so I'll take it
stwcx has joined #yocto
<rburton>
JPEW: can you send a patch with the result of your script today? I can handle that if not.
<rburton>
this script needs to be threaded for speed
<rburton>
well, pipelined would most likely help and be easier
<RP>
rburton: I guess if it is changing existing licenses, that will need more careful review too as if the checksums change, so will a load of other checksum entries
<RP>
Adding the missing ones may be a good start
flynn378 has quit [Ping timeout: 276 seconds]
<rburton>
just the missing ones:
<rburton>
314 files changed, 21319 insertions(+)
<RP>
hmm
<rburton>
yeah porting that script to urllib3 is a lot faster
<rburton>
(pipelined http)
flynn378 has joined #yocto
angolini has joined #yocto
stwcx has quit [Quit: Connection closed]
florian has quit [Ping timeout: 252 seconds]
<rburton>
we have about 20 licenses which are not in SPDX too
<rburton>
some of those are just aliases we can remove and update
<RP>
rburton: right
<rburton>
stuff like bzip and pkgconf i guess should be checked, and worst case turned into recipe-specific licenses instead
<rburton>
ok patch sent as i'm going away now, RFC in case josh wants to send a better one as its his tool :)
<RP>
rburton: I know bzip2 has a specific 1.0.4 license which has a spdx version too
<rburton>
we might just need to rename that too then
<RP>
spdx are interested in a list of licenses in a common linux system they don't have
<rburton>
JPEW: some patches for the tool you may or may not like in my branch
<fray>
ya I thought all of the licenses were covered by SPDX now, sometimes the 1:1 mapping wasn't obvious... but it was there when I last looked (about 2-3 years ago)
<rburton>
spdx has bzip 105 and 106
<rburton>
seriously people there should be about 3 licenses in the world
<sgw>
rburton: I looked at the history, busybox has an explicit bzip2-1.0.4 License, while SPDX has dropped that from their list, we will need to create a "LicenseRef-bzip2-.1.0.4" record
ant__ has joined #yocto
stwcx has joined #yocto
<stwcx>
I have a philosophical question. I did all the override syntax changes for openbmc and we've been running with that for a few weeks but people have asked me about the inconsistency in our own bbclasses and I'm trying to understand when something is an "override" and when something is a separate variable.
<stwcx>
Why did RDEPENDS/FILES/SYSTEMD_TARGETS as examples go with override but VIRTUAL-RUNTIME uses underscore? It isn't obvious to me.
<stwcx>
`SYSTEMD_SERVICE` I mean.
<fray>
My opinion (I was overrules) was FILES/RDEPENDS should have been _ and not overrides.. the actual implementation though used overrides that are specific to the task being executed..
<fray>
it's one of those things it 'could' work either way, a decision had to be made..
<fray>
for the SYSTEMD_TARGETS it probably should be using ':' syntax to match..
<stwcx>
`SYSTEMD_SERVICE` is : syntax.
<fray>
ohh, ok.. ya SYSTEMD_SERVICE, RDEPENDS:<package> etc all should be ':'..
<stwcx>
But then `LAYERVERSION_layer` is underscore when it seems like it is an override for the layer.
<fray>
again the reason is that under the hood in the middle of a task, it's adding <package> to the override and parsing it..
<fray>
LAYER.... isn't an override, this is a litteral variable referred to as: LAYERVERSION_<collection> in the code
<fray>
so I guess the official answer is probably 'it depends on the underlying implementation'
<stwcx>
Right. So the only answer is "look at the code"? :D
<fray>
unfortuantely..
<fray>
one of the growing pains of the change, but hopefully not TOO painful
<stwcx>
It isn't terrible, I just have no way to decide when looking at our bbclasses: should I make a change here or not?
<stwcx>
And I can't very consistently explain to others which way is what and why...
<stwcx>
The SYSTEMD_SERVICE is an example where the bbclass itself isn't even really using the override. It literally changed the variable name in the parsing:
<stwcx>
poky/meta/classes/systemd.bbclass: if d.getVar('SYSTEMD_SERVICE:' + pkg):
<RP>
stwcx: The VIRTUAL-RUNTIME variables are all true variables, there is no override usage, they just happen to use different cases in the variable names :/
<RP>
stwcx: the layer.conf variables are probably something we'll need to address in a different set of patches for "reasons"
<RP>
stwcx: PREFERRED_VERSION_X really should migrate to PREFERRED_VERSION:pn-
<RP>
stwcx: think of this as the first round and then we'll have to go and look at a lot of corner cases
<RP>
stwcx: I'd be interested in improving the migration guide with more info about the things that do/don't need converting as the edge cases
<RP>
rburton: with that license patch, I'm a bit worried at the license duplication :/
<RP>
rburton: e.g. GPL-1.0 and GPL-1.0-only
<RP>
I thought the later was the official SPDX form now?
Guest28 has quit [Quit: Client closed]
<stwcx>
RP: I'm looking through all our variable definitions to see if there are other ones beyond the layer and our own bbclasses that ended up not being changed. (Specifically looking at any variable we end up :append-ing.)
bps has quit [Ping timeout: 245 seconds]
<stwcx>
FEATURE_PACKAGES VIRTUAL-RUNTIME are the two that I find that aren't in our own bbclasses.
ant__ has quit [Remote host closed the connection]
<stwcx>
Here are some amusing typos I found though:
<RP>
stwcx: it is amazing that some of these typos last for so long
rewitt3 has quit [Ping timeout: 252 seconds]
rewitt3 has joined #yocto
<fray>
hopefully I didn't cause any of those.. :) (I've been known to typo occasionally)
rewitt3 has quit [Ping timeout: 244 seconds]
rewitt3 has joined #yocto
rewitt3 has quit [Ping timeout: 245 seconds]
cocoJoe has quit [Quit: Client closed]
tepperson has quit [Quit: Client closed]
<stwcx>
I feel like I always do this wrong. Is meta-openembedded openembedded-devel@lists.openembedded.org or is it openembedded-core or neither?
<stwcx>
Oh. It is a bunch of sub-layers.
<RP>
does anyone here understand npm and our fetcher? freajs appears to have disappeared and our npm tests fail :(
<RP>
stwcx: it is the -devel list fwiw
jwillikers has quit [Remote host closed the connection]
<stwcx>
Thankfully meta-networking had a MAINTAINERS file with enough info in it. I realized I had meta-openembedded as a whole cloned, but it seems like `git-send-email --relative` did the needful.
nateglims has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
<RP>
JPEW: since I need to sort these patches somehow, I've added a vardepexclude in package.bbclass to see if that helps
<JPEW>
Sorry. I have them and got pulled into a meeting
<JPEW>
AFAIK, That's all it is though
<RP>
JPEW: just the one in package.bbclass? I was hoping I'd save you doing it! :)
* RP
needs to get builds running before sleeping
<JPEW>
There are 2 in create-spdx.bbclass, but the AB isn't testing that, so it can wait till later. I'll send it in a bit
<JPEW>
Start the build and get some sleep :)
florian has joined #yocto
<kergoth>
Can someone remind me the process for requesting a commit backport to a stable branch?
<kergoth>
I need something cherry-picked to dunfell
<RP>
JPEW: ah, yes. I felt I was missing something
<RP>
kergoth: post a patch with the dunfell tag or ask sakoman to cherry-pick it
<sakoman>
kergoth: ^^ yes, either is fine
stwcx has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 252 seconds]
jwillikers has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
nateglims has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<vd>
I've set DISTRO_FEATURES_BACKFILL_CONSIDERED += "nfs" but I still see nfs service failing at boot. Isn't it the way to get rid of it?
<vd>
(I used to do DISTRO_FEATURES_remove = "nfs" but it made RP mad :P)