<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
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
<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
<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 ?
<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
<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.
<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.
<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>
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]