<asteiner>
I'm having a problem during packaging for a build where sed is losing the starting / for an absolute path, then the file can't be found. Has anybody seen this before?
<asteiner>
It's in copydebugsources from package.bbclass
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
jclsn has joined #yocto
ErRandir has quit [Ping timeout: 256 seconds]
gho has quit [Ping timeout: 272 seconds]
AntA has quit [Remote host closed the connection]
gho has joined #yocto
seninha has joined #yocto
sakoman has quit [Quit: Leaving.]
amitk has quit [Ping timeout: 252 seconds]
Estrella__ has joined #yocto
ErRandir has joined #yocto
Estrella has quit [Ping timeout: 252 seconds]
Estrella_ has quit [Ping timeout: 252 seconds]
Estrella has joined #yocto
amitk has joined #yocto
seninha has quit [Quit: Leaving]
Herrie|Laptop has joined #yocto
Herrie|Laptop has quit [Ping timeout: 272 seconds]
Herrie|Laptop has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
thomasd13 has joined #yocto
davidinux has joined #yocto
alessioigor has joined #yocto
Herrie|Laptop has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Herrie|Laptop has joined #yocto
barometz has quit [Ping timeout: 252 seconds]
demirok has joined #yocto
leon-anavi has joined #yocto
Herrie|Laptop has quit [Ping timeout: 265 seconds]
frieder has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rob_w has joined #yocto
Herrie|Laptop has joined #yocto
vladest has joined #yocto
lamm1 has joined #yocto
vladest has quit [Read error: Connection reset by peer]
vladest1 has joined #yocto
vladest1 is now known as vladest
Herdinger has joined #yocto
<Herdinger>
Hi, I am currently facing the task where I have to build an image that contains a parametrizable artifact and some derivations of it (shasums etc.)
<Herdinger>
Does anyone have any quick pointers on how to go about it? Passing an abspath to the artififact via variables and using that as SRC_URI maybe?
alessioigor has quit [Remote host closed the connection]
mvlad has joined #yocto
mckoan|away is now known as mckoan
alessioigor has joined #yocto
Herrie|Laptop has quit [Ping timeout: 268 seconds]
<RP>
kanavin: I've not narrowed down the exact cause :/
<RP>
kanavin: could be the i7 tune? :/
<kanavin>
RP: could be, yes. it was core2 before v3, not i7.
<LetoThe2nd>
yo dudX
<RP>
kanavin: I did tweak the patch in master-next to change qemu back to IvyBridge but that didn't help
<qschulz>
moto-timo: mmm actually maybe for esptool recipe it makes sense to not care about faster build times and still build espefuse/espsecure with their python3-cryptography dependency
<qschulz>
moto-timo: and then it's up to downstream or layers to modify the recipe to remove the files in the package to make their build faster?
<RP>
kanavin: I did wonder if there might be issues, so yes, maybe we do need to wait a bit! :)
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
amitk_ has quit [Ping timeout: 265 seconds]
<kanavin>
RP: just a little correction on your revert commit message: qemu usermode is not using kvm, and so doesn't depend on what the host cpu has to offer. but it very does depend on presence of bugs in the instruction translator, known as TCG :)
<RP>
kanavin: right, I was thinking of TCG for usermode
<RP>
kanavin: I'll try and remember to tweak that
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
bps2 has joined #yocto
Herrie|Laptop has quit [Ping timeout: 256 seconds]
yannd has joined #yocto
Herrie|Laptop has joined #yocto
<mcfrisk>
does anyone know how to connect to serial console of a qemu-system-aarch64 machine which was runs testimage.bbclass tests? Have one trivial test which seems to hang the device or slow it down, and sshd isn't responding at all
florian has joined #yocto
<RP>
mcfrisk: I seem to remember netcat and telnet being involved
<mcfrisk>
RP: thanks, I'll try to find the correct combo. I can't reproduce the hang with plain runqemu and manual ssh to target and executing tests. But with oeqa runtime tests the target seems to hang, and tests don't even time out after 17 hours..
Guest8 has joined #yocto
gsalazar has joined #yocto
florian_kc has joined #yocto
Herrie|Laptop has quit [Ping timeout: 252 seconds]
<RP>
kanavin: I reverted a local build to core2-64 and that test passes. With corei7-64, it hangs using 100% cpu :(
<RP>
kanavin: I think I might have to revert to core2-64 and then we can move forward once we figure this out
manuel1985 has joined #yocto
Herrie|Laptop has joined #yocto
d-s-e has joined #yocto
Herrie|Laptop has quit [Ping timeout: 272 seconds]
bps2 has quit [Ping timeout: 246 seconds]
<rburton>
kanavin: thanks, interesting
<rburton>
kanavin: i think maybe they should have called it beta support...
starblue has quit [Ping timeout: 260 seconds]
<RP>
rburton: I just dropped our tune back to core2
<RP>
rburton: elfutils is also in
<rburton>
definitely the right thing to do
<rburton>
awesome
<RP>
and uninative
<rburton>
feel free to fling a failure that hasn't been dug into my way
<kanavin>
"Intel Launches 4th Gen Xeon Scalable "Sapphire Rapids", Xeon CPU Max Series"
<kanavin>
my takeaway is that Intel, too, has mostly given up on 'general purpose computing'
<kanavin>
and we'll be seeing mostly accelerators, e.g. chasing fads via silicon
<kanavin>
and yes, these chips do have the 'enable extra features with a subscription' feature, aka 'BMW's seat heating model'
<LetoThe2nd>
/me inserts a coin to heat kanavins and RPs seat, so you can be comfy during this winter season
<kanavin>
LetoThe2nd, I work at an uncompromising standing desk (no chair or stool). I would appreciated heated floors though, particularly as our neighbours downstairs seem to have moved to Hamburg for good.
<LetoThe2nd>
kanavin: I'm really really sorry, but AFAIK BMW does not offer paid floor heating :-(
<LetoThe2nd>
kanavin: and i actually have a standing desk too but i only raise it for presentation purposes, when body language is important.
<RP>
rburton: UI says it pinged, server doesn't have a record at 12:30 :/
<RP>
rburton: the threading changes should have meant this shouldn't happen
<wyre>
is pythonnative still used? or is that for python2?
<rburton>
wyre: its py2 specific which is why its in meta-python2. modern py uses python3native
<qschulz>
kanavin: it'll be interesting to see what AMD will come up with, because I assume they are the only ones able to make Intel stop this non-sense of licensed CPUs
alessioigor has quit [Quit: alessioigor]
<qschulz>
kanavin: re accelerators... aren't VPUs, GPUs, cryptographic hw blocks, heck DMA, not accelerators?
alessioigor has joined #yocto
olani- has quit [Remote host closed the connection]
<kanavin>
qschulz, sure, but this time in particular it feels like they've run out of ideas for making general purpose computing better
<kanavin>
sequential general purpose computing has been stagnating for years, and for a while it was offset by ever-increasing core counts, but now that has reached its limits too
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
jclsn[m] has joined #yocto
<wyre>
I was trying to build that recipe https://bpa.st/PNIM2 and ... it seems to build, but then when building the python binds, I can see this error https://bpa.st/R7YQO because it doesn't find python
<wyre>
but ... the recipe inherits from python3native 🤔 ... so not sure why I'm having this issue
<rburton>
wyre: the code probably uses python explicitly instead of listening to variables
<rburton>
wyre: also don't use /archive/ github URLs
<rburton>
grab the git repo and use the sha if they don't have proper tarballs
<qschulz>
wyre: mmmmm the makefile are must for calling setup.py... I honestly think you might be better off bypassing this entirely and using setuptools3 bbclass we have?
<qschulz>
at least I would have a look there because I'm not sure it'll be trivial to modify all makefiles to make use of the Yocto native binaries with the proper flags and everything
<qschulz>
(though the recipe won't probably be trivial either)
<rburton>
well, a recipe might be trivial, just build in the right subtree. depends how well written the setuptools is...
<wyre>
I'm going to try by fixing this path in the recipe
KareemZarka[m] has joined #yocto
<qschulz>
the script rburton shared is clearly python2-only code, so I'd rather disable the compilation of those specific modules that are python2-only
<qschulz>
KareemZarka[m]: please try to keep the message small or send your request in multiple messages, otherwise we frolks on IRC just receive a link from Matrix
alessioigor has joined #yocto
<qschulz>
which highly reduces the chances of you getting an answer
<qschulz>
(and also is not nice to web search engines for people looking for the same solution as you (since it'll appear as a link instead of its content)
<qschulz>
KareemZarka[m]: if you're using a release prior to kirkstone (4.0), it'll be RDEPENDS instead of RRECOMMENDS
<KareemZarka[m]>
qschulz: perfect ! thank you
demirok has quit [Quit: Leaving.]
<KareemZarka[m]>
<KareemZarka[m]> "perfect ! thank you..." <- ok so for installing kernel image into roofs its ok , but what about installing it / uninstalling it on the boot partition ?
<qschulz>
KareemZarka[m]: your boot partition, the one used by your bootloader to load your kernel, is it the one in /boot or the one in /run/mnt/boot?
<qschulz>
I assume the latter?
<qschulz>
so technically the boot partition would be the one mounted in /run/mnt/boot and not /boot
<KareemZarka[m]>
qschulz: yes for example ./run/mount/boot/bzImage
<qschulz>
the link I provided gives you the information on how to remove the kernel image from the /boot directory I believe, while keeping it in the boot partition
<qschulz>
I highly suspect that you **need** the kernel in your boot partition
<KareemZarka[m]>
qschulz: yes I would like to achive the other way around
<qschulz>
KareemZarka[m]: you want the image removed from what?
d-s-e has joined #yocto
<qschulz>
if it's from the boot partition, I assume you get a .wic image which you then flash on your device (eMMC or SD card or something else). Find the .wks that is used to build this .wic file and comment/modify the line where you have part /boot --source bootimg-partition
<qschulz>
but I highly doubt this is going to work (except if your bootloader knows it needs to fetch the kernel from within the rootfs instead of the boot partition, which is of course possible :) )
<KareemZarka[m]>
qschulz: The kernel provider deploys the kernel images both as files in boot (via the boot files deployment mechanism) and in the root partition (via the packing system in yocto). so we are having duplication.
<KareemZarka[m]>
My system only uses root for booting so I would like to remove kernel image files from the the boot partition
nemik has quit [Ping timeout: 260 seconds]
Guest8 has joined #yocto
<qschulz>
KareemZarka[m]: ok, that is usually the other way around for people, hence why I insisted on it :)
<qschulz>
KareemZarka[m]: do you need the /boot partition for anything else?
<qschulz>
KareemZarka[m]: do you need anything else in this /boot partition? because otherwise you could just remove it entirely
kscherer has joined #yocto
<KareemZarka[m]>
qschulz: nope. I believe its not used for booting and it can be removed safely
<qschulz>
KareemZarka[m]: are you flashing a .wic image by any chance? how is your final image named/built?
thomasd13 has quit [Ping timeout: 260 seconds]
<KareemZarka[m]>
yes , its Linux oniro-linux-qemux86-64 5.10.152-yocto-standard #1 SMP PREEMPT Wed Nov 2 11:42:00 UTC 2022 x86_64 GNU/Linux
<qschulz>
KareemZarka[m]: I meant the Yocto image, the one you dd onto a flash drive/sd card/emmc :)
olani- has joined #yocto
xmn has joined #yocto
<KareemZarka[m]>
qschulz: good question ... well what i do is simply bitbake the image then using MACHINE=qemux86-64 runqemu IMAGE_NAME wic ovmf slirp nographic
<wyre>
not sure if there is some bbclass for it ... or just setting it as a DEPEND is enough
<qschulz>
KareemZarka[m]: I think you need to create a wks file in the right place in one of your layers with this content: https://paste.ack.tf/6c6926
<qschulz>
then modify WKS_FILE for qemux86-64 machine to the new one
demirok has joined #yocto
lamm1 has quit [Quit: Leaving]
<qschulz>
wyre: I assume you need swig-native and not swig in DEPENDS
<qschulz>
KareemZarka[m]: I removed the part /boot line from scripts/lib/wic/canned-wks/common.wks.inc which is included in scripts/lib/wic/canned-wks/qemux86-directdisk.wks, the default WKS_FILE for qemux86-64
<wyre>
qschulz, is that swig-native to make bitbake to use the swig at the container where bitbake is running? 🤔
<qschulz>
wyre: -native variants of recipes are for binaries supposed to **run** at build time
<qschulz>
(e.g. cmake-native if your build process requires to execute cmake on your host)
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
olani- has quit [Remote host closed the connection]
mark_ has joined #yocto
<KareemZarka[m]>
<qschulz> "Kareem Zarka: I removed the part..." <- I will try it out and let you know , thank you so much
<qschulz>
KareemZarka[m]: good luck, let us know how it went
mark_ has quit [Client Quit]
mark_ has joined #yocto
olani- has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
DarkestFM has joined #yocto
<wyre>
qschulz, I'm agree with the part of bypassing the python makefile and using setuptools3, but I actually have to run the makefile inside swig folder, not the python one
<wyre>
so in this case I cannot use setuptools3, right?
<wyre>
but I think I'm going to try that recipes from the link you pasted 😉
d-s-e has quit [Quit: Konversation terminated!]
<asdf46>
Hey, I'm working on a system with Postgresql and Timescale Db. I got timescale db to compile, but now I need Postgres to have an update to postgres.conf to load the extension and auto start.
<asdf46>
1. How do I update postgres.conf from a recipe?
<asdf46>
2. How do I start and init postgres on startup
<wyre>
rburton, hmm, sorry, that doesn't seem the log 🤔 it's the actual task, I guess
<wyre>
not sure where can I find the log
<rburton>
wyre: that's run.do_compile, the log is log.do_compile
<rburton>
also bitbake shows you the path to it when the task fails
<apteryx>
hi! what's the strategy used by yocto to cross-compile python packages?
<rburton>
apteryx: 99% are python so don't need compiling. the 1% with C code get cross-compiled. Not sure how else to answer that ;)
<apteryx>
OK; when C extensions are involved, the recipe would need to contain package-specific instructions for the cross-compilation?
<rburton>
apteryx: if it uses setuptools or other decent build tools, no
<apteryx>
interesting
<rburton>
hand written makefiles will need hand-written recipes
<apteryx>
so, assuming the 'standard' case (setuptools or pep 517 python build system), there's nothing to take care of for cross-compilation to just work
<asdf46>
I keep getting this error. "ERROR: The artifact that couldn't be found was kernel-dir:" How can a clean the code without rebuilding everything?
<asdf46>
I'm about ready to delete the tmp dir and start over.
<khem>
abelloni_: the busybox error you reported is it with my incremental patch applied ?
Starfoxxes has quit [Ping timeout: 264 seconds]
<abelloni>
nope
<abelloni>
it was from before
<abelloni>
I couldn't apply your patch since I then dropped the upgrade
<khem>
OK then please stage both together
<khem>
since I have fixed the boot issue that I reported and the textrel was actually a good sign to pay attention to since that pointed to the problem which was causing the crash in different applets
<abelloni>
ok
<khem>
its only seen on musl/x86 alone
<khem>
alpine folks are also reporting same problem upstream
Starfoxxes has joined #yocto
amitk_ has quit [Ping timeout: 246 seconds]
olani- has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]