dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
alimon has joined #yocto
alimon has quit [Client Quit]
alimon has joined #yocto
xicopitz[m] has joined #yocto
Tokamak_ has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
goliath has quit [Client Quit]
jpuhlman_ has joined #yocto
jpuhlman__ has quit [Ping timeout: 252 seconds]
Tokamak has joined #yocto
<override> cant figure out why its the recipr is trying to cd like that - https://pastebin.ubuntu.com/p/jFKknPSdfB/
<moto-timo> WARNING: No recipes available for:
<moto-timo> /home/ubuntu/oe-core/build/workspace/appends/opentrons_git.bbappend
<override> this is the simple recipe - https://pastebin.ubuntu.com/p/Jy7Z69WC3R/
<override> ive been ignoring that warning, this the recipe in question
<override> ive been setting the path for distutils like that plenty of times before, not sure why its giving me crap for this one
<moto-timo> You named the main recipe open_git.bb previously. PN = package name == the string before the underscore.
<override> oh shoot, let me check that.
<override> moto-timo: im more concerned about that cd error..
<override> the warning I can fix
<override> the cd error is for the current recipe im working on
<moto-timo> You need to share what the notify-see we recipe is we have no clue
<override> oh, thought i put a link in there
<moto-timo> s/notify-server/
<override> let me repost it one sec
<override> this is the recipe - https://pastebin.ubuntu.com/p/Jy7Z69WC3R/
<moto-timo> I see it, but you aren’t including the file name so we are partly blind
<override> wait what? this is what the file is called - notify-server_git.bb" 18L, 755C
<moto-timo> Look at your paste bin. No file name info
<override> oh,
<override> its called notfy-server_git.bb
<override> does that help, or were you trying to ask something else
<override> its the do_compile cd step that I have no clue about
<moto-timo> Also, we use Debian naming. It should be python3-notify-server_git.bb
<override> oh, think its been cutting me some slack so far
<override> you think thats problematic ?
<override> or just a convention thing
<override> I wont run into any glob issues or something would I
<override> I had those when I wouldnt get the directory levels right for my recipes
<moto-timo> Share a git repo with your entire layer. This is madness trying to do it with pastebin.
<override> oh sure one sec
<override> ohhh I can just push the workspace folder all these recipes are getting collected in
<override> does that work?
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
<moto-timo> Put it on GitHub or gitlab.
vmeson has quit [Ping timeout: 258 seconds]
vmeson has joined #yocto
<moto-timo> Several of those recipes already exist in meta-python. Do not recreate the wheel.
<moto-timo> Layers are like lego blocks. Mix and match to build the desired outcome.
<override> think im not goign to reuse those. Thats from when I didnt know any better
<override> like pyserial and all ..
<moto-timo> I’m no longer going to help you. Good luck.
<override> huh?
Tokamak has quit [Ping timeout: 252 seconds]
<override> we were barely getting started .. jeez
<override> anyone else around who could help me out a lil?
<override> just a link or anything would work too, doesnt have to be too extensive
camus1 has joined #yocto
<override> and moto-timo: think what I said earlier came out wrong - what I meant was Im not going to redo the exisiting recipies - as in I will just reuse them from meta-python. Guess I kinda see why you acted up there lol. Not trying to reinvent the wheel. its all good
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
<moto-timo> My time is precious. You used up your a lot,
<moto-timo> allotment
<override> appreciate your time. just thought you wanted to go over the repo with me, so that "Im no longer going to help you. Good luck." sounded rather abrupt..
<override> its all good thought, thanks for all the help
<override> though*
Spooster has joined #yocto
Vonter has quit [Quit: WeeChat 3.1]
Vonter has joined #yocto
<override> could use another set of eyes on this, cant figure what Im doing wrong - https://pastebin.ubuntu.com/p/G95zsQGh6z/
Vineela has quit [Quit: Leaving.]
Spooster has quit [Remote host closed the connection]
Spooster has joined #yocto
<override> its all good, i figured it out. something was up with the commit id devtool would pick up. prolly a yocto bug.
Spooster has quit [Ping timeout: 246 seconds]
sakoman has quit [Quit: Leaving.]
georgem has quit [Quit: Connection closed for inactivity]
leon-anavi has joined #yocto
davidinux has joined #yocto
Spectrejan[m] has joined #yocto
asus_986_gpu[m] has joined #yocto
shoragan|m has joined #yocto
fabatera[m] has joined #yocto
camus has quit [Ping timeout: 246 seconds]
camus has joined #yocto
zyga-mbp has joined #yocto
paulg has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
Schlumpf has joined #yocto
rob_w has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudX
<perdmann_> Hi, i created a recipe which creates a shared Object. If i built with yocto everything looks fine, if i built the SDK my so file is not in there.
<LetoThe2nd> perdmann_: but the rest of the package is? only the object is missing?
mckoan|away is now known as mckoan
<mckoan> good morning
<perdmann_> LetoThe2nd: its just one .so and a header file. Both are not part of the SDK - but both are built during the "normal image built"
<perdmann_> LetoThe2nd: i observed this during another RDEPENDS. do i really need to use that .so file in the building process to make it available in the SDK/Image?
<perdmann_> LetoThe2nd: someone mentioned the "so Solver" but i does not find more sources about it
<LetoThe2nd> perdmann_: i'd look at the packaging. and theres TOOLCHAIN_HOST_TASK (or something similar, i can't remember) variable that lets you add stuff to the sdk.
<perdmann_> LetoThe2nd: thanks, i will try that one
florian has joined #yocto
<LetoThe2nd> perdmann_: look it up first, i'm very sure i got it close but not right.
<perdmann_> TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK. i tried _TARGET_ but looks like its not working. I will investigate again
cquast has joined #yocto
ant_ has quit [Ping timeout: 265 seconds]
ilunev has joined #yocto
kayterina has joined #yocto
<LetoThe2nd> does anybody know if alex gonzales (of yocto cookbook fame) is around?
Schlumpf has quit [Quit: Client closed]
davidinux1 has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux1 is now known as davidinux
<mckoan> LetoThe2nd: I only have his LinkedIN connection
<LetoThe2nd> mckoan: yeah have that too.
Schlumpf has joined #yocto
rodrjassoccom[m] has joined #yocto
lacouture[m] has joined #yocto
tnovotny has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
dwagenk has joined #yocto
Pierre-jeanTexie has joined #yocto
janvermaete[m] has joined #yocto
Saur[m] has joined #yocto
Guest6275 has quit [Quit: WeeChat 3.1]
vquicksilver has joined #yocto
goliath has joined #yocto
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan|m has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
lacouture[m] has quit [Quit: Bridge terminating on SIGTERM]
rodrjassoccom[m] has quit [Quit: Bridge terminating on SIGTERM]
xicopitz[m] has quit [Quit: Bridge terminating on SIGTERM]
Pierre-jeanTexie has quit [Quit: Bridge terminating on SIGTERM]
janvermaete[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
asus_986_gpu[m] has quit [Quit: Bridge terminating on SIGTERM]
Andrei[m] has joined #yocto
kayterina[m] has joined #yocto
jordemort has joined #yocto
Jari[m] has joined #yocto
janvermaete[m] has joined #yocto
khem has joined #yocto
Emantor[m] has joined #yocto
ejoerns[m] has joined #yocto
Saur[m] has joined #yocto
cody has joined #yocto
Pierre-jeanTexie has joined #yocto
shoragan[m] has joined #yocto
ndec[m] has joined #yocto
barath has joined #yocto
moto_timo[m] has joined #yocto
WadeBerrier[m] has joined #yocto
Alban[m] has joined #yocto
keepitsimplejim[ has joined #yocto
shoragan|m has joined #yocto
Spectrejan[m] has joined #yocto
fabatera[m] has joined #yocto
PascalBach[m] has joined #yocto
jonesv[m] has joined #yocto
xicopitz[m] has joined #yocto
lacouture[m] has joined #yocto
rodrjassoccom[m] has joined #yocto
AlessandroTaglia has joined #yocto
alex88[m] has joined #yocto
asus_986_gpu[m] has joined #yocto
dwagenk has joined #yocto
yates_work has quit [Remote host closed the connection]
georgem has joined #yocto
xmn has quit [Ping timeout: 258 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
tnovotny has quit [Quit: Leaving]
tnovotny has joined #yocto
camus has quit [Quit: camus]
bluelightning has quit [Quit: Konversation terminated!!!111]
Schlumpf has quit [Quit: Client closed]
rob_w has quit [Quit: Leaving]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
davidinux1 has joined #yocto
davidinux has quit [Ping timeout: 250 seconds]
tnovotny has quit [Quit: Leaving]
tnovotny has joined #yocto
Spooster has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
<override> how can I force clean a package's sources?
<RP> jonmason: testimage works with slirp?
davidinux1 has quit [Ping timeout: 250 seconds]
<override> stuff under workspace/sources
<override> for some reason all the stuff from a git repo isnt getting fetched for the commit id Im setting up a recipe with...
davidinux1 has joined #yocto
<override> trying to run devtool clean recipe or something but those options tell me do_clean isnt set..
<override> any way to just force clean the source for a recipe ?
<tnovotny> override: this will clean everything (including sstate cache): bitbake -c cleanall <recipe>
paulg has joined #yocto
<jonmason> RP: yes. It took way longer than it should've for me to find the extra things to enable to get it working, but it's passing the boot test. Seeing some issues on some platforms with dropbear/ssh. So, I'll add that (and extra tests) in the future
<tnovotny> override: but I'm not using devtool yet, so I might be missing something
<override> tnovotny: ive been trying to clean that way. been seeing this, https://pastebin.ubuntu.com/p/Ck9CRMj4VZ/
<jonmason> RP: Also, I'm trying it on dev kernels as well https://gitlab.com/jonmason00/poky/-/pipelines/324118745
<jonmason> risc-v is breaking, which is probably normal ;-)
<override> the overaching problem here is how the recipe is conviniently skipping some stuff out from the commit Im poininting it to..
<override> so i was trying to bitbake clean and maybe try other commits or something
<RP> jonmason: the boot test is pretty basic, am just wondering about some of the others that use ssh
<zedd> RP / jonmason: when I was getting set up to debug the LTP issue, I figured out the tweaks to get ssh login, etc, passing with slirp. so in theory, it should be doable.
<zedd> but I've flushed it from the cache, and can't quite recall everything I changed :D
<tnovotny> override: hmm, I have no idea...btw the missing yarn in the output is strange. Is it possible that it is related?
<RP> zedd, jonmason: would be good to document this somewhere
<zedd> the box I was doing the tests on, is still largely unchanged from that, I can go have a look later.
<RP> zedd: I have a horrible kernel hack to make the rcu stall detector 3s in master-next. Is there anything else we could do to try and provoke it you know of?
<override> think bitbake just trying doing that when it sees a make file or something in the repo.. I can build fine with the recipe tho, I just inherit setuptools3 .. :tnovotny
<jonmason> RP: https://gitlab.com/jonmason00/meta-arm/-/jobs/1371692272 has dropbear working, but the other qemus that meta-arm cares about failed
<zedd> RP: to make it the stall trigger in a shorter time ? i.e. more than tweaking: /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout ?
<RP> zedd: Yes, just wondering if there is anything else we could tweak to maybe make it fail more frequently.
<RP> zedd: if changing this doesn't change the frequency of failures on the AB, I think that tells us something
<zedd> right. That's the biggest runtime knob, but the docs talk about some macro's in the kernel that can be changed to lower some thresholds. are those the ones that you changed in your run ?
zpfvo has quit [Remote host closed the connection]
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
<zedd> RP: yup, that's where I would have started as well. There's some potential in the options hidden under RCU_EXPERT, but they are more for runing, and doing rcu offloads, etc, probably wouldn't help much here.
<zedd> but we could always clear the rcu cbs off a core (if we are smp) and see if it makes a difference.
<RP> zedd: right, that could be an interesting experiment. I guess I'll see what the current experiment shows. Do you know if there is a way to trigger a dummy stall just to test the kernel reporting?
<zedd> the rcu torture tests might be able to do that. I'll have a look at the docs for them. I haven't run them myself, but pauk mkinny is always tweaking them.
<RP> zedd: I'd like to try and see if the stall crashes the system or whether the system is crashed and the stall is just a symptom. The kernel BUG: yesterday makes me suspcious
<zedd> we could also make sure that CONFIG_RCU_TRACE is on in the future (along with the other kernel debug options), to see if that can help us glean more about the cause.
* zedd wonders how long until someone asks for a rcutorture name change
Guest55 has joined #yocto
Guest55 has quit [Client Quit]
<zedd> there's also panic_on_rcu_stall, which might dump more information to the vmcore, or maybe that is what was already tried when you talked about the vmcore.
<zedd> an yah, I can't see anyway to trigger a dummy stall at the moment.
Tokamak has joined #yocto
sakoman has joined #yocto
<RP> zedd: we pulled the vmcore from qmp out from qemu
<RP> zedd: I think I might add a sysctl to trigger a stall
ant_ has joined #yocto
OutBackDingo_ is now known as OutBackDingo
<rburton> zedd: today's discovery: linux-yocto won't boot in lkvm
ilunev has quit [Quit: Textual IRC Client: www.textualapp.com]
<zedd> aka kvmtool ?
<zedd> yah. I've never tried to boot in using it myself, so I have no config fragments for it.
<rburton> yeah
<rburton> i have docs
<override> can anyone please tell me whats going on with my bitbake here - https://pastebin.ubuntu.com/p/hn6pZrvDPV/
<rburton> moto-timo: thats obsolete
<moto-timo> Thanks Google
<rburton> yes
<rburton> like how yocto docs give you 1.6 releases
<zedd> override: the bitbake server hung, it can happen. just find the bitbake processes and kill them.
wesm has quit [Ping timeout: 265 seconds]
p34nutz has joined #yocto
<override> thanks zedd
<override> zedd: so this what makes it hang to begin with, Im trying to undersatnd what an ExpansionError is - https://pastebin.ubuntu.com/p/cBgGdJnjrF/
wesm has joined #yocto
<RP> abelloni, zedd: We have at least one rcu failure in the builds on the AB. Just trying to think of the best way to track this as it requires sshing in to check in many cases :/
<RP> zedd, abelloni: Looks like that patch in master-next is causing mayhem, tons of crashed/broken stuff :)
<RP> zedd: conclusion - the stall messsages in the kernel cause the kernel to break somehow :/
tnovotny has quit [Quit: Leaving]
<zedd> some sort of non graceful recovery from the stall state perhaps.
<RP> zedd: that is my thinking. I just mailed out 4 backtraces/stall reports
<RP> paulg, zedd: this is looking very kernel related now
<zedd> RP: one other question. do all the hangs / crashes have rcu stalls ?
<RP> zedd: yes
<zedd> so have you tried the opposite ? set the stall to some unreachable timeout ? and see if the hangs just never report the same way ? i.e. an oom or something similar ?
<RP> zedd: I have not. You have my live data
<RP> zedd: I have never seen a build with as many hangs though
* zedd nods
<RP> zedd: if that were the issue, with the original threshold we should have been seeing more oom/other messages which we haven't
* paulg wonders if he can get away with playing the Schultz "I know nothing" card...
kayterina has quit [Remote host closed the connection]
<RP> paulg: it isn't working ;-)
<RP> paulg: particularly as I also know *nothing* about rcu and yet I'm this far... :)
<paulg> I thought the LTP thing would buy me a free pass for at least a week...
<RP> paulg: I was hoping the LTP issue and this were the same thing :/
mckoan is now known as mckoan|away
<RP> manually running print_cpu_stall() with the "suppressed" bit hacked out doesn't seem to crash my local qemu
<RP> but it doesn't print any cpu traces either
goliath has quit [Quit: SIGSEGV]
<RP> and even forcing CPU traces and load onto cpus, doesn't crash
<RP> paulg: actually, could you look at something for me? I think I can see a locking bug.
<RP> paulg: rcu_print_task_stall() in kernel/rcu/tree_stall.h - that return 0;
<RP> zedd: ^^^ if you fancy a look
<paulg> baseline? 5.10.43?
<RP> paulg: 5.10.43
<paulg> got a bunch of goings on today but will look quickly now.
<RP> paulg: look at where its called and the comment, then the code...
<RP> (all in that file)
<paulg> ? the return 0 comes at the top if there is nothing to do. I don't see anything.
Tokamak has quit [Ping timeout: 256 seconds]
<RP> paulg: note the "raw_spin_unlock_irqrestore_rcu_node(rnp, flags);" below and "ndetected += rcu_print_task_stall(rnp, flags); // Releases rnp->lock."
<paulg> I guess you gave me the wrong fcn name
<paulg> print_other_cpu_stall vs. rcu_print_task_stall ?
<RP> paulg: no, that name is right :/
<paulg> ok, lemme look some more
<RP> static int rcu_print_task_stall(struct rcu_node *rnp, unsigned long flags)
<RP> __releases(rnp->lock)
<RP> perhaps I'm missing something obvious :/
<paulg> ok, now I think I see what you are saying.
<paulg> now I have to find what is obvious that we are both missing.
<RP> paulg: basically that function is supposed to release that lock and doesn't when it hits the return 0 path
<RP> paulg: and that could give the BUG: scheduling when atomic we've seen
<paulg> yeah I see the stub for ! PREEMPT_RCU releases the lock, so I'm failing to prove you wrong so far....
<RP> rcu_preempt_blocked_readers_cgp() could conceivably do something but is handled with locks elsewhere so seems unlikely
<paulg> lemme do a bit of git blame and check mainline and then if paul is around maybe go check with him.
<paulg> it does seem a bit sus though -- I'll grant you that.
<RP> paulg: looks the same in mainline too
<RP> paulg: sorry to add to your plate but thanks, does seem odd and worth looking at
<RP> paulg: definitely would explain a few things
<RP> paulg: also, its only called by print_other_cpu_stall() and I was testing my sysrq with print_cpu_stall()
<paulg> so basically you might have found a bug - just not the one you were looking for. :-P
<RP> paulg: no, I think this could be it
<paulg> looking at 3fc3d1709fc currently....
<RP> paulg: definitely fits the two BUG: in those backtraces I sent
<ant_> you guys have a perfect week-end timing
* paulg hasn't read email yet today. :-/
* paulg wasn't here yesterday.
<RP> paulg: its c583bcb8f5edd48c1798798e341f78afb9bf4f6f
<paulg> yeah looking at that commit already
<paulg> introduces the "interesting" locking.
<RP> paulg: I need to head afk for food. I'm going to queue a fix in master-next and ask it be started on the autobuilder after maint completes
<RP> paulg: we can run it with the other patch to lower the timing so we'll hopefully see a few rcu stalls but no crashes
<paulg> I'll see if I can scare up paulmck
<RP> paulg: thanks. Its help to have a sanity check I'm not missing anything obvious
<RP> halstead: after maint could we schedule a master-next build of a-full please to test this change?
* RP -> afk
Vineela has joined #yocto
<paulg> for those following along at home, it seems a fix is already in, just hasn't completed the mainline --> stable --> zedd/yocto circuit quite yet.
<ant_> \o/
behanw has joined #yocto
<ecdhe> I have a recipe that doesn't inherit any bbclass. I set some variables, that's okay, but when I add do_configure(), I get the error "myrecipe_1.0.bb:26: unparsed line: 'do_configure()'"
<ecdhe> The line above it is "S = "${WORKDIR}/git""
<ecdhe> I put the entire line in quotes on irc but should have left it: S = "${WORKDIR}/git"
<ecdhe> When I remove do_configure, there's no parse issue.
<ecdhe> I changed the function name to my_do_configure, and even to a random identifier, but any task I attempt to define results in an "unparsed line" error
LetoThe2nd has joined #yocto
<ecdhe> okay, got it: you have to use K&R brace placement, so "do_configure() { "
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
goliath has joined #yocto
vmeson has quit [Ping timeout: 246 seconds]
vmeson has joined #yocto
Guest15 has joined #yocto
behanw[m] has joined #yocto
LocutusOfBorg has quit [Changing host]
LocutusOfBorg has joined #yocto
TrevorWoerner[m] has joined #yocto
dev1990_ has quit [Quit: Konversation terminated!]
p34nutz has quit [Quit: Client closed]
<ecdhe> I've got a recipe that requires a gcc3 or gcc4 cross compiler. I'm working in dunfell.
<paulg> interesting - that is rather retro.
<ecdhe> yes
<ecdhe> I probably need to just cherry pick a denzil recipe and add it to my own layer
<ecdhe> unless there is a faster way I haven't considered
<ecdhe> I wish yocto would keep more recipe versions around for reverse compatibility
<ecdhe> The cross compiler I'm using is too new
<ecdhe> another option could be to patch the old kernel just enough to be built with a newer compiler
<paulg> I wouldn't recommend that.
<paulg> any reason why you can't simply build the kernel outside of yocto and plop it into your image?
<ecdhe> paulg: may want to iterate on it, want to have things source controlled if possible
<ecdhe> but archiving the binaries is an option too
<ecdhe> the layer system is brilliant
<ecdhe> paulg: why would you recommend against patching the kernel?
<paulg> the reason I don't recommend patching the old to build with the new, is that you are straying into unchartered waters, as nobody else has probably done that and updated the old source appropriately ; so you've lost the implicit run-time validation of *all* the original user base for whatever it is you are working on.
<paulg> sure, you can make it *compile* but what if the compiler does an optimization on some lock ordering that the old compiler never did and the old source never anticipated?
<paulg> if you are just hacking around on some personal project then maybe that isn't a concern.
wesm has quit [Remote host closed the connection]
florian has quit [Ping timeout: 265 seconds]
Vonter has joined #yocto
<abelloni> my answer would be "simply upgrade your kernel"
<abelloni> you don't want to ship a product on 2.6.x
<abelloni> or 3.x
<paulg> or 4.x :-)
<abelloni> yes too but I'll accept 4.19 ;)
<paulg> anyway who knows if ecdhe is fighting with an old product being sustained, or limited RAM resources or what - I'm sure an upgrade was considered if at all possible.
florian has joined #yocto
<abelloni> yes but I don't see the point in updating userspace if the kernel is full of holes
<abelloni> and also upgrading userspace will have a bigger impact on storage/memory size than just the kernel
hauke has joined #yocto
Vonter has quit [Ping timeout: 258 seconds]
florian has quit [Ping timeout: 252 seconds]
cquast has quit [Ping timeout: 258 seconds]
florian has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
alejandr1 has quit [Ping timeout: 265 seconds]
<ecdhe> paulg: on may way to having original compiler available
<ecdhe> no kernel mods
florian has quit [Ping timeout: 252 seconds]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto