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]
<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>
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>
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?
<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"
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>
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]
<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
<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>
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…]
<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