ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
stevebtc17[m] has quit [Quit: User was banned]
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
sakoman has quit [Quit: Leaving.]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 248 seconds]
Circuitsoft has quit [Quit: Connection closed for inactivity]
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #yocto
sakoman has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
thomasd13 has joined #yocto
sakoman has quit [Quit: Leaving.]
beneth has quit [Read error: Connection reset by peer]
sstiller has joined #yocto
rob_w has joined #yocto
kranzo has joined #yocto
beneth has joined #yocto
F_Adrian has joined #yocto
amitk has joined #yocto
milosv has joined #yocto
rob_w has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
rob_w has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
Schlumpf has joined #yocto
frieder has joined #yocto
zpfvo has joined #yocto
mvlad has joined #yocto
zpfvo has quit [Remote host closed the connection]
zpfvo has joined #yocto
Xagen_ has joined #yocto
Xagen has quit [Ping timeout: 248 seconds]
tomzy_0 has joined #yocto
goliath has joined #yocto
zpfvo has quit [Remote host closed the connection]
zpfvo has joined #yocto
RP has quit [Remote host closed the connection]
Cguer has joined #yocto
<Cguer> Hello everyone:)  Hope you are well. I'm wondering how i can add anonymous python function in bblayers.conf. The main reason of this question is because i would like to check with an if statement if a path exist, and if not, adding a new path to a variable.
<Cguer> It is for the BSPDIR variable.
RP has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
milosv has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
<mcfrisk> memory and io pressure detection in bitbake to reduce new tasks is good, but what is the kernel configuration and version needed for this? On my Debian LTS machines I don't have /proc/pressure
nemik has joined #yocto
ptsneves has joined #yocto
prabhakarlad has joined #yocto
<landgraf> config_psi it is
<mcfrisk> when was this introduced, which LTS/stable kernel?
leon-anavi has joined #yocto
<mcfrisk> "PSI is included in Linux kernel versions 4.20 and up. If building your own kernel, make sure CONFIG_PSI=y is set in the build configuration." from https://facebookmicrosites.github.io/psi/docs/overview
<mcfrisk> this IMO should have been in the bitbake commits, sigh. Debian 10 uses 4.19 kernel. Maybe some others too. I hope bitbake doesn't explode with /proc/pressure isn't available..
<qschulz> mcfrisk: isn't buster EOL?
<qschulz> mcfrisk: supposed to be this month: https://wiki.debian.org/DebianReleases
<qschulz> mcfrisk: but that seems like a good argument for not backporting (if not already done?)
<qschulz> and remove buster (and other distros with old kernels) from supported distros for master branch?
<qschulz> or improve checks around /proc/pressure presence
fenrig has joined #yocto
florian has joined #yocto
tre has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
<bigendian> hi. using some EXTRA_OECONF += in a wolfssl bbappend. Should cross-compile for aarch64, Btw, compiling, seems some x86 assembly code is processed in /usr/include/bits/select.h
<landgraf> qschulz: or switch to gentoo and cook your linux yourself (sorry for offtopic)
* landgraf doesn't have /proc/pressure either. need to recompile the kernel
<bigendian> Is it possible EXTRA_OECONF breaks the cpu/arch type ?
zpfvo has joined #yocto
<RP> mcfrisk: it doesn't explode, no, just can't use it
Karsten[m]1 has quit [Quit: You have been kicked for being idle]
Perceval[m] has quit [Quit: You have been kicked for being idle]
tomzy_0 has quit [Quit: Client closed]
Schlumpf has quit [Ping timeout: 252 seconds]
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
Guest61 has joined #yocto
Guest61 has quit [Client Quit]
Cguer has quit [Quit: Connection closed]
denisoft81 has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 248 seconds]
camus1 is now known as camus
ardo has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
ardo has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<rburton> bigendian: possibly, easily tested by changing to EXTRA_OECONF:append (or just removing the bbappend)
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
fenrig has quit [Quit: Client closed]
denisoft81 has quit [Quit: Leaving]
Schlumpf has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
gsalazar has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
seninha has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
xmn has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
<agherzan> How do you guys handle cases where you want to remove things from world based on required feature?
<agherzan> I'm asking because when you have a dependency of a package that is specific to a feature while the package(s) depending on it don't, world will fail.
<agherzan> A(requires foo feature) <-B<-world
<RP> agherzan: usually have the recipe SkipRecipe if it can't build?
<RP> i.e. it shouldn't available in world if it can't build
<agherzan> The problem is B needs A which needs distro feature X. But B itself doesn't need distro feature X
<agherzan> Is the general workaround to add a feature req to B as well?
<agherzan> Looks a bit artificial but I can't see what else we can do
<RP> agherzan: it is a hard problem, not an easy answer. Common .inc file shared maybe?
<agherzan> distro feature check does in turn SkipRecipe so yes, I'm basically asking if this is the only workaround at this point
<agherzan> I'm not sure how an inc file would help here.
<agherzan> On. For the entire dep chain
<RP> agherzan: You could code the knowledge of the feature in one place instead of two recipes
<agherzan> Gotcha yeah. Where would that reside when you cross layers for example?
<agherzan> Or even when you cross recipe-foo namespaces
<RP> agherzan: you can put paths in include names so in a layer is ok
<RP> cross layer you could make it an optional include I guess
<agherzan> Makes sense. I was curious how we workaround it at this point
<agherzan> It is indeed a hard problem
<RP> agherzan: I've not seen the above done, I just think it could work
<agherzan> Maybe we should make world ignore any dep paths that has a restriction base on something
<agherzan> based*
<agherzan> so if you have any dependency (in the dep chain) that requires a feature not available, skip this recipe too
<RP> agherzan: The risk is thing silently disappearing. It is a piece of code I don't really want magic in
zpfvo has joined #yocto
<agherzan> I'm thinking out loud to be honest but it doesn't like the worst idea
<agherzan> Besides that, yes
<agherzan> Silent skips are annoying
<RP> agherzan: magic like that has very poor failure modes
<agherzan> I know. I'll think about it
<agherzan> Thanks for confirming my approach here
<agherzan> I'll go a fix meta-java with this
xmn has quit [Quit: ZZZzzz…]
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
Cguer has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
Cguer has quit [Quit: Connection closed]
brazuca has joined #yocto
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
Austriker has joined #yocto
Austriker has quit [Quit: Client closed]
brazuca has quit [Quit: Client closed]
kranzo has quit [Quit: Client closed]
cambrian_invader has quit [Ping timeout: 268 seconds]
seninha has quit [Ping timeout: 268 seconds]
tre has quit [Remote host closed the connection]
Schlumpf has quit [Quit: Client closed]
<Alban[m]1> Hi! Building cmake-native on Ubuntu 22.04 with uninative fails because of some libstdc++ missmatch: bin/cmake: /home/..../build/tmp-glibc/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by bin/cmake)
<Alban[m]1> The host system has libstdc++ 3.4.30 but uninative only support up to 3.4.29. Any idea why that is happening? Look like there is some contamination from the host system happening
<Alban[m]1> This is with hardknott
sakoman has joined #yocto
rob_w has quit [Remote host closed the connection]
barometz_ is now known as barometz
thomasd13 has quit [Ping timeout: 248 seconds]
goliath has quit [Quit: SIGSEGV]
sstiller has quit [Remote host closed the connection]
xmn has joined #yocto
JaMa has joined #yocto
BWhitten has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
gsalazar has joined #yocto
wkawka has joined #yocto
brazuca has joined #yocto
<BWhitten> Hi all, I'm having trouble with overrides and weak assignments to the SRC_URI of a recipe. I am trying to override in my local.conf so that it looks at a local checkout of some source instead of the recipe location, but I'm getting unstuck because of machine overrides in the recipe that appear to take precedence. My best attempt so far has been an immediate assign := in local.conf at the pn_${PN} level, then in the recipe a first weak
<BWhitten> assign ?= at the machine level then patches append at machine level. But the weak assignment doesn't yield to the previous immediate and it gets overwritten
zpfvo has joined #yocto
wkawka has quit [Quit: Client closed]
<qschulz> BWhitten: SRC_URI:machine:pn-${PN} = "whatever" ?
brazuca has quit [Quit: Client closed]
<qschulz> BWhitten: I might be very tired but it is difficult for me to understand the whole context, is it possible to share the actual code? e.g. the SRC_URI lines from the recipe and what you're putting into your local.conf and what you expect to happen and what actually happens?
<zeddii> has anyone noticed on-target applications not doing ncurses/curses like drawing properly ? I'm trying to sort out a tui issue, and I'm plagued by ??? instead of lines. I've tried every sort of TERM type export I can think of. nothing.
<BWhitten> qschulz, I didn't appreciate you could chain them like that, that splats over everything but a step in the right direction. Sure I'll pop something into pastebin
vin[m] has quit [Quit: You have been kicked for being idle]
alimon has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
kevinrowland has joined #yocto
kevinrowland has quit [Client Quit]
<BWhitten> qschulz, here we go https://pastebin.com/jc7sPf90
<qschulz> BWhitten: yup, works as expected
<qschulz> but I guess you want to keep the patches
<qschulz> BWhitten: so I recommend using :remove instead
<qschulz> BWhitten: SRC_URI:mx8m-generic-bsp:remove:pn-fb5-uem = "extrepo" and then SRC_URI:mx8m-generic-bsp:append:pn-fb5-uem = " localrepo"
<qschulz> although, I think you could create a bbappend which inherits externalsrc and points to your local directory
<qschulz> I think it may not do anything with the SRC_URI variable then
<qschulz> (I mean, devtool leverages externalsrc recipe IIRC for modifying recipe source code locally, don't know if it messes with SRC_URI also)
<BWhitten> qschulz, that could be an interesting way to do it Yeh its just like the devtool approach sans patching
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 256 seconds]
alimon has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
<smurray> khem: your tweak to the audit for 5.17+ seems to end up installing a broken header file, I'm seeing the SELinux bits fail to compile since the #include "audit.h" ends up in the installed libaudit.h...any ideas on what a fix would be?
<smurray> err, tweak to the audit recipe
zpfvo has joined #yocto
frieder has quit [Remote host closed the connection]
<khem> is selinux using vendored audit package ?
<khem> perhaps the tweak should be undone after do_compile
<smurray> khem: yeah, I think it needs to be undone or maybe using something like --include with a temp copy
<smurray> khem: I'm a bit surprised the RedHat folks haven't hit the issue wrt swig
pabigot has joined #yocto
<khem> Can you try this fix http://sprunge.us/PV3dVJ
<khem> smurray: this should fix the problem I think for you
<smurray> khem: that does fix libsemanage, looks good
prabhakarlad has joined #yocto
prabhakarlad has quit [Client Quit]
prabhakarlad has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
<khem> thanks smurray I will send it to ml
<smurray> khem: thanks for the quick response!
<smurray> sadly I'm now seeing a lttng-tools build failure that seems different than what I can find
adams[1] has joined #yocto
<adams[1]> Exception: bb.fetch2.FetchError: Fetcher failure: Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).
<khem> OK whats the error like ?
<adams[1]> wondering what I am doing wrong..
<adams[1]> SRCREV_Abc-linux-xyz ?= "${AUTOREV}"  i have this set in my bb file
<smurray> khem: I wonder if it's maybe sensitive to kernel configuration? We supply some fragments in AGL, but other than that this is with linux-yocto from poky
<khem> smurray: Do you have CONFIG_KALLSYMS_ALL enabled ?
<khem> if not enable it
<khem> this function is guarded by this define
<khem> but it seems a bug to me that definition is guarded
<smurray> no, it's not set in the final .config we end up with
<khem> but use is not guarded by same define
<smurray> yeah, that seems bogus
<khem> where it started to use it if kernel is 5.18+
<smurray> khem: good call, CONFIG_KALLSYMS_ALL=y avoids it
<smurray> khem: I'll try cooking up a patch for upstream, I guess
<zeddii> is just my searching of the docs that is off .. or do we have nothing much for the locales ?
<khem> I guess consistency would be good in definition and use places
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
Circuitsoft has joined #yocto
<RP> zeddii: I suspect we might not have
<zeddii> in the end, I don't think it is my issue. but I was trying to rule it out.
<zeddii> one of the ncurses like shells can't draw some of the lines .. ??? everywhere. smells like the old Kconfig issues, but this is a go application, so it can't be the same ncurses mess.
<zeddii> I'm just removing it from my ELCe demo portion and moving on for now :)
<RP> zeddii: I don't know much about any of that
<zeddii> yah. me either.
<zeddii> I've flailed long enough. have NFI why they don't draw properly
<RP> zeddii: terminfo missing?
<zeddii> what's that come from ? layers.openembedded.org points at ncurses hmmm. so it should be there.
<zeddii> I did a native build on my server (ubuntu builder) and it was messed up as well
<zeddii> until I did: export LC_ALL="en_CA.UTF-8"
<zeddii> then it draws.
<zeddii> which makes me think I need to dive back into locales, but grepping was failing me earlier.
<zeddii> since I get this on the target:
<zeddii> root@qemux86-64-c9:~# export LC_ALL="en_CA.UTF-8"
<zeddii> -sh: warning: setlocale: LC_ALL: cannot change locale (en_CA.UTF-8)
florian_kc has joined #yocto
<RP> zeddii: You'd need IMAGE_LINGUAS += "en-ca" for that I think
brazuca has joined #yocto
<zeddii> I was just reading about that in the docs.
<zeddii> and I just confirmed it is empty by default in my build by dumping the env
<RP> zeddii: took me far too long to pull "linguas" out my cache
<RP> classes-recipe/image.bbclass:IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
<zeddii> heh. I found it by looking at the git history of the libc-package class
<RP> nobody has ever complained it was en-gb and not en-us :)
<zeddii> :D
<zeddii> I see the default, but since I'm building a variant of core-image-minimal with a lot of junk tossed in, it gets cleared.
* zeddii sets it in the local.conf for now
<zeddii> well bugger. the image just rebuilt and did nothing. clearly that isn't going to change anything :)
<RP> zeddii: for minimal it is probably cleared
<zeddii> I can forcevariable it for now, my += was not the right thing.
* zeddii notes something is happening this time at least.
<zeddii> hahah!
<zeddii> needed the locale, and b) not to be run under screen.
<rfs613> zeddii: if it helps any... on my target I have LC_ALL undefined, the other LC_* are all "C", and LANG=C. And ncurses test program correctly displays line-drawing characters.
<zeddii> it's definitely funky to get it right. standard ncurses stuff was fine. cfdisk, etc, but not this.
<rfs613> however my config does have (evenidently by default) IMAGE_LINGUAS="en-us en-gb"
<zeddii> that does seem to be the differentiator. some locale. I got lost in the go code to understand exactly what it was using, but at least I have an initial working set of steps now.
<rfs613> my IMAGE_LINGUAS is coming from poky/meta/conf/distro/include/default-distrovars.inc
<zeddii> yup. unless you use the minimal images, etc, they clear it.
<rfs613> how we've managed to make simple things complicated, eh? :P
<RP> who'd have thought a minimal image wouldn't have things in it? :)
<RP> to be honest, locales should have moved over to an image feature
<kergoth> good idea
odra has joined #yocto
<khem> zeddii: use core-image-base generally perhaps avoids some of these issues
<khem> core-image-minimal is really as the name suggests 🙂
<zeddii> not for what I'm trying to demo, but yes, I realize there are options.
Minvera has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Maxxed has joined #yocto
adrian_ has joined #yocto
F_Adrian has quit [Ping timeout: 248 seconds]
adrian__ has joined #yocto
leon-anavi has quit [Quit: Leaving]
adrian_ has quit [Ping timeout: 256 seconds]
dev1990 has joined #yocto
<adams[1]> error: build_directory_structure: unknown file type on dev/console -- wondering if anyone knows who populates /dev in yocto as I haven't even enabled devtmpfs using USE_DEVFS=1.....
cambrian_invader has joined #yocto
adams[1] has quit [Quit: Client closed]
<yudjinn[m]1> I'm trying to build `flatbuffers` and the cmake "build" step works correctly. it also installs to an "image" folder in the project dir, but then it only moves the /usr/lib into the sysroot-components, not the /usr/bin
<yudjinn[m]1> any thoughts? its a step after `do_install` but I dont understand why its not bringing the other install artifacts
<khem> adams[1]: sometimes its created in initramfs-framework if you are using that recipe or in device_table in image during rootfs creation
<khem> yudjinn: it generally brings developement headers and libs from a dependent component in recipe sysroot generally
<khem> it seems you also need some tools if so then see if you can use a native version of recipe to generate these tools and use them
<yudjinn[m]1> I need to build a recipe that needs `flatc` which is built by flatbuffers. but I also need flatbuffer's libs available on the target
florian_kc has quit [Ping timeout: 248 seconds]
<yudjinn[m]1> ill try native though
adams[1] has joined #yocto
seninha has joined #yocto
Minvera has quit [Ping timeout: 248 seconds]
olani has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
vladest has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
vladest has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
vladest has joined #yocto
<yudjinn[m]1> I think the problem I mostly having is that I have a recipe A that needs project B as a dependency. So I have a recipe for B that builds it. I list B as a DEPENDS in recipe A. In the CMakeLists for project A, I use the syntax `find_package(flatbuffers)` but it is unable to find them.
florian_kc has quit [Ping timeout: 248 seconds]
vladest has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
brazuca has quit [Ping timeout: 252 seconds]
mvlad has quit [Remote host closed the connection]
florian_kc has joined #yocto
olani has quit [Ping timeout: 256 seconds]
olani has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
adams[1] has quit [Quit: Client closed]
Herrie has quit [Ping timeout: 268 seconds]
dev1990 has quit [Quit: Konversation terminated!]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
chep has quit [Quit: ZNC 1.8.2 - https://znc.in]
chep has joined #yocto
Herrie has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
seninha has quit [Remote host closed the connection]