qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
mattsm has quit [Quit: Ping timeout (120 seconds)]
mattsm has joined #yocto
jwillikers has quit [Remote host closed the connection]
<vmeson>
RP valgrind is working on fixes, I'll check on strace, elfutils tomorrow if no one gets there first.
<vmeson>
actually valgrind has a few commits that aim to deal with glibc-2.34 already on master but not released yet
<vmeson>
strace has a new releae: 5.13 that deals with some of the glibc-2.34 borkage so patch coming for that tomorrow/this week depending on how keen you are.
mihai- has joined #yocto
mihai has quit [Ping timeout: 265 seconds]
<override>
https://github.com/intel/bmap-tools gets installed as a command line tool, can someone help me understand how I run it in a python script by importing the bmaptools module (and using subprocess.run())
<override>
let me know if that makes sense..
mranostaj has quit [Remote host closed the connection]
boo has quit [Ping timeout: 256 seconds]
yates_work has joined #yocto
<yates_work>
is there a default number of cores bitbake uses to process tasks?
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
zpfvo has joined #yocto
prabhakarlad has joined #yocto
davidinux has quit [Ping timeout: 258 seconds]
vd has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
LetoThe2nd has joined #yocto
goliath has quit [Quit: SIGSEGV]
<qschulz>
michaelo: for bitbake-devel, I sent a diff on the ML as an answer to RP's original patch if that's what you were talking about? Or are you talking about yocto-docs?
<qschulz>
RP: ok this is SUPER confusing now that some are overrides and some not. I see that tlwoerner and you were talking about SRC_URI for example yesteday. What's the logic behind whether overrides are used or not?
<qschulz>
(but I guess it's going to be answered in some of the comments in the diff I sent by mail since this SRC_URI_%s SRC_URI:%s change I did was one for which I had my doubts :)
leon-anavi has joined #yocto
florian_kc has joined #yocto
<LetoThe2nd>
yo dudX
<florian>
hi all
vmeson has quit [Ping timeout: 245 seconds]
<michaelo>
qschulz: yes, I was talking about about yocto-docs :)
vmeson has joined #yocto
goliath has joined #yocto
bizulk has joined #yocto
<qschulz>
michaelo: haven't started working on it. Did RP run his script on it (yocto-docs) by any chance so we don't have to start from scratch?
<RP>
qschulz: the script is in oe-core so anyone can run it. I did have a test run which I could share, or re-run it
<qschulz>
RP: no manual modification on top of that script run?
<qschulz>
michaelo: There are a few _<something> which aren't overrides and shouldn't use the new syntax (since they are not overrides). The thing is, I don't know when they are overrides and when they aren't :/
<qschulz>
So I'm not sure how to review docs patch or make them :/
<RP>
qschulz: I've not got to that, no
<RP>
qschulz: you could just mark those up and we could then check?
<michaelo>
qschulz, RP: I have already run the script. That's easy but maybe you could send me a patch first (if you have time) to mark as comments the statements you're thinking about, before I run the script.
<qschulz>
I won't probably send a patch first, so please go ahead :)
<qschulz>
michaelo: I guess the first step is to commit the output of the script first
<qschulz>
maybe we can share taskload by committing changes per file?
<qschulz>
using a contrib branch or something, I don't know
<qschulz>
also just so we're clear, I've just fixed a few issues in files modified by RP in his original patch for bitbake's doc but I haven't done a whole pass on the documentation to check if there's something he missed in some other files
davidinux has quit [Ping timeout: 245 seconds]
davidinux has joined #yocto
<michaelo>
qschulz: thanks, I'll do that.
<yates_work>
mihai: truly? bitbake will auto-detect the number of cores and use them all?
jwillikers has joined #yocto
<RP>
yates_work: yes, why wouldn't it?
<RP>
yates_work: you can override it (BB_NUMBER_THREADS and PARALLEL_MAKE)
<jsandman>
Hi again. I am getting this error still: "failed with exit code 'setscene whitelist'" when building the extensible sdk for my target machine. I tried runing a plain core-image-minimal using MACHINE=qemuarm and it worked ok but when trying for my own MACHINE I always get that at random tasks. I tried removing al the sstate_cache dire but did not
<jsandman>
work
<jsandman>
I have no idea where to start looking for that error.
mranostaj has quit [Ping timeout: 258 seconds]
<RP>
jsandman: that error is a nightmare to debug :(
<yates_work>
RP: i guess that's no great feat. i just feel like i must vette everything that passes the optic nerve into the brain...
<RP>
jsandman: it means that the computed hash in the eSDK isn't matching what it was originally locked down to during the earlier build. Sadly bitbake doesn't know why :/
<jsandman>
RP Do yo have any ideas of what things I can try to solve it? Maybe running everything from scratch may help re-generating those hashes?
jwillikers has quit [Remote host closed the connection]
<RP>
jsandman: I kind of doubt that would help much. I'd try and get the sigdata files for the hashes that are changing and try and understand why they're changing. Something about the things the MACHINE is setting must not be entirely deterministic
jwillikers has joined #yocto
<RP>
jsandman: when you build that machine normally in a build are there recipes which always rebuild?
<jsandman>
RP No that I know of. I just tried with the image build and got "Attempted 5007 tasks of which 5007 didn't need to be rerun and all succeeded." That is usually the case if nothing changes
<RP>
jsandman: right, it would have just been a much easier issue to debug if it were that
<RP>
jsandman: this issue with the eSDK really bugs me, I just wish I knew how to explain how to debug it in a sensible way :(
<jsandman>
RP Yeah. Painful one. I have no idea where to start. I really appreciate any comment on this so thank you very much ;)
<RP>
jsandman: is it a public machine layer?
<jsandman>
Nope. This Machine configuration is part of this closed layer :S
<RP>
jsandman: I think if you enable that, the stamps dir should have basehash info in it and if it is the basehash component of the hash that varies, that would help
<RP>
you'd have to figure out where the stamps dir esdk was using was
<RP>
and compare to your main stamps dir
<RP>
jsandman: what I can't tell is whether your base hashes are varying or whether it is the second task components that vary
<jsandman>
Ah great. That seems helpfull. I'll try to play with that and see if I can gather some info. How am I supposed to enable that code?
<RP>
jsandman: uncomment it
<RP>
jsandman: trying to improve this is something I've wanted to do for a long time
<jsandman>
Ah ok. Sorry I missed the line bit :D
<wyre>
hi guys, I'm following this answer https://stackoverflow.com/a/37366507/6723042 to make a custom device tree, I'm following the Option two: Manual, the problem right now is that bitbake cannot generate the wic image because it cannot stat my custom .dtb file, maybe I need to add the .dts file to the Makefile like in here https://stackoverflow.com/a/61618880/6723042
<wyre>
is this right?
<wyre>
i.e. do I need to patch the Makefile?
<jsandman>
RP Thank you! I'll be trying that and I'll come back with what I see.
<qschulz>
wyre: yes
mranostaj has joined #yocto
<RP>
hmm, I think I may have figured out how to make devupstream work with native recipes. rburton might like that
<wyre>
qschulz, where should I place the patch file? https://bpa.st/UOMA apparently I could place into linux/linux-engicam/ because this dir has prepended to FILESEXTRAPATHS, right?
<qschulz>
wyre: yes
<JaMa>
RP: I see your IMAGE_TYPEDEP in master-next, thanks, next var should probably be CONVERSION_CMD to match with IMAGE_CMD behavior
<JaMa>
RP: and there is a missing quote in master-next branch in imagevars = ["IMAGE_CMD", "EXTRA_IMAGECMD", IMAGE_TYPEDEP"]
xmn has quit [Ping timeout: 256 seconds]
<RP>
JaMa: will fix, thanks
vd has joined #yocto
<RP>
JaMa: and then COMPRESS_CMD. I'll do those as well
<JaMa>
RP: found another maybe interesting case, VIRTUAL-RUNTIME_com.webos.service.flowmanager_armv4 isn't replaced because of dots before the override, will adjust the script for meta-webosose where I see many cases like this, then re-run it on oe-core/meta-oe to see how common it is
<wyre>
oh, the problem was I was appending .dts instead .dtb to KERNEL_DEVICETREE var 😁
<RP>
JaMa: ah, interesting. I didn't know dots worked in variable names :/
<RP>
JaMa: I've sent a patch for CONVERSION_CMD and dropping COMPRESS_CMD
frieder has quit [Ping timeout: 268 seconds]
<JaMa>
RP: thanks
<JaMa>
RP: the dot might be also in package name, I've just noticed it in RDEPENDS:gstreamer1.0-meta-base:remove as well
<RP>
JaMa: ah, right, that will be why we support it
frieder has joined #yocto
BobPungartnik has joined #yocto
rpcme has joined #yocto
BobPungartnik has quit [Quit: Leaving]
<rpcme>
Is layercheck broken on master? It's weird that I'm getting an error 2 but nothing in the log itself shows there's an actual issue- maybe the commandline for layercheck is not correct but "it was working" before https://gist.github.com/rpcme/299249de4eb71295323a17ef4851e4ba
boo has joined #yocto
<rpcme>
Perhaps it is buried in the log somewhere. I'm running it thru an automated build system so if I can repro local that might help
<Alban[m]>
Is there some guidelines / best practices on how to choose a layer priority?
<LetoThe2nd>
Alban[m]: best practise: don't use priorities :)
<Alban[m]>
But openembedded-core and most layers define one
<LetoThe2nd>
Alban[m]: and bitbake-layers create-layer will also set one for your newly created layer. but if you rely on the priorities for some dirty trick to work, it's... a not-best practise.
<LetoThe2nd>
hence, just leave as-is.
<Alban[m]>
But if I override a file provided in one layer in another one the priority select the file used, or is that already a "dirty trick"?
<LetoThe2nd>
i think the standard values from poky/oe-core and layer creation will have that covered?
<Alban[m]>
so you mean that it is recommended to always use the default value, but what is the default value?
<LetoThe2nd>
not "always" by defintion, but "stick to it until a different need actually arises"
<qschulz>
Alban[m]: depends of the order in FILESEXTRAPATHS and the name of your directory and subdirectory where your file resides
<qschulz>
but yes, that could be a reason for a higher priority
<qschulz>
though there are other ways to do it, use overrides or a "stronger" override for example
<Alban[m]>
right, i got confused here. What I'm hitting currently is that I need to backport psplash from dunfell to zeus. I have a layer I use for backporting but both recipe have the same version, just different revision, so here only the priority is useful.
whuang0389 has joined #yocto
<qschulz>
Alban[m]: PREFERRED_VERSION_psplash in one of the configuration file ;)
<qschulz>
+s
<RP>
rpcme: I suspect it was the new dependencies change
<rpcme>
RP: thank you - will look to tweak the command line.
fitzsim has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
<Alban[m]>
qschulz: That would also be a solution, although I would prefer a more generic one. I'm just surprised that the layer priorities don't seems to be clearly defined or documented.
<Alban[m]>
qschulz: I mean regarding the values to use, not what it does
<wyre>
maybe is not enough just removing the gpio_export node 🤔
<qschulz>
Alban[m]: it's an integer so not sure to understand the question?
<qschulz>
wyre: very likely that you're still booting the old device tree
<Alban[m]>
why has oe-core 5., what would be the recommended value for a bsp layer, for a distr layer, and so on
<qschulz>
you'll need to do modifications in your u-boot logic to boot the correct one
<LetoThe2nd>
Alban[m]: i would say "usually the lowest possible", but... it depends.
<Alban[m]>
depends on what?
<LetoThe2nd>
Alban[m]: but then, thats what i meant by: if you rely on the priorities to make your build work, you're in trouble anyways.
goliath has quit [Quit: SIGSEGV]
<wyre>
qschulz, I've flashed the NAND with the new dtb so ... could be the old device tree being loaded?
<Alban[m]>
why?
<LetoThe2nd>
Alban[m]: first and foremost, on your layer stack.
dgriego has joined #yocto
<LetoThe2nd>
Alban[m]: because a) layers are meant to be shared and reused b) your way of using a layer might be different from somebody elses.
<qschulz>
wyre: cat /proc/device-tree/* to check the device tree being used
<wyre>
yes, sorry, it was my fault
<qschulz>
not directly this command but files in those dirs/subdirs
<LetoThe2nd>
so if you're imposing a hard rule on the priority structure, for example "middleware takes precedence over BSP", then you define that one use case is better than the other.
<wyre>
I was pasting the normal dtb as imx6ull-joifi.dtb in the tftp
<wyre>
so sure, I was flashing again the very same 😥
<Alban[m]>
LetoThe2nd: let say I have a backport layer, shouldn't it make sure that its recipes override the ones from oe-core?
<LetoThe2nd>
Alban[m]: and if you stick to the defaults, it will have right from the start, or did i get that wrong?
<Alban[m]>
well some recipes, like psplash, didn't increased their version between oe-core releases
<Alban[m]>
so which version is taken depend on the lexical order of git git revision, so it is basically random
<wyre>
now its working qschulz 😁
<wyre>
thank you
<LetoThe2nd>
Alban[m]: what is the difference then? because then a) theres either a bug (internal version change without recipe version bump) or b) backporting an unchanged version doesn't make much sense to me.
<Alban[m]>
dunfell has version 0.1+gitAUTOINC+0a902f7cd8 and zeus has 0.1+gitAUTOINC+2015f7073e
<Alban[m]>
so on version compare the zeus version win, although it is older
<LetoThe2nd>
Alban[m]: and what is the PR, respectively?
<wyre>
what are those fixed regulators for? 🤔
<wyre>
I'm wondering if I could remove them also
<qschulz>
Alban[m]: not random, depends on BBFILE_PRIORITY and the order in which the layers are listed in global BBLAYERS in bblayers.conf
<Alban[m]>
both have r15
<Alban[m]>
random if both layer have the same priority
<qschulz>
wyre: regulators are for power, so you might disable power for some things if you do it. Sometimes (often) they are required
<LetoThe2nd>
Alban[m]: but in that case i would call that a bug: the recipe has been modified, but no PR increase.
<qschulz>
Alban[m]: no, then it depends of the order in BBLAYERS
<Alban[m]>
random because the git revision hash is basically random
<wyre>
qschulz, you mean for internal things in the SoM? or in the carrier?
<qschulz>
wyre: both
<LetoThe2nd>
hah well ok, git is injected into PV then... problematic.
<LetoThe2nd>
i might be wrong, but technically i would call the recipe buggy.
<Alban[m]>
it looks like many recipe in oe-core are doing exaclty this
<RP>
Alban[m]: in the final packages, AUTOINC should become a number which is increased by the PR server
<Alban[m]>
does that help if the wrong recipe is parsed?
<LetoThe2nd>
RP: but if PR isn't being incremented, then?
<RP>
LetoThe2nd: is the PR server enabled?
<LetoThe2nd>
RP: can that be assumed as given for any build based on oe-core?
<RP>
LetoThe2nd: I don't think we default to that being on by default any more
<Alban[m]>
but wouldn't it need to build both version to then select the correct one?
<LetoThe2nd>
Alban[m]: parse, but not build.
<LetoThe2nd>
RP: but them bumping SRCREV without bumping PR shouldn't be allowed? or am i missing something stupid?
<Alban[m]>
AUTOINC doesn't seems to come into play at parse time
<RP>
LetoThe2nd: it is only an issue if trying to do package manager upgrades on target
<LetoThe2nd>
RP: then we are obviously now seeing a new case - what happens if both versions happen to be present in the metadata?
<LetoThe2nd>
i *think* just slapping on a priority is going to make it fly, but it feels wrong (at least to me)
<Alban[m]>
setting the priority works, raising PR doesn't
<LetoThe2nd>
then it's very possible that my brain has a massive misconception of things there :-(
<Alban[m]>
all this wouldn't be a problem if psplash version had been increased between oe-core relases
<LetoThe2nd>
Alban[m]: well many problems stick to a version for a long time and only git bump, so thats not exactly a good argument for the generic case.
<LetoThe2nd>
problems = projects.
<JPEW>
LetoThe2nd: I liked the original wording better :)
<LetoThe2nd>
JPEW: hehe
<Alban[m]>
sure, but that's probably the reason why this didn't showed very often
<Alban[m]>
so currently for a backport layer to work properly it need to have a priority higher than all the layer it wants to override
<LetoThe2nd>
Alban[m]: which it will already have in the vast majority of cases without even thinking about it.
<LetoThe2nd>
so from my POV: this is a corner case which seems to be handled improperly at the moment technically, but without much trouble being caused due to good choice of defaults.
<Alban[m]>
I would be nice if these "good choice of defaults" were documented somewhere. The current doc is barely understandable:
<Alban[m]>
A larger value for the BBFILE_PRIORITY variable results in a higher precedence. For example, the value 6 has a higher precedence than the value 5. If not specified, the BBFILE_PRIORITY variable is set based on layer dependencies (see the LAYERDEPENDS variable for more information. The default priority, if unspecified for a layer with no dependencies, is the lowest defined priority + 1 (or 1 if no priorities are defined).
<Alban[m]>
This doesn't help at all in choosing a correct value
<LetoThe2nd>
Alban[m]: feel free to send improvements! :)
<Alban[m]>
I would need, beside time, to know what the "good defaults" are to be able to do that
<LetoThe2nd>
Alban[m]: i told you. essentially, an hour ago.
<LetoThe2nd>
generated == uses the default value, obviously
<Alban[m]>
So 6 is the recommended default?
<Alban[m]>
but meta-python for example has 7
<LetoThe2nd>
Alban[m]: 6 is the default value for a newly created layer. if that qualifies as "recommended", i can't judge.
<Alban[m]>
that
<Alban[m]>
that's why I asked for recommendation before, the answer was "don't set it"
<LetoThe2nd>
*sigh*
<LetoThe2nd>
no. i said, create your layer with bitbake-layer layer-create, and leave as is.
<LetoThe2nd>
(at least i'm pretty sure i did)
<LetoThe2nd>
anyways - i think there is little more to say. we have found, identified and discussed a corner case. action needed? questionable. a hard recommandation? probably won't be. so, thats it from my side unless something really new is brought to the table now.
<Alban[m]>
action needed would be better documentation, but that's not possible as long as there is no clear explanations on how to select a "good" value
<qschulz>
Alban[m]: because the good value depends on the context. what we would probably welcome in the documentation would be that bitbake-layers create-layer provides a default (and should actually be used to avoid user errors/typos). I'm not sure it makes much sense to define a "good default" since it depends on context and which layers you include
<Alban[m]>
I understand that, but some general advice would be helpful. Telling ppl to just blindly use a tool doesn't help those that have to deal with existing setups or want to understand
jmiehe has joined #yocto
<qschulz>
if the existing setup isn't doing what you want, you need to increase/decrease the priority as explained in the documentation of BBFILE_PRIORITY. If you want to understand what's going on, looking at the priorities of all layers and the documentation of BBFILE_PRIORITY should help. If you are creating your own layer, use bitbake-layers create-layer which provides some default. Then go back to the
<qschulz>
beginning of this message if it does not work the way you want
goliath has joined #yocto
<qschulz>
if there could be better wording of the documentation of the variable is debattable but I'm not sure there's a way to define a 'good value'/general advice
Tokamak has joined #yocto
rpcme has quit [Quit: Client closed]
rpcme has joined #yocto
<Alban[m]>
qschulz: thank you
bizulk has quit [Quit: Client closed]
zpfvo has quit [Remote host closed the connection]
Tokamak has quit [Ping timeout: 258 seconds]
florian has quit [Quit: Ex-Chat]
frieder has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 258 seconds]
leon-anavi has quit [Quit: Leaving]
whuang0389 has quit [Quit: Client closed]
sakoman has joined #yocto
vd has quit [Quit: Client closed]
<RP>
vmeson: since the strace upgrade seems simple, I've queued an upgrade for testing for that
<khem>
should new override seprate work in this case ?
<RP>
khem: no, that needs to be converted to :
<RP>
khem: well, yes, if you convert it, it will work
<khem>
right ok
<smurray>
RP: I seem to be having some issues getting either the python "-X dev" or PYTHONDEVMODE=1 env variable down into bitbake child processes w/o ending up overly invasive and ending up in target build env, any suggestions?
<RP>
smurray: I think the question is why bitbake processes? Things started by the server or by the worker?
<smurray>
RP: there's some asyncio debugging enabled with it that I want to see on both the server and hashequiv/prserver children
<smurray>
RP: there's also PYTHONASYNCIODEBUG=1 as a hook for that, but it looks like dev mode also makes debug logging the default for the logging module w/o having to hack that
<RP>
smurray: those are started from the server so it sounds like you want bitbake's server started with that?
<smurray>
RP: I tried hacking it into the bitbake-server wrapper but it didn't seem to take effect that way
<smurray>
RP: I then wrapped python3 with a script, but that ends up too invasive
<RP>
smurray: hmm. It should :/
<smurray>
RP: I can try again, maybe I missed something
<smurray>
RP: semi-related, is there a hook for changing the logging level other than passing -d to bitbake?
<RP>
smurray: you can pass a custom log levels definition
<smurray>
RP: okay, I guess I'll pick apart the oe-selftest that fails and work out running it by hand so I can try that
<RP>
vmeson, khem: I pulled in a few valgrind patches and tried a build
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
<smurray>
RP: do the bb.debug/note/etc. messages go through the logging module at this point, or do they use a separate mechanism altogether?
<RP>
smurray: they should go through it
<smurray>
RP: okay, trying to wrap my head around where messages are ending up
<RP>
smurray: our logging needs work, its a mess
<RP>
smurray: I sometimes resort to writing things to a file
amitk has quit [Remote host closed the connection]
<smurray>
RP: I've instrumented a bunch with bb.note, but I'll have to try to correlate with multiple files or hack the config json if I can get this other stuff enabled
<RP>
smurray: fair enough, just mentioning what I sometimes resort to
<smurray>
RP: yeah, I might end up there ;)
<rpcme>
RP: just to let you know I'm back in the green on the yocto-check-layer. It was the dependencies for sure. Takes more than 1h to run on 2 VCPU so I bumped it up to 72 VCPU to finish in 11 minutes. That might be a reasonable duration for PR checks as well.
<moto-timo>
there are some commented out settings in local.conf.sample that will also need the new override syntax conversion such as PACKAGECONFIG_append_*
amitk has joined #yocto
<RP>
rpcme: that code does metadata parses which can take advantage of cpu cores
yates_work has quit [Remote host closed the connection]
Tokamak has joined #yocto
wing0 has joined #yocto
rfried has joined #yocto
amitk has quit [Ping timeout: 258 seconds]
vd has joined #yocto
stwcx has joined #yocto
<stwcx>
Hello. I'm trying to build an image using hardknott and running into a problem that I have no idea how to debug. Uninative vs sysroot-native is something I've not really dug enough into before.
<stwcx>
| re2c: .../tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by re2c)
<stwcx>
My system has GCC 11, and it seems like re2c was built against my system libstdc++, but...
<stwcx>
When it gets used during the build of `ninja` it ends up using the libstdc++.so.6 out of the uninative.
<RP>
stwcx: are you using the latest uninative?
<RP>
stwcx: it is expected it would switch to use uninative as that is how it works
<stwcx>
RP: I think the "latest" that comes with hardknott, yes.
<stwcx>
Shouldn't re2c have built with the uninative libstdc++ then too?
<RP>
stwcx: it builds against the host, then switches at install time for 'reasons'
<stwcx>
RP: checking that I haven't messed something up with that uninative.inc.
<stwcx>
Ah, I don't have that uninative bump. It takes me 3 hops to get subtree updates with the build that we have, so ... :(
<RP>
stwcx: hence my question :) that would explain it
<stwcx>
> it builds against the host, then switches at install time for 'reasons' --- this is interesting to know. For some reason I thought everything always built against the uninative libraries.
<RP>
stwcx: uninative doesn't ship with headers and if it did, it gets very confused with the host's headers. It is much easier to link against the host, then switch
<RP>
It just means the uninative needs to be equal or newer than the host
roussinm has joined #yocto
<stwcx>
Sorry for the distraction. It is too bad the whole #freenode bifurcation happened. #openbmc went to Discord instead so I don't really log in here to IRC anymore.
<RP>
it is supposed to detect and error about that but detecting all the versions of gcc/glibc can be tricky
<RP>
stwcx: that whole business is rather sad :(
rpcme has quit [Quit: Client closed]
<stwcx>
"uninative needs to be equal or newer than the host" ... this is partially surprising for doing ancient builds. We still have some images that we use Rocko as the base for. I've been lucky thus far that the crops/poky Docker image works for me.
<stwcx>
Anything Rocko I use that crops/poky image but anything newish I use my host.
<RP>
stwcx: the nice thing is that newer uninatives tend to work fine with older releases
<stwcx>
So in theory we could just backport a change to the checksums and pick up a new uninative?
<RP>
stwcx: in theory yes
<stwcx>
Sounds good. I'll keep that in the back of my mind.
<stwcx>
Thanks much for your help and explaination.
<RP>
stwcx: np, nice to have an easy answer to something :)
<smurray>
RP: I think I have a theory now, during PR export the code in prservice.py creates a connection and caches it in the datastore. With the rework as it is ATM, this means every parsing process doing export calls uses the same asyncio loop, which eventually splodes...
<vd>
if I want to add the "foo" package to some-image-recipe from a multiconfig
<smurray>
yes, barring the change in override syntax in latest master
<smurray>
it'd be IMAGE_INSTALL:append:pn-some-image-recipe now, I believe
<vd>
sweet!
<vd>
I guess it'll fail or warn when I'll bump, no big deal.
<vd>
I have a complex set of stacked images, and appending packages this way to the images from the same multiconfig file is quite neat
<vd>
it gives a complete view of the customization for a specific build
rpcme has joined #yocto
vmeson has joined #yocto
florian_kc has joined #yocto
<stwcx>
I'm learning about this new override syntax today too. :/ Since there is no backwards compatibility for the old _ syntax that means it is pretty much impossible to have a single metalayer support two different branches now?
prabhakarlad has quit [Quit: Client closed]
<rpcme>
that's right - that is why layer maintainers had to change the layer compat
wing0 has quit [Quit: WeeChat 3.1]
<stwcx>
That's really ugly.
<rpcme>
I was very unnerved about the change on Monday but after working with it a couple days I'm liking it a lot. Although we're maintaining 4 releases and breakfix on four more, I'm OK with it
<stwcx>
Unfortunately we maintain a single tree and swap out the poky stuff depending on which system we're targeting.
<rpcme>
Yah we tried that but there were too many nuances requiring conditions, it made it worse to maintain and hard to tell what was bitrot or not. Then I became a YP release branch convert...
boo has quit [Ping timeout: 272 seconds]
wing0 has joined #yocto
<smurray>
stwcx: there's forward compatibility in bitbake for dunfell forward, so doing the conversion in a layer that needs to support in that range forward is hopefully doable
<stwcx>
Oooh. That sounds better. So you're saying that in theory you could convert recipes that are targeting at least Dunfell and they'll work? I assume this means there is a bitbake update for them also?
<RP>
stwcx: we did backport changes to dunfell/gatesgarth/hardknott which mean the new syntax works over those releases and master
<RP>
stwcx: just realised smurray covered it :) Yes, there was a bitbake update to do that
<smurray>
RP: my phrasing wasn't great
<RP>
smurray: not sure mine is either tbh :)
<vd>
what is the recommended way to package ${DEPLOY_DIR_IMAGE}/some-image-recipe.img into the rootfs?
<smurray>
RP: I'm pretty sure now what I mentioned above is the issue with the prservice selftest hangs with the rework, same issue JPEW's change last week addressed but in a different context
<stwcx>
I must be misunderstanding this:
<stwcx>
> Supporting mixed syntax isn't possible, it is only feasible to have
<stwcx>
> one internal representation of overrides.
<stwcx>
So if you've backported the changes to bitbake, how does it know which one to use?
<RP>
stwcx: it just converts ":" into "_" in older bitbakes
EdTanous has joined #yocto
<RP>
smurray: ah, I missed that comment. That sounds like a promising lead
<smurray>
RP: the simple fix is to pull out the caching of the client connection object in meta/lib/oe/prservice.py, I'm currently debating if there's something to be gained by trying to keep that while hacking on things to delay connecting
boo has joined #yocto
<smurray>
RP: there's no obvious way to open the connection once and then reuse that connection now, since the connection is done with an asyncio call. I suspect a minor diff in export performance isn't a big deal, though...
<RP>
smurray: I suspect it would be best to pull it out and then we can look at performance again if it is an issue
<smurray>
RP: yeah. I don't see a way with asyncio to reuse an open socket, but I could be missing something
vd has quit [Ping timeout: 246 seconds]
<smurray>
RP: I'll bang on it in a test loop for a while before declaring victory. I start some vacation tomorrow, but I can pick at it a bit remotely and try to get an updated patch set out in the next few days
<smurray>
RP: one of the changes in my stack ATM is from JPEW, it'll need to go in IMO
dkl has quit [Remote host closed the connection]
dkl has joined #yocto
<RP>
smurray: it'd be great to get this in and resolved!
<smurray>
RP: you're not alone in that thinking ;)
ant__ has joined #yocto
<RP>
smurray: I'm just wary as the last thing I need is another weird autobuilder intermittent issue!
<smurray>
RP: definitely
<smurray>
RP: I think with JPEW's change to move the loop creation for the server side and this fix it'll hopefully hold up now
<RP>
smurray: it sounds promising
<JaMa>
RP: I've reproduced that systemd-boot issue on one of my hosts, it looks like it uses hosttools/ld.bfd when available instead of ld.bfd from binutils-cross
<RP>
JaMa: ah, that sounds a bit nasty but good to know the issue
<JaMa>
RP: I will use ${BUILD_PREFIX}ld.bfd which should match with what ${LD}[0] has except the .bfd suffix
<RP>
JaMa: sounds good
<RP>
vmeson, khem: just to keep up to date, the list of valgrind issues with reduced with backported patches. I opened a bug to keep track from here
<RP>
and there is an elfutils patch available I can try testing
florian_kc has quit [Ping timeout: 240 seconds]
<moto-timo>
for the python3-scons upgrade to 4.2.0 I tested a build of serf (the only component in core that inherits scons) but if anybody depends on it for other things please test
<stwcx>
Has any issues with a high amount of "pseudo aborts" been reported lately? I'm seeing them pretty frequently with simple package rebuilds.