Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
frieder has quit [Remote host closed the connection]
kranzo has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
nemik has joined #yocto
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
Schlumpf has joined #yocto
selff has joined #yocto
gsalazar has joined #yocto
<RP>
jclsn[m]: yes
tomzy_0 has joined #yocto
selff has quit [Quit: Client closed]
selff has joined #yocto
tnovotny has joined #yocto
selff has quit [Ping timeout: 252 seconds]
xmn has quit [Quit: ZZZzzz…]
* RP
notes that eSDK is broken and oe-selftest hangs with his git changes :(
<Saur[m]>
RP: Have you considered patching git-native instead to disable the test?
<RP>
Saur[m]: no, since we use git from the host in most cases, not git-native
<Saur[m]>
Hmm, ok. That's true...
florian has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<kanavin>
RP: I have a task from Siemens to make eSDK 'really nice', so could work directly on that
mabnhdev2 has quit [Ping timeout: 252 seconds]
<kanavin>
just trying to wrap up some package updates
<RP>
kanavin: In yesterday's members meeting, "reinventing" eSDK was one of the things we talked about as a way to trying to improve project usability. The technology underneath is good, the implementation and user interface to it isn't
<RP>
kanavin: I'm seeing if I can reproduce the eSDK failure locally atm
<kanavin>
RP: I'm going to start by studying what there is and how it works first
<qschulz>
RP: michaelo: I'm seeing an issue with default and 4.0 pages (same pages but different URL subpath) being reported as obsolete
<qschulz>
RP: yay \o/ thanks halstead for the docs fix :)
<RP>
qschulz: cool :)
ptsneves has joined #yocto
<Saur[m]>
RP: In an anonymous Python function, is there some easy way to get the name of the file it is part of (e.g., if it is in a bbappend, is there some way to get the name of that bbappend)? I would like to use it in an error message to help the reader to know where the error is coming from.
<RP>
Saur[m]: FILE sometimes indicates that
<ptsneves>
Saur[m] that is a good request. I am also curious if this possible. The fact that bitbake always reports the .bb and not the bbappend is nightmarish for most people
<RP>
Saur[m]: it isn't easy though as it would mean updating the datastore on every file change and invalidating the data store caches
<ptsneves>
is there any plan to report .bbappen in the future?
<RP>
ptsneves: the key question is report where and when. You mean a parsing failure?
<ptsneves>
yes. that would be good the first aspect. The other aspect would be to report in which bb or bbappend the command that failed comes from
<Saur[m]>
Unfortunately it seems that ${FILE} doesn't expand to anything (while in the bbappend at least). I tried setting `FOO_FILE := "${FILE}"` just to see.
<ptsneves>
I think we already have information about that, as when running with -e we have the parsing changes separated by where they came from
<RP>
ptsneves: very very hard to do reliably :(
<RP>
ptsneves: imagine a do_install set in the main .bb which the bbappend does do_install:append to
<qschulz>
ptsneves: we have that for variables but not tasks for example
<RP>
Saur[m]: perhaps I removed that as it wasn't accurate :/
<RP>
Saur[m]: looking at the code, FILE is set but probably not in the append
<Saur[m]>
RP: No worries. I don't expect this error to more or less ever trigger so grepping for it in the rare occasion it does is fine.
* RP
can fix eSDK with the git intercept but it is horrible
<qschulz>
Saur[m]: I'm surprised this didn't work?
<qschulz>
because THISDIR (which is used in bbappends!) is derived from FILE
<Saur[m]>
Duh, it actually worked as it should. It was just me forgetting that `${FOO}` isn't expanded in Python code.
<RP>
qschulz: what bothers me about the docs is that we really want to show the 4.0.99 docs on the main page. Otherwise the 4.0 migration notes aren't there in full, no release notes
<qschulz>
RP: I agree on the issue, disagree on the solution :)
<RP>
qschulz: your solution would be?
tomzy_0 has quit [Quit: Client closed]
<qschulz>
the issue we have is that we have migration docs for a given version only from older versions
<RP>
qschulz: oh, this is the move them to the transition branch?
<RP>
then we ship the release with no inbuild transition doc :(
<qschulz>
RP: yes that's what I had in mind
<qschulz>
RP: yes, but at the moment, older releases do not even point to newer migration manuals
<qschulz>
i.e. dunfell does not even have this page
<RP>
qschulz: that is going to be a bigger discussion and more work
<qschulz>
yes
<RP>
right now we have a 4.0 release due out and the website is poor
<qschulz>
I don't know how to fix the inbuild migration notes atm honestly
<qschulz>
long term I mean
<RP>
we need to get the docs on the main page right now
<qschulz>
RP: we have hooks for adding patches to releases
<qschulz>
in yocto-autobuilder-helper
<RP>
qschulz: we want to patch in the set of 12 patches or whatever it is?
<qschulz>
the question I have is why we tagged a commit for yocto-4.0 that was clearly not proper for 4.0 ?
<RP>
qschulz: because nobody can get me the docs changes by the initial build date?
<qschulz>
(probably workflow or timing "issues"/constraints)
<RP>
If I blocked the release build on the docs changes we'd just never have a release :(
<RP>
qschulz: I wish we had people able to spend the time needed to work all this out and design a nice process which solved every problem. We don't :(
<qschulz>
RP: I'm sadly too much aware of the issues we have with lack of time and contributors :/
<qschulz>
RP: coming up with the list of requested patches and sending something for the autobuilder real soon
<RP>
qschulz: One other idea before you do that
leon-anavi has joined #yocto
<RP>
qschulz: In the drop down, perhaps we should have "Unstable (dev), 4.0 (latest), 4.0, 3.4 (latest), 3.4.3, 3.1 (latest), 3.1" ?
<RP>
with "latest" going to the .99 versions?
<RP>
qschulz: I'm thinking out loud
<qschulz>
RP: this does not fix the issue with the default page not showing the correct migration manual
<RP>
qschulz: it would if the default page went to 4.0 (latest)
<qschulz>
i don't think it'd be easy, because currently we just use the latest tag as default page
<qschulz>
we'd have to figure out which branch is the latest
<qschulz>
from the info we get from git
<RP>
qschulz: we have a list we can use though!
<qschulz>
not in the autobuilder right now?
<RP>
qschulz: in set_versions.py it has activereleases = ["kirkstone", "honister", "hardknott", "dunfell"
<qschulz>
RP: there are two places where changes need to be made
<qschulz>
in yocto-docs for the switchers.js
<qschulz>
for the dropdown
<qschulz>
haven;'t looked into that yet but gut feeling is it's an ok change
<qschulz>
(in terms of time to spend)
<qschulz>
the other one is how the autobuilder run-docs-build knows which branch to use as default page
<RP>
qschulz: We make run-docs-build get the data from set_versions.py?
<qschulz>
basically trying to get the one branch which contains the last commit
<qschulz>
excluding master and master-next
<qschulz>
the long term plan being to remove this once we agree on how to handle migration manuals
<qschulz>
yours is ok too, I can write a proper commit if you want
<qschulz>
just lemme know
<RP>
qschulz: This is basically to patch things up for release until we can get a better solution and improve on it
<RP>
qschulz: I leaning towards mine simply as it has hopefully less to go wrong?
<qschulz>
RP: agreed.. whatever floats your boat then :)
<qschulz>
RP: mine does not require a change in yocto-docs that's all :)
<qschulz>
RP: wondering if you cannot have shell run the output of "git show master:documentation/set_versions.py"?
<qschulz>
in which case no need to git checkout and the whole thing with keeping the local git clean afterwards
<RP>
qschulz: haha, interesting thought
* RP
is trying to avoid being "too clever"
Schlumpf has quit [Ping timeout: 252 seconds]
<qschulz>
RP: where is the fun in that :D
<RP>
qschulz: we can save that for a later patch ;-)
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
kranzo has quit [Quit: Client closed]
<RP>
qschulz: I sent it to the lists but pushed it. Lets see what that does
tomzy_0 has joined #yocto
<qschulz>
RP: python -c "$(git show master:documentation/set_versions.py)" getlatest
<qschulz>
FYI, that's what I could come up with
<RP>
qschulz: if that works we can update to that
<RP>
qschulz: feel free to send a patch and michaelo can process in due course. I want to see if the docs look right and we can release :)
<qschulz>
RP: I don't want to spend time on things I believe will be removed at some point :) it was just a "challenge" for me to figure out if it was possible :)
pgowda_ has joined #yocto
<RP>
qschulz: we may be able to use this tricky more widely...
<RP>
but I understand
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
kranzo has joined #yocto
<rburton>
today' favourite typo is 'farktoot farks'
<rburton>
typod the typo. 'farktoot farts'
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
goliath has quit [Quit: SIGSEGV]
<RP>
rburton: nice :)
<RP>
qschulz: site updated. "4.0.999" isn't great but better to have the migration guide complete on the front page
<qschulz>
RP: I agree
wkawka has joined #yocto
stanf has joined #yocto
argonautx has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]
leon-anavi has quit [Quit: Leaving]
leon-anavi has joined #yocto
ecdhe_ has joined #yocto
stanf has quit [Quit: Client closed]
ecdhe has quit [Read error: Connection reset by peer]
dmoseley has joined #yocto
<rburton>
and now i discover my mails have a disclaimer attached, sorry about that
florian_kc has joined #yocto
xmn has joined #yocto
Guest1431 has joined #yocto
<ptsneves>
Has anybody ever looked at the gn build system https://gn.googlesource.com/gn/? Does anybody have experience integrating it with yocto?
<Guest1431>
Hey there! II'm quite new to Yocto and I have a problem. I was building a Yocto image and while it was at the do_rootfts task, my power went out... Now when I try to build again, it gives me an error - "abort()ing pseudo client by server request..." and then it also prints some "inode mismatch". How can I fix this?
manuel1985 has joined #yocto
<kranzo>
Guest1431: did you try to remove $BUILDDIR/tmp? Should be rebuild from sstate pretty fast
<ptsneves>
Guest1431 just do bitbake <name of the recipe with the broken abort> -c cleanall
<ptsneves>
should get you going
<ptsneves>
kranzo should not need to get a whole tmp wipe
<Guest1431>
Ok I'll try that
<Guest1431>
Thanks
<qschulz>
Guest1431: are you building in rootless podman containers?
<Guest1431>
I'll be honest, I don't know what that is so... probably not
<Guest1431>
Also, will cleanall remove the sstate cache? If so, will it take long again to build everything? I'm really new to Yocto so sorry if I'm asking dumb questions
<qschulz>
yes it removes the sstate cache
<qschulz>
however, iut only removes the sstate-cache of the image recipe
<ptsneves>
Guest1431 it will remove only that recipe's state cache which is probably not relevant or unexistent
<qschulz>
not of the other package recipes
<Guest1431>
Oh okay, great. Thanks again!
<ptsneves>
if you are concerned -c clean is enough. I just said cleanall as I do not know exactly how your image is built
<thomasd123>
Bascially, a path is cut of, at some cp call.
<thomasd123>
However, If i print out the environmental variables for that task, I see that at "populate_srcipk_package() " the path is complete
<thomasd123>
I have included the error message, the content of the logfile, and the "-e" output of bitbake for that package in that paste.
<thomasd123>
Has anyone an idea, why the path can be cut of during the process? It seems that the recipe stuff is okay, since the "-e" output of bitbake seems to be sane.
Guest1431 has quit [Ping timeout: 256 seconds]
<ptsneves>
no idea on my side. I do not know populate_srcipk_pacakge task. I guess this is TI specific
<thomasd123>
Alright, I hoped this is something from OE. Or more generic
rob_w has quit [Remote host closed the connection]
<thomasd123>
But is my guess right? I'm still a yocto noob. The content of "-e" should be executed 1:1? So for example the "populate_srcipk_package()" function should be executed as it is defined at the "-e" output?
sakoman has joined #yocto
<qschulz>
thomasd123: what is executed 1:1 is what you have in ${WORKDIR}/temp/run.do_<task>
<qschulz>
thomasd123: you might want to check the variable that is used in this task and check it with bitbake -e
<thomasd123>
Thank you very much, I'll check that
<qschulz>
and not only check the final value (which should be stripped/incomplete, but the history, to see if something smells fishy
<qschulz>
(the history is above the final value in the bitbake -e output)
<thomasd123>
Thanks for listening my nightmares ;)
<ptsneves>
the logs of the IRC are available in search engines so all was not for nothing ;)
thomasd123 has quit [Quit: Client closed]
thomasd123 has joined #yocto
Schlumpf has quit [Quit: Client closed]
wkawka has quit [Quit: Client closed]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
goliath has joined #yocto
kranzo has quit [Quit: Client closed]
thomasd123 has quit [Quit: Client closed]
<rburton>
ptsneves: there's a few recipes floating around for gn
<rburton>
ptsneves: the big problem is gn can and does change behaviour without ever being 'released'
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<ptsneves>
Yes and the projects that use it as well. I am working with https://github.com/project-chip/connectedhomeip and they basically track dependencies through the gitmodules hashes. That means they download all their dependencies and build them as part of the actual target library. It leads to long compilation times and even longer downloads due to them
<ptsneves>
not being cached in the download dir
<qschulz>
RP: can the GDoC in the Yocto Project Status be at least readable by all without a Google Account? (clicking on the link asks me to login)
<qschulz>
Status +mail
<qschulz>
ndec: maybe more a request for you?^
<LetoThe2nd>
underscores in recipe names are bad, right?
<rburton>
i'd have to check but i imagine PN=my_fancy
<rburton>
you're then relying on other bits of the stack respecting the same algorithm
<qschulz>
LetoThe2nd: wpa_supplicant is named wpa-supplicant
<qschulz>
just rename it to avoid weird stuff :)
<qschulz>
though maybe there'd be less issues now with the newer override syntax?
<rburton>
yes, but there's still the pn_pv.bb behaviour
<rburton>
just use -
<LetoThe2nd>
yeah thats my preferred solution too, but alas, wonky hw vendors...
kevinrowland has joined #yocto
<tlwoerner>
what is the output of meta-environment ?
<JPEW>
ndec & LetoThe2nd: I recorded a talk I gave to the SPDX project about SPDX in Yocto, are you the ones I need to talk to about "promoting" it?
<ndec>
yes! i've heard about that talk just a few mins ago :)
<tlwoerner>
the point of meta-environment is to create an environment file (that can be sourced) that points you to your build's sdk tools without having to build and install an sdk explicitly?
<LetoThe2nd>
JPEW: heh actually RP already poked me about it. i wanted to ask you if its public, as unlisted at the moment.
<LetoThe2nd>
JPEW: nice! I would actually like to postpone its promotion to next week or so, this week the YPS CFP ends, and OEDVM needs stage time.
<LetoThe2nd>
ndec: thoughts?
<ndec>
sure. fine with me
ptsneves has quit [Quit: Client closed]
tomzy_0 has quit [Quit: Client closed]
<LetoThe2nd>
JPEW: fine for you too?
<JPEW>
LetoThe2nd: Yep
<LetoThe2nd>
JPEW: awesome! will set myself a reminder to put it out early next week then.
<JPEW>
LetoThe2nd: Sounds good. Thanks!
florian has quit [Quit: Ex-Chat]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<kevinrowland>
Is it crazy to want to maintain Kconfig fragments _in_ my Linux or U-Boot source trees? If so, I don't think I can use the existing configuration machinery provided by `cml1.bbclass`, because it expects `.cfg` fragments to be in `SRC_URI`, and they can't be in `SRC_URI` alongside my `git://` URI because they'd be _inside_ that repository.. so they
<kevinrowland>
can't be fetched until the repository is unpacked. I hope someone is following. Just looking for thoughts, or maybe someone has done this before?
Vonter has quit [Quit: WeeChat 3.5]
manuel1985 has quit [Quit: Leaving]
kevinrowland has quit [Quit: Client closed]
<tlwoerner>
kevinrowland: i don't think that's the place where config fragments are expected to be stored. i think the assumption is that they're stored either in-layer or in a layer used for nothing else other than config fragments
prabhakarlad has quit [Quit: Client closed]
mckoan is now known as mckoan|away
hcg has quit [Quit: Client closed]
<tlwoerner>
meta-environment (i found it) seems to expect the tools to be installed in a specific location (/usr/local/oe-sdk-hardcoded-buildpath)
<rburton>
thats normally replaced iirc
<RP>
tlwoerner: oh, we must have broken it. There is an envvar we need to set
<RP>
tlwoerner: that is worth a bug
<nagua[m]>
Hello everyone,
<nagua[m]>
was taken so far is satisfactory for everyone.
<nagua[m]>
I'm currently using yocto to generate an SDK with rust-cross-canadian. The rust project that we are building with it relies on bindgen to link native libraries from the yocto sysroot. I had to do a few patches to cargo and yocto until it worked well enough for us. Does anybody else use the SDK for that? Can I start a conversation somewhere on how to upstream the changes at least into yocto? I might also need some guidance if the approach that
<rburton>
nagua[m]: feel free to send a RFC patchset to the openembedded-core list to start a discussion
florian_kc has joined #yocto
<nagua[m]>
<rburton> "nagua: feel free to send a RFC..." <- Ok, I will try to bundle everything together and send a patch.
<rburton>
nothing talks better than code
kevinrowland has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
<kevinrowland>
tlwoerner: gotcha, thank you
argonautx has quit [Quit: Leaving]
pgowda_ has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
goliath has joined #yocto
<kergoth>
Hmm, considering taking on the layer setup and configuration future directions development task.
florian_kc has quit [Ping timeout: 240 seconds]
<tlwoerner>
RP: oh, there is an SDKPATH variable that is set to /usr/local/oe-sdk-hardcoded-buildpath by default
<tlwoerner>
so i guess i have to set SDKPATH before building
<kergoth>
relocation is supposed to fix the sdkpath in setup environment, but you shouldn thav eto ajdust SDKPATH to change the default install path, you want SDKPATHINSTALL or so
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<RP>
kergoth: this is using meta-environment in an existing build
<RP>
tlwoerner: I think we should just be setting SDKPATH to the right value when the script is generated
<RP>
tlwoerner: I guess the challenge is there isn't a proper non-recipe sysroot any more
<RP>
tlwoerner: perhaps we should display a message telling the user they need to set SDKPATH? :)
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
whuang0389 has joined #yocto
goliath has quit [Quit: SIGSEGV]
florian_kc has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
prabhakarlad has joined #yocto
whuang0389 has quit [Quit: Client closed]
<JPEW>
tlwoerner: Whats Abstract vs Description?
sakoman has quit [Quit: Leaving.]
florian_kc has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
wesm has joined #yocto
<moto-timo>
JPEW: I used Abstract for the usual "short blurb" that quickly summarizes the talk... I used Description to add some more details, more verbosity.. haven't used Notes yet
<moto-timo>
JPEW: you can go back and look at the phosh one from 2021.11
* moto-timo
very happy that d.getVarFlags returns a dict and that d.getVarFlag exists... for my evil mad scientist usage completely not as intended
<RP>
moto-timo: it also optionally takes a list of variables to expand as the expand parameter fwiw
<moto-timo>
RP: even better! (I've never really looked at varFlags before for some unknown reason)
mvlad has quit [Remote host closed the connection]
kevinrowland has quit [Quit: Client closed]
amahnui1 has quit [Quit: Connection closed for inactivity]