seninha has quit [Remote host closed the connection]
demirok has quit [Quit: Leaving.]
sakoman has joined #yocto
nemik_ has quit [Ping timeout: 246 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 260 seconds]
nemik_ has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 272 seconds]
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #yocto
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #yocto
amitk has joined #yocto
sakoman has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
<kiwi_29_[m]>
Hello..I m using Go lang compiler v 1.19.3 . Because my yocto is based on dunfell and go v1.19.3 is available on langdale, instead of upgrading yocto(which was breaking all my packages), I copied meta/recipes-devtools/go from yocto to my custom-layer/recipes-devtools. This works. However, when I compile my go... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/fc9b9316a8d836abfdd073f2c0f89d883517e7a8>)
<kiwi_29_[m]>
* Hello..I m using Go lang compiler v 1.19.3 . Because my yocto is based on dunfell and go v1.19.3 is available on langdale, instead of upgrading yocto(which was breaking all my packages), I copied meta/recipes-devtools/go from yocto to my custom-layer/recipes-devtools. This works. However, when I compile my go... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/741ed90b3bff2c15f412197c13d571a4df90586d>)
sakoman has quit [Quit: Leaving.]
malsyned has joined #yocto
malsyned has quit [Ping timeout: 255 seconds]
malsyned has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
malsyned has quit [Ping timeout: 246 seconds]
alessioigor has joined #yocto
malsyned has joined #yocto
malsyned has quit [Ping timeout: 265 seconds]
xmn has quit [Ping timeout: 272 seconds]
barometz has quit [Ping timeout: 246 seconds]
malsyned has joined #yocto
malsyned has quit [Ping timeout: 268 seconds]
demirok has joined #yocto
malsyned has joined #yocto
malsyned has quit [Ping timeout: 272 seconds]
rob_w has joined #yocto
frieder has joined #yocto
jeffrey33 has joined #yocto
malsyned has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX
gho has joined #yocto
malsyned has quit [Ping timeout: 272 seconds]
goliath has joined #yocto
leon-anavi has joined #yocto
malsyned has joined #yocto
zpfvo has joined #yocto
<manuel>
I have a system running with weston&wayland, but to start I need to invoke `weston-start` manually. There is a graphical.target WANTing a non-existent display-manager.service.
<manuel>
Is display-manager.service be provided by a package I don't have?
<Payam>
I am trying to enable VLAN on my yocto. How do I do that exactly? Any references?
gho has quit [Ping timeout: 248 seconds]
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
sion33 has joined #yocto
gho has joined #yocto
flumpy33 has quit [Ping timeout: 268 seconds]
<d-fens>
is threre any build in mechanism to replace variables in a in file included in a .bb receipt or do i have to use sed and such
<LetoThe2nd>
d-fens: sed
<d-fens>
ok, so its right that only in receipts the variable expansion works
<LetoThe2nd>
d-fens: you just need to have a clear distinction between metadata and payload. bitbake variable and their expansion happen in the metadata. when ever you need to modify something in the payload, you need to actively do so, for example by sed.
<d-fens>
you should make a cheatsheet with all the valuable explanations you posted over time , thx
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<LetoThe2nd>
d-fens: we usually put them in chants.
<d-fens>
:)
malsyned has joined #yocto
malsyned has quit [Ping timeout: 252 seconds]
<Payam>
If I want to change the kernel of a yocto projekt in a custom meta layer. do I need to create a recepie-kernel?
<LetoThe2nd>
Payam: depends a bit if you want to do a full replacement of just add a configuration fragment for example.
<LetoThe2nd>
question - if deciding upon a license for a bare metal open source thing, would you rather pick MIT od Apache 2? I feel like the latter is more complicated, but more explicit on eventual patents and all involved contributors.
<gsalazar>
Hi, is there a way to verify the checksum of local files mentioned in SRC_URI?
<rburton>
the checksum is mainly for transfer integrity, local files are assumed to be fine. if you can't rely on local file storage you've bigger problems :)
ptsneves has joined #yocto
<RP>
"RuntimeError: concurrent poll() invocation" - that is a new achievement :)
<JaMa>
congratz :)
<LetoThe2nd>
RP: do you want a badge?
JM has joined #yocto
JM is now known as JM12
JM12 has quit [Client Quit]
JM12 has joined #yocto
<RP>
LetoThe2nd: it is just nice to find new and intersting ways to break bitbake for a change
<RP>
it is a bit sad as I had a crazy idea to solve a few issues but isn't quite working
<Payam>
LetoThe2nd, I just want to enable VLAN
<JM12>
Hello people, I'm (sometimes) getting a "FileNotFoundError" for "CVE_CHECK_MANIFEST" during the do_rootfs step
<JM12>
*** 0230: with open(manifest_name, "w") as f:
<JM12>
0231: f.write(text_data)
<JM12>
It seems this fails because the parent directory of the file it tries to write (tmp_machine/deploy/images/machine/image.rootfs.cve) does not exist yet for mc:machine:image (only specific machines seem to fail).
<JM12>
I'm trying to figure out if I've got a missing dependencies or something along those lines, and I was mostly wondering if anyone could tell me in which step this directory is normally created, though any other help would be appreciated.
<LetoThe2nd>
Payam: as I have never "enabled VLAN", what does it mean? adding a few config options, or what?
<Payam>
Configuring the kernel is what it should mean
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
sotaoverride is now known as Guest8299
Guest8299 has quit [Killed (sodium.libera.chat (Nickname regained by services))]
sotaoverride__ is now known as sotaoverride
sotaover1ide has joined #yocto
kscherer has joined #yocto
seninha has joined #yocto
<Payam>
rburton, I work on AgL. and when I do according to the docs and run bitbake qemux86-64 -c menuconfig I get this error : Nothing PROVIDES 'qemux86-64'
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<JaMa>
Payam: qemux86-64 is MACHINE name, not recipe name
<Payam>
so do I need to have a recepie for kernel?
<Payam>
I can not find any .config file under work/
sakoman has joined #yocto
sotaoverride has quit [Remote host closed the connection]
<sudip>
linux-yocto is the kernel recipe name for qemux86-64 of agl
<Payam>
how did you know that?
<LetoThe2nd>
Payam: maybe it would be useful if you learned the real basics? like, what is a recipe, what is a machine, what is a distro, what is an image? tbh, the knowledge that linux-yocto is the default kernel for the included qemu machines is pretty much common knowledge.
<Payam>
LetoThe2nd, I read the first chapter a book
<Payam>
I am reading the rest now
zpfvo has quit [Ping timeout: 256 seconds]
<sudip>
well, it actually helped as Payam said its for qemux86-64, but agl has other kernel recipe name depending on arch or machine
<Payam>
where do you find those names sudip ?
<JaMa>
you can also use virtual/kernel which will select preferred kernel provider
<Payam>
but there should be documented somewhere right? I google and I end up on just Github issues and etc.
<rli>
Hello, I'm trying to include a git describe into my image build but cant manage to execute it in my yocto repo. It works fine to execute within the same meta-layer directory but I can't figure out how to get the status of the repo containing the meta-layers. Have anyone tried or can point me in a direction?
rob_w has quit [Quit: Leaving]
<JaMa>
rli: see base_get_metadata_git_branch from metadata_scm.bbclass
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
azcraft has joined #yocto
<xcm>
hey all. i sometimes have an issue where even though `ping 8.8.8.8` works fine, `nslookup google.com 8.8.8.8` fails to resolve. there's no iptables or anything on the system
barometz has joined #yocto
prabhakarlad has quit [Quit: Client closed]
sion33 has quit [Quit: WeeChat 3.0]
<Payam>
So now the .config is shown but it is impossible to navigate
<RP>
JPEW: I sent a few bitbake changes to the list which I might discuss on the call later if anyone is interested
<JPEW>
k
rli has quit [Quit: Client closed]
JM12 has joined #yocto
Guest22 has joined #yocto
Guest22 has quit [Client Quit]
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 252 seconds]
otavio has joined #yocto
manuel_ has quit [Remote host closed the connection]
manuel1985 has joined #yocto
manuel1985 has quit [Ping timeout: 265 seconds]
seninha has quit [Quit: Leaving]
prabhakarlad has joined #yocto
sstiller has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 252 seconds]
Payam has quit [Read error: Connection reset by peer]
Bardon has quit [Ping timeout: 246 seconds]
gsalazar has quit [Ping timeout: 252 seconds]
Dolly has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
<RP>
"ERROR: ParseError at /home/pokybuild/yocto-worker/qemux86-64/build/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc:15: Could not inherit file classes/autotools.bbclass"
* RP
wonders how that could happen
florian has quit [Quit: Ex-Chat]
JM12 has quit [Quit: Client closed]
gsalazar has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
<moto-timo>
JaMa: that required a code change, but thankfully Robert Yang sent a patch
frieder has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
gho has quit [Quit: Leaving.]
mckoan is now known as mckoan|away
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
<rfs613>
RP: in the cloud, anything is possible ;-)
seninha has joined #yocto
Bardon has joined #yocto
<brabander>
RP: i don't really understand that ping command :p
zpfvo has quit [Quit: Leaving.]
<khem>
kiwi_29_: You may try to disable cgo, set export CGO_ENABLED=0 in the failing package and see if that helps
goliath has quit [Quit: SIGSEGV]
Bardon_ has joined #yocto
Bardon has quit [Ping timeout: 268 seconds]
<kiwi_29_[m]>
khem: many thanks for the response... working on it right now
Bardon_ has quit [Ping timeout: 260 seconds]
<RP>
brabander: the need or what it does?
gsalazar has quit [Ping timeout: 252 seconds]
<brabander>
what it does, looks like the implementation is missing because it only prints something and doens't use the parameters
<RP>
brabander: it is simply a command to run on the server and send a string back to the client, a simple check to see if the connection can send a message and get it back
<RP>
well, get something back
<brabander>
ahh, I see
<brabander>
so not an ICMP ping
<RP>
brabander: similar in concept but not ICMP related
<JPEW>
Mmm ya. I was a little worried about that sort of thing
<JPEW>
RP: this is so crtl+c works?
<RP>
JPEW: amongst many other things
<RP>
JPEW: I think the issue is the inotify stuff being acted upon too soon. I have ideas on how to fix it by separating the queue from the handling
malsyned has quit [Ping timeout: 260 seconds]
<JPEW>
I was thinking that maybe you could move just the Ctrl+c handling to a thread for now and slowly move other ui commands to the same thread over time
<JPEW>
Not sure if that even makes sense
<JPEW>
Don't know what all the Ctrl+c handling does in the server
<RP>
JPEW: It isn't so much Ctrl+C as being able to know we're being asked to shut down
<RP>
JPEW: the only way to know that is if we read the command socket
ferlzc has quit [Read error: Connection reset by peer]
seninha has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
<khem>
RP: halstead I am seeing an issue on AB https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/2254, this is because isort-5.11.3.tar.gz is empty and its not being deleted so any susequent rebuilds are failing. Is there some way to remove zero sized archives from downloads/ on AB ?
<khem>
kiwi_29_: ok so it seems your app really needs CGO ☹️
<khem>
kiwi_29_: I think the problem is with mismatch between C runtime and go runtime, how its coming in I dont know
<halstead>
khem: I'll remove the bad file. One moment.
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
<halstead>
khem: I've cleared out all the zero byte tmp files including that one. We could make a job for it if that's desirable.
florian_kc has joined #yocto
<kiwi_29_[m]>
<halstead> "khem: I'll remove the bad file..." <- Hello khem yes...I will need cgo...how to make sure both c and go runtime matvh.... the whole process using v1.19.3 of normal x86 go toolchain downloaded from golang.org on hostmachine (without yocto) works
<kiwi_29_[m]>
s/matvh/match/
<kiwi_29_[m]>
<khem> "kiwi_29_: ok so it seems your..." <- @khem yes...I will need cgo...how to make sure both c and go runtime match.... the whole process using v1.19.3 of normal x86 go toolchain downloaded from golang.org on hostmachine (without yocto) works
<kiwi_29_[m]>
s/@/ /
<kiwi_29_[m]>
I have a pointer ...my recipe at the top mentions TOOLCHAIN = clang ...I wonder may be plugins are compiling with clang ..but during runtime...may be only gcc runtime is available on target
<kiwi_29_[m]>
let me try to remove clang...its probably not needed at present
<JPEW>
So even with the thread, it still seems to have trouble?
camus has joined #yocto
camus1 has joined #yocto
<RP>
JPEW: yes :/
<RP>
JPEW: pings were working, then it stopped servicing commands
<JPEW>
RP: I would imagine it eventually has to wait for some semaphore
<JPEW>
?
camus has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
<RP>
JPEW: we don't have many, just the event ones. I wonder if those can deadlock somehow
<JPEW>
RP: Seems possible. From expirence, it can be really tricky to retrofit threading to a codebase without deadlocks and race conditions
<RP>
JPEW: right, I've been avoiding this :/
<JPEW>
Is there a bug report that describes the problem?
<RP>
JPEW: there are several bug reports but most of this is a mental map I have of several server issues
<JPEW>
It's not that we shouldn't make it better, but I have a hard time trying to weight what actual problem is vs how invasive the fix is on this one (due to lack of familarily mostly)
<RP>
JPEW: my conclusion is that we're never going to be able to move the codebase beyond where we are with certain bugs without doing something like this threading
<RP>
but I appreciate you probably don't have the context to conclude that :/
<JPEW>
RP: Ya, that seems likely; when I've done this sort of thing before, it usually involves a pretty deep dive into the code to figure out the correct locking strategy :/
<RP>
JPEW: could you have a look at what we're doing with builtins in bb.event and see if there is a better way to inject d for the scope of the handler?
<JPEW>
Sure
<RP>
JPEW: I suspect if we can improve that to drop the lock then this might work better. The other thread event lock is well established and then the two wouldn't be able to race
<JPEW>
Ah, is one thread adding it to builtins and the other removes it?
<JPEW>
Or rather one thread adds and removes it and the other is left missing it
<JPEW>
(when the first removes it)
<RP>
JPEW: yes
<JPEW>
That's really tricky.... if it's the exact same `d` everytime, you can (if you cover your eyes and plug your nose), reference count adding `d` to `builtins`
<RP>
JPEW: I was wondering about exec() and setting a context?
<JPEW>
Ya, that was going to be a suggestion also
<JPEW>
Otherwise, you need to pass d as an argument to the handler
<JPEW>
You could use `threading.local()` to get Thread-Local storage, but you'd still need to re-write the handlers, so it's not gaining much over passing d
<JPEW>
... so probably not worth it
<JPEW>
There isn't a thread specific version of __builtins__, globals() in Python AFAICT
<RP>
JPEW: that is something along the lines of what I was wondering
<JPEW>
Might not be too bad; I think handlers are rare enough that the extra overhead of eval is probably OK?
<RP>
JPEW: have a look at the code in register(), could we just stick d in there ?
<RP>
JPEW: We compile these functions ourselves I think so we might be able to
<JPEW>
Oh, ya, let me see....
risca_ is now known as risca
<RP>
JPEW: I think the solution might be easier/more obvious. The only risk is some handler expecting d in the global scope but we'd just have to fix that
<JPEW>
WHy not make the compiled version accept d as a second argument there?
<JPEW>
Ya fair
<RP>
JPEW: right, that seems obvious now :)
<JPEW>
d in global scope does seem like it might be a problem
<RP>
JPEW: in, or not in? :)
<JPEW>
If the code in the handler calls a function that expect d to exist in the global scope, passing it as an argument would not work
<RP>
JPEW: I wonder where we register precompiled handlers from? :/
<JPEW>
.... but that code probably doesn't handle threading correctly either?
<RP>
JPEW: that should fail quickly/obviously at least
<kiwi_29_[m]>
<kiwi_29_[m]> "basically use -trimpath" <- still no luck yet...working various trial and error solutions
<RP>
JPEW: looks like a couple of internal handlers in bitbake but we can fix the parameters for those
<JPEW>
Ya, passing `d` as an argument is probably the cleanest way to do it
<RP>
JPEW: thanks for talking it through. I was thinking this would have to go the eval/exec route!
<JPEW>
You still need the lock you added though?
<JPEW>
Unless all our handlers can handle being multi-threaded
<RP>
JPEW: I don't see why they shouldn't have an issue with threading?
<JPEW>
RP: Yep as long as the handlers can stand to be running in parallel :)
<RP>
JPEW: we'll see
<RP>
this code is neater anyway
olani has quit [Remote host closed the connection]
<RP>
I was thinking the 9,000 line log sounded bad so stopped that build. Next one I looked at, 29,000 lines :/
olani has joined #yocto
malsyned has quit [Ping timeout: 272 seconds]
kscherer has quit [Quit: Konversation terminated!]
<kiwi_29_[m]>
khem: what does the dir FILES_${PN} = "${libdir}/go/pkg/${TARGET_GOTUPLE}_dynlink. store..how is it different from FILES_${PN} = "${libdir}/go/pkg/${TARGET_GOTUPLE}
<kiwi_29_[m]>
got that from go-runtime.inc
<kiwi_29_[m]>
* khem: what does the dir FILES\_${PN} = "${libdir}/go/pkg/${TARGET\_GOTUPLE} _dynlink. store..how is it different from FILES_${PN} = "${libdir}/go/pkg/${TARGET\_GOTUPLE}
<kiwi_29_[m]>
* khem: what does the dir FILES\_${PN} = "${libdir}/go/pkg/${TARGET\_GOTUPLE}\_dynlink. store..how is it different from FILES_${PN} = "${libdir}/go/pkg/${TARGET\_GOTUPLE}
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
malsyned has joined #yocto
malsyned has quit [Ping timeout: 272 seconds]
<RP>
JPEW: looks like there are problems in tinfoil and hence devtool :(
nemik_ has quit [Ping timeout: 272 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 268 seconds]
leon-anavi has quit [Quit: Leaving]
malsyned has joined #yocto
nemik_ has joined #yocto
malsyned has quit [Ping timeout: 268 seconds]
gsalazar has joined #yocto
<RP>
JPEW: found it, I hope
nemik_ has quit [Ping timeout: 268 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 260 seconds]
nemik_ has joined #yocto
azcraft has quit [Remote host closed the connection]
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
<RP>
more issues, some kind of "busy" error. Tomorrow...