<TRO[m]>
Hi, is there a way to rerun oe-selftest without deleting the build-st dir? For dev purpose...
zpfvo has joined #yocto
bps has joined #yocto
ptsneves has joined #yocto
<kanavin>
TRO[m], oe-selftest -h
xmn has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
florian has joined #yocto
<TRO[m]>
yes, I did read that first - now also the wiki, but I did identify the only might correct parameter is -K to "Keep the test build directory even if all tests pass", but that also will give that error: "...build-st already exists, aborting"
<kanavin>
TRO[m], you can rename the existing build-st dir to something else. I thought you wanted to keep it after successful oe-selftest.
<kanavin>
what's the use case for reusing build-st?
<RP>
TRO[m]: the best way would be just to tweak the code to reuse the directory. We don't have an option for it as we can't gurantee what state a given build directory would be in and we had a lot of odd test failures as a result
<kanavin>
TRO[m], you can make it faster by setting sstate cache somewhere where it would be shared between build and build-st
<RP>
kanavin: we should find a way to allow sharing of sstate by default for this :/. I think the code tries but it isn't perfect
<TRO[m]>
@RP: @kanavin: thank you!
<kanavin>
RP: indeed, oe-selftest could first check where the cache is in the main build, then set build-st to use that
<RP>
kanavin: I think it does work but only if you set SSTATE_DIR directly, not with the default path
<RP>
kanavin: it might be "as simple" as checking if it is a variable path and then pointing at the parent if so
<RP>
TRO[m]: perhaps improving this might be a good step, I did talk a little with megan about some of the challenges you've had :/
<RP>
TRO[m]: I was going to mention in triage yesterday but you had to drop :(
<TRO[m]>
Yes, as said I will have more time next week.
prabhakarlad has quit [Quit: Client closed]
<RP>
TRO[m]: in meta/lib/oeqa/selftest/context.py you'll see a setup_builddir() function. I'd accept a patch which sets SSTATE_DIR in there to match the parent
<TRO[m]>
ok, will look into that
florian_kc has joined #yocto
rfuentess has quit [Remote host closed the connection]
jpuhlman has quit [Read error: Connection reset by peer]
thomas__ has quit [Ping timeout: 252 seconds]
ptsneves has quit [Ping timeout: 250 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
zhmylove has joined #yocto
rob_w has quit [Quit: Leaving]
ptsneves has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
amitk has joined #yocto
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
florian_kc has joined #yocto
goliath has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
<RP>
TRO[m]: let me know if it looks problematic and I can take a look. I agree we should fix this to make it easier for people to be productive
<RP>
We really need to improve hash equiv serve with this too
jtoomey has joined #yocto
ptsneves has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<TRO[m]>
Currently testing - if it's safe to assume that nobody modified the SSTATE_DIR in the parent. We could simply set the build-st to the default of the parent.
<TRO[m]>
brought the test down from 30 to 3 minutes!
<RP>
TRO[m]: sadly it won't be safe to assume that, we make this work on the autobuilder by setting to a common directory in the parent!
<RP>
TRO[m]: nice testing time impovement though :D
<RP>
TRO[m]: maybe check if that directory already exists? or read the value from the parent build?
<TRO[m]>
hmm. you mean parsing parent local.conf or how do I get that var in that environment - I mean it's not an env var...
<RP>
TRO[m]: I'd check if the example in that code, bblayers = subprocess.check_output("bitbake-getvar --value BBLAYERS") is looking in the current builddir or the new one
<RP>
TRO[m]: if it is the old builddir we could use that. If it is the new one, I'm then not sure what to do
<TRO[m]>
ok, will try. thank you!
* RP
is having a day where he feels overwhelmed with too many things to do and therefore gets nothing done :(
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
prabhakarlad has joined #yocto
<TRO[m]>
*sorry for this ;)
<TRO[m]>
But this: bblayers = subprocess.check_output("bitbake-getvar --value BBLAYERS") will end with command not found, I'm trying to get the SSTATE_DIR var by tinfoil - does this make sense? This is giving me the new build-st sstate-dir var?
camus has quit [Remote host closed the connection]
kscherer has joined #yocto
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP>
TRO[m]: where in the function are you running that? You need to run it before it changes os.environ
<RP>
TRO[m]: it isn't failing when it runs it currently I assume so it should work
nemik has quit [Ping timeout: 246 seconds]
<RP>
TRO[m]: you're not what I'm struggling with, this is an easier thing :D
nemik has joined #yocto
Xagen has joined #yocto
|Xagen has quit [Ping timeout: 255 seconds]
<TRO[m]>
yes, that was it - works! :)
seninha has joined #yocto
Guest76 has joined #yocto
amitk_ has quit [Ping timeout: 240 seconds]
<Guest76>
Hi all. I am new to yocto and I am trying to get a recipe for python FastAPI and its dependencies (starlette). There doesn't seem to be one on openembedded index yet but it looks like yet but it seems someone may have submitted a patch to add a recipe before: https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg76295.html Can
<Guest76>
anyone point me to where I would find this recipe and the starlette one it references?
sakoman has joined #yocto
<LetoThe2nd>
Guest76: if you read the title, then you might notice the 3/3, which means its the third of three patches in a series. scroll down, there is the thread tree, and the other two mails are 1/3 and 2/3
<Guest76>
Thank you LetoThe2nd my bad!
<LetoThe2nd>
Guest76: have fun!
<Guest76>
LetoThe2nd thanks also for your useful live streams on youtube, I am still learning and they have been helpful!
<LetoThe2nd>
glad to hear! unfortunately a bit outdated now, need to make new ones. hopefully soon.
<RP>
landgraf: which bug did you put the libgcc/python comment into? I'm struggling to find it :/
<fray>
LetoThe2nd: still planning to do them on twitch?
<LetoThe2nd>
fray: yup
<meego_>
quick question: it's not possible to have conditional class inheritance in recipes, correct? i was hoping to remove gsettings from a recipe's PACKAGECONFIG but this little guy also inhertits gsettings.bbclass, which ends up breaking during postinst
roussinm has joined #yocto
<LetoThe2nd>
it always was a lot of fun, but finding good time is complicated.
<RP>
meego_: it is technically possible but fraught with potential problems as it means immediate expansion of variables
<meego_>
RP: oh that's dangerous. OK thanks for sparing me the bruises. I'll just leave it as it is.
<RP>
TRO[m]: patches look good thanks!
alessioigor has quit [Ping timeout: 255 seconds]
<roussinm>
Is mickledore branch stable enough to be used experimentally until release?
<kanavin>
RP: glibc is something of a mess with y2038. I didn't inspect much of it, but for example its wrapper for ppoll (which is timestamp-sensitive) seems to use 32 bit syscall if time_t fits into 32 bits, and 64 bits otherwise. But if you configure it with 'minimum kernel at least 5.1' then it always uses the 64 bit versions, which seems more reassuring to me.
<RP>
kanavin: presumably they do know what they're doing but I must admit for YP usage, I'd prefer to have it 64 bit everywhere
<RP>
kanavin: glibc does need to support older binaries
<kanavin>
RP: this caused strace and lttng-tools ptests to regress though, which means none of the desktop distros do this, we're the first :-(
<kanavin>
or no one runs on 32 bit platforms anymore except yocto :)
<RP>
kanavin: I guess they both try and intercept the older calls
<kanavin>
RP: no, they regressed even without enabling time64.inc, just from OLDEST_KERNEL change - glibc enables 'new features' if you do that
<kanavin>
gotta run!
<RP>
kanavin: ah, "fun". I doubt people test with such a new old kernel yet
goliath has quit [Read error: Connection reset by peer]
<kanavin>
RP: I just checked, fedora rawhide sets old kernel to 3.2 - same as yocto
<kanavin>
RP: it's a bit wasteful, glibc puts in support for all those new and improved kernel APIs, and no one's enabling that
<kanavin>
----> out
<RP>
kanavin: that isn't quite how it works, at least as I understand it. If you compile a new binary, it should use the newer glibc apis. The oldest kernel piece is whether the older compat code is present or not
* RP
just mentioning that for later when you're back :)
<landgraf>
RP: one of the AB INT ones. I should be CCed
<RP>
landgraf: thanks, I don't know why I couldn't find that :/
<kanavin>
RP: my understanding is that OLDEST_KERNEL controls which kernel APIs glibc would use, specifically that it would avoid using things introduced in newer kernels than that setting.
<RP>
kanavin: I think it can user newer APIs, it would just have fallbacks
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP>
kanavin: I doubt the code is optimised for all cases though
Guest76 has quit [Quit: Client closed]
tunahan has quit [Quit: tunahan]
nemik has quit [Ping timeout: 246 seconds]
tunahan has joined #yocto
nemik has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
xmn has quit [Ping timeout: 255 seconds]
Thorn has quit [Ping timeout: 246 seconds]
xmn has joined #yocto
MathiasKoch[m] has quit [Quit: You have been kicked for being idle]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 264 seconds]
RP has quit [Remote host closed the connection]
RP has joined #yocto
starblue has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
seninha has joined #yocto
Thorn has joined #yocto
florian_kc has joined #yocto
alessioigor has quit [Quit: alessioigor]
ptsneves has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 255 seconds]
amitk_ has joined #yocto
florian_kc has joined #yocto
florian_kc is now known as florian
xmn has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
VasylVavrychuk[m has joined #yocto
bps has quit [Ping timeout: 276 seconds]
applepi has joined #yocto
<applepi>
So I'm working on a yocto image for aarch64, but I have a recipe I absolutely *have* to compile for m32/arm. I've tried bitbaking it as lib32-$RECIPENAME, which seems to almost work, as it calls the right vendor supplied arm compiler, however it fails when it hits a file that #include's <stdint.h>.. it hits a file that just #include_next's
<applepi>
<stdint.h>, and it can't seem to find next. I'm a little confused on how to proceed, any suggestions?
<applepi>
If I go look under work/armv7ahf-neon-xiphosmllib32-linux/lib32-recipename/version#/, there are three places I can find stdint.h. The one that # include_next 's is under ./recipe-sysroot-native, the other two are under lib32-recipe-sysroot
<LetoThe2nd>
zwelch_: without really knowing, just asking the rubberduck way: "disableing the UART, how?"
creich has joined #yocto
<zwelch_>
LetoThe2nd: disabled with `ENABLE_UART = "0"`..... I just found a blog post (https://andrei.gherzan.ro/linux/uboot-on-rpi/) with this little gem of wisdom: "The enable_uart setting is required because U-Boot assumes the VideoCore firmware is configured to use the mini UART (rather than PL011) for the serial console. Without this, U-Boot will not boot at all."
<LetoThe2nd>
zwelch_: yay one more time for using a chip that was designed for a PVR to run the modern world.
<zwelch_>
I'm not going to try to fight it. Our images can live with the UART enabled. I just was following best practice of locking down our production images as much as possible, so everything worked fine for our testing image and only failed in production.
<LetoThe2nd>
zwelch_: yeah, that would have caught me too. fully agreed.
kscherer has quit [Quit: Konversation terminated!]
alejandrohs has quit [Read error: Connection reset by peer]
alejandr1 has joined #yocto
amitk_ has quit [Ping timeout: 248 seconds]
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
osteoblast22[m] has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
<osteoblast22[m]>
Is there something in yocto/oe similar to `filetool` in tinycore linux
<osteoblast22[m]>
but i also want to be able to run some command which will save the writes and persist the changes for next reboot
<osteoblast22[m]>
Basically i want to create yocto image where every write to disk is volatile and in some sort of an overlay
seninha has quit [Ping timeout: 255 seconds]
<osteoblast22[m]>
in tinycore linux there is a tool called filetool which when invoked will create a backup of specifc files that you specify to be persisted, this created backup will be overlayed on next boot
Thorn has quit [Ping timeout: 264 seconds]
seninha has joined #yocto
roussinm has quit [Quit: WeeChat 3.7.1]
invalidopcode1 has quit [Ping timeout: 256 seconds]