<sotaoverride>
Dont see any python scripts actually!
<SunInDusk>
Hello everyone, has anyone encountered this situation? I use yocto dunfell version, gcc is 9.3.0. Sometimes the code compiles with an error, but I can't find the reason for the error in the compiled log file. Anyone encountered this situation? I googled a lot and didn't find any information.
sakoman has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #yocto
mihai has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
opello has left #yocto [#yocto]
sakoman has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
pgowda_ has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Circuitsoft has quit [Quit: Connection closed for inactivity]
Starfoxxes has quit [Ping timeout: 255 seconds]
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
Starfoxxes has joined #yocto
xmn has quit [Ping timeout: 244 seconds]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
SunInDusk has quit [Quit: Leaving]
tre has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX, yo mckoan
<jclsn>
Morgen
<ykrons>
Hi all
<ykrons>
I'm working with Dunfell for iMX8 machine where I have activated multilib support to be able to build 32bit applications. Everything went fine and I'm able to build 32bit application running on my 64bit BSP with the generated BSP.
leon-anavi has joined #yocto
<ykrons>
However libusb in 32bit version is missing, so I have added lib32-libusb1 to my IMAGE_INSTALL. Since that change I have an error when I generated the SDK "WARNING: eagle-image-1.0-r0 do_populate_sdk: Manifest /workdir/oe-core/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-wayland-protocols.package_write_ipk not found in 1388_imx8x aarch64-mx8 armv7at2hf-neon armv7ahf-neon armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
<ykrons>
I can't find the relation between adding the libusb and wayland-protocol and why this can break manifest generation. Did someone have an idea what can be wrong ?
<kanavin_>
ykrons, you should not have to add any library explicitly, it usually gets pulled in via package dependencies
<kanavin_>
if that doesn't happen, then nothing depends on the library, and then why install it?
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
beneth has quit [Read error: Connection reset by peer]
<ykrons>
kanavin_: I know that point, but I need to build the application out of yocto with only the SDK and I have not yet done the corresponding recipe. I'm expecting adding lib32-libusb1 would have the same impact as a RDEPENDS on it
<ykrons>
I will draft a empty recipe with only this dependencies to see if it is better
<brware>
Hi guys. I'm new to yoctoproject and I generated a minimal image but when I try to run It as live the filesystem come as read only. Is there anyone that help me to switch the rootfs in write/read mode. Thanks in advance
<LetoThe2nd>
brware: by default the created images are rw, so the question is which documentation you followed.
<brware>
I don't find informations about this
<brware>
LetoThe2nd you suggest me a documentation that help me about this?
<brware>
can?
<LetoThe2nd>
brware: how did you start?
zeddii has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
brware: because if you ran the generic yocto getting started, then you have a rw rootfs.
<brware>
LetoThe2nd Yes, if I install It the filesystem is rw but if lunch the live it is ro
florian has joined #yocto
<kanavin_>
abelloni, patch to yocto-autobuilder-helper sent
<LetoThe2nd>
brware: what is "the live"? what is "the install"?
<brware>
LetoThe2nd I generate a bootable iso and the options that can you choose are: Graphics console boot and Graphics console boot
<brware>
I mean Graphics console boot
<LetoThe2nd>
brware: see, so far you totally left out that we are talking about an ISO image. that was the missing piece.
milkylainen has joined #yocto
<LetoThe2nd>
brware: don't know then, never used it.
<brware>
LetoThe2nd Do you have a custom boot loader? I build image for the genericx86-64
<LetoThe2nd>
brware: no, i also don't do x86, sorry.
<milkylainen>
Total noob/basic question. Tried passing an extramake to a package containing a path to a file. Variable is passed correctly. But that path is relative and is not found from the package source. $THISDIR/files?
<milkylainen>
So how do I pass an absolute path when building a package, or where do I place files the source can find?
brware has quit [Quit: Ping timeout (120 seconds)]
ptsneves has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
tomzy_0 has joined #yocto
nemik has joined #yocto
ardo has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 244 seconds]
ardo has joined #yocto
nemik has joined #yocto
brware has joined #yocto
mihai has joined #yocto
<ykrons>
kanavin_: I have added a recipe for my apps with libusb1 in DEPENDS and I got the same error during SDK generation when I had my lib32-myapp to IMAGE_INSTALL
brware has quit [Quit: Ping timeout (120 seconds)]
seninha has joined #yocto
<mrybczyn[m]>
JPEW RP: will someone working on the spdx class be in Dublin at ELC? There's an interesting new functionality in the works and a chat could be useful
<RP>
mrybczyn[m]: I'm not sure. I won't be there unfortunately :(
goliath has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
<LetoThe2nd>
does anybody happen to have a x86 harddisk image build around for download? core-image-minimal or such?
<landgraf>
thought it may be because of feature freeze or something like that
zeddii has quit [Ping timeout: 240 seconds]
<RP>
landgraf: we're just struggling with a few issues causing many build failures
Xagen has quit [Ping timeout: 268 seconds]
<RP>
infrastructure fetching issue, ruby/webkit issue that suddenly appeared and so on
<landgraf>
RP: yup. I know. Something for me to work on? I have plenty of free time now...
<JPEW>
mrybczyn[m]: I don't think so unfortunately
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
SmoothBrain has joined #yocto
<SmoothBrain>
Hi all, anyone ever figured out a way to make kas less verbose?
<SmoothBrain>
It's printing INFO logs by default. And there is only a DEBUG flag as a CLI parameter to enable more logs
<JPEW>
mrybczyn[m]: you could bring it up at the dev meeting on Tuesday?
<mrybczyn[m]>
JPEW: will start from a ml post and then we'll come yo a Tuesday meeting, deal
<RP>
landgraf: there are lots of small things to tidy up now I think. I'm waiting on a rust fix and the current patch queue testing and then I think we'll build M3
* RP
remembers about the broken nativesdk-gcc
<JPEW>
mrybczyn[m]: sounds good :)
hmw[m] has joined #yocto
paulg has joined #yocto
ecdhe has quit [Ping timeout: 268 seconds]
ecdhe has joined #yocto
eirikb[m] has joined #yocto
Xagen has joined #yocto
<eirikb[m]>
Hi. Can I ask about application development environments here?
mvlad has joined #yocto
tre has quit [Remote host closed the connection]
ecdhe has quit [Ping timeout: 244 seconds]
<mckoan>
eirikb[m]: if is related to Yocto or the SDK yes
ecdhe has joined #yocto
<eirikb[m]>
mckoan: Yes. Kind of. I'm thinking about creating a docker image which could both run and build our application. The application is not hardware dependent, and I believe this could greatly improve the development process.
<eirikb[m]>
I'm able to build a docker runtime image of our yocto image, but I'm not able use any build tools. I have not tried including the SDK yet, as I hoped I wouldn't need to
<qschulz>
eirikb[m]: what about using qemu for running your application?
<qschulz>
based of an SDK running on your host directly
<eirikb[m]>
We use CLion, and remote development against docker in CLion is very very good, so I would hope to not use that
<ykrons>
With MULTILIB enabled, it seems Yocto generates a manifest for lib32-wayland-protocols that it is not able to find during SDK generation. The manifest name is built with manifest-<32bit arch>-<MACHINE_SOCARCH>... whereas populate_sdk is looking for manifest-<32bit arch>... . I think it is related to "fsl-dynamic-packagearch" mechanism but I'm a bit lost at that point. Does someone already faced similar issue or have an hint to track this one ?
<kanavin_>
This looks like something a lot of folks would like to have, I hope the actual ui and functionality withstands the 'real world'
<RP>
kanavin_: nice. We've known this was an issue for years. This is a first good step
<kanavin_>
RP: yes, towards something of a holy grail: an official turnkey cicd solution
<RP>
kanavin_: I'm kind of sad I'm still not carving out time to work on bits of it
<mckoan>
kanavin_: a use case or a small doc or post would help to understand it quickly
<kanavin_>
mckoan, yes, I plan to write more on linkedin about it, and fix documentation and manuals throughout
Schlumpf has quit [Quit: Client closed]
alimon has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Xagen has quit [Ping timeout: 252 seconds]
wkawka has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
landgraf has quit [Quit: WeeChat 3.5]
alimon has joined #yocto
Xagen has joined #yocto
<jackos888[m]>
Hello
<jackos888[m]>
How can I generate an SDCard image with LUKS rootfs?
<jackos888[m]>
within yocto
<qschulz>
kanavin_: any chance this makes it to kirkstone? I guess too big of a feature to add it to an LTS right?
<qschulz>
kanavin_: asking because when I find time I'll finally update from honister to kirkstone but we're currently using kas
<kanavin_>
qschulz, maybe
<kanavin_>
it's tooling not content
<kanavin_>
the template location stuff, certainly not though
<RP>
we're not backporting this
<qschulz>
ack, thx :)
florian has quit [Quit: Ex-Chat]
goliath has quit [Quit: SIGSEGV]
<kanavin_>
qschulz, it's probably one of those where you have to maintain backports on top of kirkstone fork if you really want it
<chrysh>
easy yocto question for 10 points: How can I change the python version that is used for boost? This file uses the env variable PYTHON_BASEVERSION, but overwriting it in my image does not have any effect on the version (I checked by looking into the output of bitbake -e boost)
alicef has quit [*.net *.split]
shoragan has quit [*.net *.split]
Crofton has quit [*.net *.split]
ldts has quit [*.net *.split]
shoragan has joined #yocto
ldts has joined #yocto
Crofton has joined #yocto
alicef has joined #yocto
<chrysh>
(I mean, I can obviously directly change it in the boost.inc file, but I bet there is a more yocto way)
zpfvo has quit [Quit: Leaving.]
<mckoan>
/IMAWAY
wkawka has quit [Quit: Client closed]
pgowda_ has quit [Quit: Connection closed for inactivity]
<qschulz>
kanavin_: not worth it for a very small BSP but otherwise yes :)
<qschulz>
chrysh: recipe data is local to the recipe
<qschulz>
so changing it in the image is not going to change it in the boost recipe
prabhakarlad has quit [Quit: Client closed]
<qschulz>
and I guess you'd want to upgrade the python recipe to use the version you want?
<chrysh>
qschulz: true, the yocto chant. yes, I would like to use a more recent python version
<chrysh>
so changing it in the boost.inc recipe is actually the right way to go?
<qschulz>
it's not clear why yuou want a different python version and if it's related to boost only?
<qschulz>
chrysh: just import a newer version of python and then PREFERRED_VERSION_python = "3.10%" in (likely) your distro conf file
wkawka has joined #yocto
<mischief>
finding that during dunfell->kirkstone my kernel modules are now stripped and unloadable. any idea about that?
<qschulz>
likely _python3
<kanavin_>
chrysh, supporting more than one version of python in a single build is basically impossible
ptsneves has quit [Ping timeout: 268 seconds]
<chrysh>
kanavin_: It's just that our software stack is compiled with python 3.8, and that's what I would like to use, also globally.
<kanavin_>
chrysh, I think you are subscribing for a world of pain if you try to replace what your yocto prescribes in oe-core
<chrysh>
qschulz: Why? Because that's what the application programmers decided to use at some point. Currently, I see an error when compiling boost related code, but I would also be happy to have it globally
<chrysh>
kanavin_: is it not just a matter of checking out a new bitbake recipe? Or can I just update oe-core or so?
<kanavin_>
chrysh, you can attempt to backport a newer python onto an older yocto, but this may quickly unravel into build errors and compatibility issues at runtime, and the need to backport many additional pieces
<kanavin_>
you better update yocto itself to a newer version
goliath has joined #yocto
<chrysh>
kanavin_: We have a vendor bsp...how easy is it to update yocto itself?
<vvn>
what is the best way to disable getty@tty1.service in an image?
<kanavin_>
chrysh, depends on how big the delta is between what you have and where you want to be
<kanavin_>
chrysh, and whether all of the layers, including the BSP vendor one are actively maintained to support the desired target version
<RP>
JPEW: really struggling to reproduce this unix domain socket issue. I put a ping(), close(). ping() call in bitbake-worker from task context and ran it up with BB_NUMBER_THREADS="1000" bitbake world -n but couldn't break it
<JPEW>
RP: hmm
<RP>
JPEW: perhaps it needs to be server context
<chrysh>
kanavin_: qschulz: Thank you, I will give it a thought during the weekend
<RP>
JPEW: is it possible this is happening if the hashserv is somehow slow to startup?
<RP>
JPEW: i.e. it really hadn't created the socket yet
<JPEW>
ya, that could be
<JPEW>
Maybe you can add a loop to poll in the main bitbake until it's actually created?
<JPEW>
(or some timeout)
<JPEW>
That would certianlly explain the "File not Found" error
<RP>
JPEW: I'm struggling to see how this could stall out for as long though
<RP>
JPEW: can't be, there are log entries in cooker before this saying "unihash changed to"
<JPEW>
Maybe CWD is changing?
<RP>
oh, this is async of course
<RP>
I bet that is it
sakoman has joined #yocto
<RP>
JPEW: the failing logs always show the connect being deferred to report_unihash time so that makes sense
<JPEW>
OK, well at least that's a simple fix :)
tomzy_0 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<RP>
JPEW: it is already calling self.loop.run_until_complete() on the connect() call
<RP>
JPEW: it is probably as the connect call is coming from send_wrapper
* RP
is a bit lost in the maze
<JPEW>
Ya, that is synchnronous (it will block the calling thread)
<JPEW>
Is it possible a different thread changes the CWD?
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<JPEW>
RP: I guess the simple test would be to temporarily bypass the AF_UNIX path length work around and thereby remove the chdir
<JPEW>
If that fixes it, at least we know that is the problem
<JPEW>
If that's the case, maybe it's the lazy creation of the client that's burning us here (and some unscrupulous threads); maybe we can make the client up front instead of being lazy about it
kscherer has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
florian_kc has joined #yocto
<RP>
JPEW: reproducer and root cause in the bug
<RP>
JPEW: it is a bit twisted
<JPEW>
RP: Got it
<JPEW>
I think if we move the os.chdir() stuff down into AsyncClient::connect_unix::connect_sock() it would fix it
<eirikb[m]>
<mckoan> "eirikb: please try calling..." <- Same error.
<eirikb[m]>
I tried creating a new runtime image including the SDK. This works, also in CLion, but I need to set up CLion to use an environment file, and hard code paths to cmake etc. Best to not have the toolchain
mlaga97 has quit [Client Quit]
nemik has quit [Ping timeout: 244 seconds]
mlaga97 has joined #yocto
nemik has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
<RP>
JPEW: you can't next event loops :/
<RP>
nest
<JPEW>
I don't remember, why?
<RP>
JPEW: specifically disallowed by python asyncio
<RP>
Exception: RuntimeError: This event loop is already running
<JPEW>
Sure, why do you want to nest them?
<RP>
JPEW: in the middle of connect_unix, which is being run in a event loop, how do I force the connect async call to run?
<JPEW>
The AsyncClient.connect() ?
<JPEW>
I think you want `await self.connect()`
<JPEW>
If your already in an event loop (e.g. a `async def` function, you just call await
<RP>
JPEW: that won't allow it to go off and do other things?
<JPEW>
Ah, I see. Yes it would
<JPEW>
Bascially, I don't think you can solve the path length unix domain socket limit with a chdir()
<RP>
JPEW: I think asyncio has some annoying limitations
Vonter has quit [Ping timeout: 260 seconds]
<JPEW>
A few, but it's really the best async option of all the ones out there
<RP>
JPEW: right :/.
<JPEW>
Ah, there might be a simpler way to work around this reading the documentation
<RP>
JPEW: you win though as you have a commit message
<JPEW>
I think non-async connect_unix can actually be completely removed and it can be added to the downcall method list in __init__ also, but I can do that in a later patch
<RP>
JPEW: I did try that but it exploded and I didn't get to the downcall part
<JPEW>
RP: I'll do it later, it's not a big deal
<RP>
JPEW: I'm just happy we have an idea why this was breaking and I don't need an exorcist for the build server :)
<JPEW>
I mean, I know some of those too if you really want to try
<RP>
:D
AkkermT has quit [Read error: Connection reset by peer]
amitk has quit [Ping timeout: 252 seconds]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
florian_kc has quit [Ping timeout: 244 seconds]
goliath has joined #yocto
majoribanksaud[m has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]