dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
RobW has quit [Quit: Leaving]
Spooster has quit [Remote host closed the connection]
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
BobPungartnik has joined #yocto
jpuhlman_ has joined #yocto
jpuhlman__ has quit [Ping timeout: 252 seconds]
<override> any python folks around right now?
<override> khem: what was that about ptest again? I was hoping for the script I shared earlier .. import opentrons shouldve just worked (thats what the package is called), but it didnt..
<override> recipe* not script
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 268 seconds]
hpsy has quit [Ping timeout: 265 seconds]
<Ch^W> override: Not sure if I qualify, but I have done a little python.
Spooster has joined #yocto
Vineela has quit [Quit: Leaving.]
Spooster has quit [Remote host closed the connection]
paulg has quit [Ping timeout: 252 seconds]
Emantor has quit [Quit: ZNC - http://znc.in]
sakoman has quit [Quit: Leaving.]
Emantor has joined #yocto
yates has quit [Ping timeout: 258 seconds]
pung_ has joined #yocto
BobPungartnik has quit [Ping timeout: 265 seconds]
pung__ has joined #yocto
pung_ has quit [Ping timeout: 252 seconds]
rob_w has joined #yocto
goliath has joined #yocto
pbergin has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudX
leon-anavi has joined #yocto
zpfvo has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
goliath has quit [Quit: SIGSEGV]
pung_ has joined #yocto
pung__ has quit [Ping timeout: 265 seconds]
zyga-mbp has joined #yocto
tnovotny has joined #yocto
hpsy has joined #yocto
florian has joined #yocto
tnovotny has quit [Quit: Leaving]
fury has quit [Quit: Connection closed for inactivity]
goliath has joined #yocto
chrfle has quit [Quit: ZNC - https://znc.in]
chrfle has joined #yocto
aeichner has joined #yocto
<rburton> override: ask, don't ask to ask
kayterina has joined #yocto
MysticMice has joined #yocto
<MysticMice> Hey all, is it possible to move around the build folder and still have it functional?
<LetoThe2nd> MysticMice: nope
<dwagenk> MysticMice: don't. Rebuilduing it from SSTATE should take less than 5min
<LetoThe2nd> MysticMice: but you can move SSTATE and DOWNLOADS, and the rest is mostly transient anyways. hint: if it is not, rethink your setup :)
<MysticMice> I see. But, if the compiled files are in the tmp folder, how would/could that take small time?
<MysticMice> My motivation is that, right now, I have the build folder at the same level as the metadata folders. And opening it in a file indexing editor causes it to search inside the build folder :(
<MysticMice> I mean, I just wanted to save a build from scratch.
<LetoThe2nd> MysticMice: the files are not compiled in tmp :)
<LetoThe2nd> or rather, they are, but the results are filled in through sstate if there was no change
<LetoThe2nd> MysticMice: see, thats my i ALWAYS preach to have the build and layers located next to each other
<MysticMice> LetoThe2nd, I see... Thanks! I will try preserving these and see how it goes :)
<MysticMice> in the past, I've already failed once, not too hopeful xD
<LetoThe2nd> this is really no magic. mv downloads somewhere, mv sstate somewhere. set up new build directory, adjust local.conf to use the moved directories, donw.
<LetoThe2nd> if you need to edit more than a handful lines in local.conf (lets say DLDIR, SSTATE, MACHINE, DISTRO, PACKAGE), then you've got a bad setup anyways.
<override> Ch^W: rburton: not sure if youre still around, so I got this recipe going for a package - https://paste.ee/p/73Ir5. seems to be bringing in the package, but a simple import <packagename> fails
prabhakarlad has joined #yocto
cquast has joined #yocto
<override> any debugging steps for modules python cant get o would be much appreciated.. module Im adding using a recipe. the module seems to be sitting in the site-packages dir.
pung__ has joined #yocto
<override> to*
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
pung_ has quit [Ping timeout: 252 seconds]
<LetoThe2nd> override: when does the import happen? at runtime, on the target?
Schlumpf has joined #yocto
<override> LetoThe2nd: i was just doing a ./usr/bin/python3 and then import <packagename> at the python prompt thing
<override> is that what youre asking?
<LetoThe2nd> "the python prompt thing"
<LetoThe2nd> so you're doing that interactively, using an image that you've built?
<override> yep, correct LetoThe2nd
<LetoThe2nd> and the image includes this recipe?
<override> im trying to test the package is working out ok on the board.. I dont know much about the package - just a quick validation test of sorts
<override> yep the image includes it through local.conf
<LetoThe2nd> have you verified that?
<override> and I can see stuff related to the pakcage in site-packages dir
<LetoThe2nd> have you checked that the package contents and its rdepends really are in the image?
<override> yep
<LetoThe2nd> note: adding random stuff through local.conf is a really bad practise.
<override> oh, whats a nicer way of going aboit it then?
<LetoThe2nd> creating a custom image of course.
<override> but yeah, I could see a lot of depencides being shown under site-packages
zyga-mbp has quit [Remote host closed the connection]
<LetoThe2nd> i'm not talking about site-packages.
<LetoThe2nd> i'm always talking about what really is *IN* the image
<override> yeah I mean the image itself when I say that
<override> where else is a good place to confirm the packages got included in the image
<LetoThe2nd> as i'm no python guy its guesswork for me, but my understanding is that the next thing is then to inspect PYTHONPATH and see if it includes the things you expect
<override> i wasnt too sure so I just did find -name
<LetoThe2nd> umm, ls?
<LetoThe2nd> ah "site-packages" is a pythonism probably?
<override> yeah thats how I looked around when I had the image running on the target board
<override> I guess so, I prolly know lesser than you even when it comes to python , yocto etc
<override> how do I inspect yocto variables
<LetoThe2nd> its not about yocto
<LetoThe2nd> we were talking about your image that you are using interactively.
<override> is that what PYTHONPATH is or is that something from env
<override> ok
<override> I can see where that's pointing at - PYTHONPATH
<override> any other hunches you might have?
<LetoThe2nd> *sigh*
<LetoThe2nd> you say it is in your image. good. you says when you try import, it doesn't work. bad. so you have to find out why that is.
<LetoThe2nd> this https://realpython.com/lessons/module-search-path/ suggests that you have to look at the PYTHONPATH
zyga-mbp has joined #yocto
<LetoThe2nd> once you have understood the problem, we can try and fix it in the build process, e.g. yocto. but at the moment the only thing you know for sure is "it is not found"
<override> yeah, thats about all I got right now. Let me fire up the board again and look up PYTHONPATH etc
<override> have to hook it up to my other machine and all so not the most swift process. Ill set all that up and come back with more
<override> LetoThe2nd: well. PYTHONPATH doesnt seem to be set to anything currently - https://pastebin.ubuntu.com/p/rqBNVWx37X/
<LetoThe2nd> override: see the link, and act accordingly
<override> I used setuptools tho for my recipe .. shouldnt that set the path itself?
<LetoThe2nd> i *guess* that it only affects build time.
<LetoThe2nd> but again, i'm no python guy.
aeichner has left #yocto [The Lounge - https://thelounge.github.io]
pung__ has quit [Quit: Leaving]
<override> sys.path seems to be getting to the paths fine - https://pastebin.ubuntu.com/p/GyJckByXzZ/
<override> maybe I dont see the package the recipe shouldve added. hmm..
<LetoThe2nd> you confirmed at least two times that have checked it is there :D
<LetoThe2nd> *you have checked it is
<LetoThe2nd> anyways, lünch
<override> yeah, I was pretty sure
<override> Im trying to see what the package would be called even that the setup.py would create on the target - let me double check
RobertBerger has quit [Quit: Leaving]
rber|res has joined #yocto
<rburton> you don't need to set those on the target
<rburton> step 1: verify that the packaging has done the right thing. oe-pkgdata-util list-pkg-files -p [recipename]
<RP> vmeson, abelloni: I tried all kinds of things with stress-ng and I can't seem to crash two qemus running tests with that locally :/
<rburton> pastebin that
Guest12 has joined #yocto
Guest12 has quit [Client Quit]
Guest5438 has joined #yocto
kayterina has quit [Remote host closed the connection]
<LetoThe2nd> rburton: just like i said. make sure things are in the image :)
<derRichard> poky/meta/recipes-core/ovmf/ovmf_git.bb is only to build ovmf tools, not the uefi firmware itself, right?
<rburton> OVMF is virtual machine firmware
<rburton> it builds the actual firmware
<rburton> there's also edk2-firmware in meta-arm which builds firmware. one day i'll turn all that into a class that can be reused instead of everyone battling with edk2 themselves
<derRichard> let me explain my use case. the sdk ships nativesdk-qemu. i want that the sdk contains also the uefi firmware (for x86) such that i can use the sdk's qemu for a uefi boot
Guest5438 has quit [Quit: Client closed]
<rburton> ovmf sounds about right then
<rburton> its uefi firmware for qemux86-64
<derRichard> this was my thought. but there is no nativesdk-ovmf recipe. so i started wondering
<rburton> you wouldn't want nativesdk-ovmf
<rburton> you want firmware for the target, not the sdk
<rburton> pretend your SDK is running on an arm windows machine
<derRichard> oh yeah, i always mixup this :D
<derRichard> so adding ovmf to TOOLCHAIN_TARGET_TASK should do it?
Spooster has joined #yocto
<rburton> yes
<derRichard> let me check, i thought i tried that first and it failed badly.
kayterina has joined #yocto
williamh89 has joined #yocto
pbergin has quit [Quit: Leaving]
<derRichard> rburton: hmmm. bulding ovmf emits only an efi shell (ovmf-shell-efi_edk2-stable202102-r0_core2-64.ipk) and two empty packages, ovmf-dev_edk2-stable202102-r0_core2-64.ipk & ovmf-dbg_edk2-stable202102-r0_core2-64.ipk
* derRichard digs into
<rburton> it might be just deploying the actual binary, you'll want to package it too
<derRichard> yes, i fear so :)
<derRichard> ah! oh! you pack the firmware as qcow2
<derRichard> o_O
<williamh89> I'm getting an error with yocto regarding recipes with same names in different layers:
<williamh89> Multiple versions of rkwifibt-firmware are due to be built (/meta-rockchip/recipes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb /meta-radxa/recipes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_rkwifibt-firmware to select the correct
<williamh89> version or don't depend on multiple versions.
<williamh89> I tried bumping up the priority of one of the layers
<williamh89> but still getting the same error..
<williamh89> they dont have a version attached haha. how do I tell bitbake which one to take?
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
dtometzki has joined #yocto
fury has joined #yocto
Schlumpf has quit [Quit: Client closed]
williamh89 has quit [Ping timeout: 246 seconds]
<rburton> the default version is 1.0, so set your recipe to version 2? or use a bbappend to adjust the existing recipe instead of providing an alternative
williamh89 has joined #yocto
<override> rburton: cant rembemer if the ,,, is just a malformed PACKAGECONFIG or some syntax thing PACKAGECONFIG[cp2110] = ",,,python3-hidapi"
<rburton> that's fine
<override> what do those commas mean again?
Schlumpf has joined #yocto
mckoan is now known as mckoan|away
ilunev has joined #yocto
sakoman has joined #yocto
camus has quit [Quit: camus]
Schlumpf has quit [Quit: Client closed]
tnovotny has joined #yocto
<override> rburton: whats ptest and why do some packages under meta-python just have that and no recipes? pyserial for instance
Schlumpf has joined #yocto
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton> not sure what you mean by have just ptest and no recipes
<zedd> override. that just means that the bbclass provided defaults work for the standard tasks. So the recipe bb file has variables and the ptest stuff.
<rburton> optional stuff doesnt' need to be listed, classes provide a lot of stuff, and there's a lot of defaults
<rburton> right, it's a level up
<rburton> the folders are for files references by the recipes
<override> oh crap, that was dumb of me.
<override> rburton I havent hit this issue yet, but Im tryin to see if I should even be worried.
<override> or nevermind I just remembered reading somewhere bitbake takes care of the order in which things are built - to take care of dependencies
manuel1985 has joined #yocto
<override> this new recipe I'm wiring might rdepends on package I got done writing a recipe for yesterday
<override> writing*
wesm has quit [Ping timeout: 268 seconds]
Schlumpf has quit [Quit: Client closed]
fury has quit [Quit: Connection closed for inactivity]
kayterina has quit [Remote host closed the connection]
Vineela has joined #yocto
tnovotny has quit [Quit: Leaving]
wesm has joined #yocto
rob_w has quit [Quit: Leaving]
camus has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus has joined #yocto
<JaMa> zedd: ping, "conmon: update to v2.0.29" seems to be missing libseccomp dependency (fails with "src/seccomp_notify.c:9:10: fatal error: seccomp.h: No such file or directory" now)
<zedd> JaMa, odd! I'll have a look. thanks for the heads up.
<JaMa> running local build to see why it fails for me in CI and probably not for you, but the git log in the commit message really looks like it's new dependency
<zedd> my build was incremental in my dev environment, so it could have just rummaged around and found it.
zpfvo has quit [Quit: Leaving.]
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
<JaMa> zedd: it's pulled as systemd dependency when enabled with seccomp in DISTRO_FEATURES
<zedd> ahah.
<zedd> I'm glad seccomp made core, it has become unavoidable.
<JaMa> I'll send a patch to add it to DEPENDS + REQUIRED_DISTRO_FEATURES check to conmon
<zedd> awesome. many thanks.
camus has quit [Remote host closed the connection]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
manuel1985 has quit [Quit: Leaving]
MysticMice has quit [Remote host closed the connection]
cquast has quit [Ping timeout: 258 seconds]
cquast has joined #yocto
cquast has quit [Ping timeout: 250 seconds]
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
<override> rburton: I cant figure where the arch is getting picked up from - https://pastebin.ubuntu.com/p/6cQBgdyHGp/
Guest54 has joined #yocto
<override> ^ or anyone else who's around
<override> any pointers, much appreciated. Thanks
<RP> override: it is saying /work/aarch64-tdx-linux/api/1.0+git999-r0/packages-split/api/usr/lib/python3.8/site-packages/opentrons/resources/scripts/lpc21isp is an arm binary (32bit) and you're building for a 64 bit system
<override> RP: can I just have it not run the make files at all? think its just trying to build something using the make files.. I was hoping the recipe would just run the setup.py
<override> setuptools3 stuff..
<RP> override: I just tried to answer your question, I have no idea about that
<override> got it thanks for answering the question. Appreciate it. The questions leading into some follow up questions.
<RP> vmeson: not sure if you saw earlier but I tried stress-ng loads with qemu images and I can't seem to break it with that, apart from low diskspace issues
<override> ls
Guest54 has quit [Quit: Client closed]
<williamh89> are valid machine names only from the conf/machine/*.conf files?
<williamh89> (does the .inc files count as machines?)
<williamh89> nvm :)
<RP> williamh89: yes and no
<williamh89> sometimes I see in recipes for example: "PACKAGECONFIG_append_rk3399" where the rk3399 is a the chip. but where does the rk3399 come from?
<williamh89> unless it has something to do with the soc-family.inc
<zedd> williamh89: it's an override, of which MACHINE is in default list of valid overrides. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-syntax-overrides
<williamh89> ahh okay I see. There's an inc file that defines SOC_FAMILY = "rk3399" and then in the soc-family.inc has MACHINEOVERRIDES =. "${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}"
<williamh89> and im guessing thats where the overrides is
<williamh89> im not sure what ${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']} is saying/doing though
angolini has quit [Quit: Connection closed for inactivity]
<rburton> override: basically, the makefile or setup.py or whatever is broken. read the compile log, figure out where it decides to pass -m32 instead, and work backwards to fix the makefile
<vmeson> RP I didn't see that. I've been stuck in project mgmt meetings and process - fun!
Saur has quit [Quit: Leaving.]
Saur has joined #yocto
<RP> vmeson, zedd: One difference I notice is the autobuilder qemus don't use MTTR, my local qemu does
zyga-mbp has joined #yocto
<override> how can I go about deleting files from the S directory right after a recipe has fetched all the source from a git repo?
<override> rburton: im trying to get rid of that binary before setuptools etc starts dealing with it .. its for the older target with a different arch
<RP> override: a do_configure_prepend ?
<override> ok nice, lemme try taht
<override> that*
<override> think it ends up in some other dir I cant figure out the varaible for like its not S im guesssing
<override> /work/aarch64-tdx-linux/api/1.0+git999-r0/packages-split/api-dbg/usr/lib/python3.8/site-packages/opentrons/resources/scripts/.debug/lpc21isp
<override> D ?
<override> let go look up the variable doc again - thanks for the thar prepend tip RP
<RP> override: well, you asked about deleting it from ${S}
<RP> if you want to delete it from ${D}, that would be a do_install_append
<override> oh, think it should be S
<override> sorry my heads all over the place
<Ch^W> I did an ldd on the buildtools-extended x86_64-pokysdk-linux-gcc and I see libm.so.6 showing up. I built GCC10 from Hardknott sources (using buildtools-extended), and I do not see libm.so.6 showing up in the resulting compiler - x86_64-mysdk-linux-gcc.
<Ch^W> Did I miss something somehow?
<RP> Ch^W: ldd is probably not using nativesdk's loader
<RP> i.e. I wouldn't trust ldd for that
florian has quit [Ping timeout: 268 seconds]
<fray> all ldd does is turn on an environment variable and run the application. You can do the same yourself by: LD_TRACE_LOADED_OBJECTS=1 <elf binary>
<fray> so in the case of nativesdk, it'll run and SHOULD show you the ld.so it used by default..
<fray> ...but RP is right, if you just run ldd, it may run the wrong loader..
<Ch^W> Lovely...
florian has joined #yocto
<Ch^W> I have been chasing a nasty one and I think it is going to kill me... I have very slowly narrowed it down to: use buildtools-extended to build our SDK VM, boot up SDK VM and try to build gobject-introspection-native, build breaks on a bison segfault. But if I build gobject-introspection with buildtools-extended, it builds just fine.
<Ch^W> I bisected the differences down to gcc, which is not great.
<Ch^W> *gobject-introspection-native
<Ch^W> And the stack trace shows bison breaking on calls to libtextstyle. It does not segfault when I build with buildtools-extended directly.
<Ch^W> I compared logs from both builds, and they appear to be identical.
<RP> Ch^W: i recently saw a conversation about new versions of bison segfaulting in g-i
<RP> rburton: ^^^ ?
<Ch^W> This has the sort of feeling as if it is bigger than just bison. Hard to explain. buildtools-extended GCC10 -> hardknott sources -> GCC10 -> gobject-introspection-native should _not_ be failing.
<fray> did you try back on gatesgarth at all?
<Ch^W> We jumped from thud to hardknott. I switched to the buildtools-extended because I was concerned I was hitting a bootstrapping issue building GCC10 from thud GCC8.
<Ch^W> Currently workaround for the nightly builds is to shim in buildtools-extended.
Dracos-Carazza has quit [Ping timeout: 252 seconds]
<Ch^W> BTW we have open reqs at a (formerly Seattle based) major aircraft manufacturer if anyone wants to work on a Yocto based linux distro project full time.
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cedric has joined #yocto
cedric has left #yocto [Konversation terminated!]
leon-anavi has quit [Quit: Leaving]
<ant_> oes not update
<RP> ant_: I think its been stuck for a while :(
<ant_> just that one...
<Ch^W> Hmmm, buildtools-extended gcc 10 has --enable-default-pie turned on, but my gcc 10 does not. Can you use .so files built with pie turned on in builds with no pie?
agola has joined #yocto
<RP> zedd: happen to be around? Wondering about qemu boot message differences :/
<agola> Looking for someone to discuss about the eclipse plugins for yocto app dev and platform project plugins
fury has joined #yocto
<RP> zedd: https://www.rpsys.net/wp/rp/qemuboot-rp.log vs https://www.rpsys.net/wp/rp/qemuboot-autobuild.log - note the mtrr and local apic address differences, also e820 difference in memory region messages
<RP> zedd: I've tried disabling mtrr but that gives different messages again
<RP> agola: the eclipse plugin was discontinued as there was nobody to maintain it :(
<RP> vmeson: ^^^ in case you're interested
* RP notes paulg has run away
Spooster has quit [Remote host closed the connection]
<agola> Thanks RP I am at Intel, trying to understand what do developers use now for app development and modifying kernels. cli? We have a fork/version of those plugins in-house as part of the oneAPI toolkits : https://software.intel.com/content/www/us/en/develop/tools/oneapi/iot-toolkit.html#gs.43glo2
<Ch^W> agola: I generally fire up the kernel source in VS Code
<Ch^W> Or vim if it is a quickie.
Dracos-Carazza has joined #yocto
<RP> agola: you can use your favourite IDE or editor and just build from the commandline, yes
<RP> zedd: should ACPI tables be aligned in memory? Those offsets also feel a little unusual :/
<RP> abelloni: ^^^ in case you have any thoughts
agola has quit [Ping timeout: 246 seconds]
florian has quit [Ping timeout: 246 seconds]
<RP> difference is the DSDT which changes size and offsets everything
* vmeson follows what's going on with the RP vs qemu wrestling match but is busy with meetings, paperwork, make job server and herding cats
<override> hey RP: I could use some help getting rid of that binary
<override> think it ends up in some other dir I cant figure out the varaible for like its not S im guesssing do_install_append
<override> doesnt seem to work
<vmeson> Despite watching a good LCA talk last night about gtk3 improvemnts in Emacs, I going to jump on the VSCode bandwagon for a while...
agola has joined #yocto
<RP> override: For do_install I'd guess at ${D}${PYTHON_SITEPACKAGES_DIR}/opentrons/resources/scripts/lpc21isp
* RP wonders if anyone here knows anything about ACPI alignment
* RP decides to sleep on it
<override> RP: so_install_append you mean?
hpsy has quit [Ping timeout: 252 seconds]
<override> still craps out, unfortunately
<vmeson> bb
<override> RP: when I delete the binary in do_install it works, but wont that override all the other stuff that does need to happen in do install?
<override> it craps out if I put it under do_install_append