<JPEW>
Seems like the local data isn't making it into the image because /usr/share/i18n/ doesn't exist
<JPEW>
*locale data
vd has quit [Ping timeout: 256 seconds]
<JPEW>
GOing to see if adding `glibc-locale-localedata` to the image helps
troth has quit [Ping timeout: 256 seconds]
chep has quit [Ping timeout: 260 seconds]
chep has joined #yocto
troth has joined #yocto
sakoman has quit [Quit: Leaving.]
troth has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
troth has joined #yocto
troth has quit [Ping timeout: 246 seconds]
vd has joined #yocto
troth has joined #yocto
landgraf has quit [*.net *.split]
yolo_ has quit [*.net *.split]
Ch^W has quit [*.net *.split]
yolo has joined #yocto
Ch^W has joined #yocto
landgraf has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
neverpanic has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
rperier has quit [*.net *.split]
Shaun has quit [*.net *.split]
alex88 has quit [*.net *.split]
derRichard has quit [*.net *.split]
woky_ has quit [*.net *.split]
jsandman has quit [*.net *.split]
Shaun has joined #yocto
alex88 has joined #yocto
Shaun has quit [Changing host]
Shaun has joined #yocto
rperier has joined #yocto
mcfrisk has joined #yocto
jsandman has joined #yocto
derRichard has joined #yocto
woky has joined #yocto
neverpanic has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
alessioigor has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
alessioigor has quit [Client Quit]
troth has quit [Ping timeout: 260 seconds]
kroon has joined #yocto
Vonter has joined #yocto
troth has joined #yocto
adrian__ has joined #yocto
goliath has joined #yocto
rob_w has joined #yocto
manuel1985 has quit [Quit: Leaving]
tre has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
chep has quit [Ping timeout: 260 seconds]
camus has quit [Remote host closed the connection]
camus has joined #yocto
mithro has quit [Ping timeout: 246 seconds]
NishanthMenon has quit [Ping timeout: 246 seconds]
NishanthMenon has joined #yocto
chep has joined #yocto
mithro has joined #yocto
rfuentess has joined #yocto
zpfvo has joined #yocto
vd has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
adrian_ has joined #yocto
adrian__ has quit [Ping timeout: 260 seconds]
tnovotny has joined #yocto
bps has joined #yocto
bps has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
fleg has joined #yocto
fleg has quit [Remote host closed the connection]
Guest77 has joined #yocto
fleg has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 264 seconds]
camus1 is now known as camus
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
hjones2199[m] has quit [Quit: You have been kicked for being idle]
adrian_ has quit [Ping timeout: 245 seconds]
lucaceresoli has joined #yocto
xtopher_ has quit [Ping timeout: 264 seconds]
rhadye has quit [Ping timeout: 268 seconds]
moto-timo has quit [Ping timeout: 268 seconds]
bradfa has quit [Ping timeout: 268 seconds]
Crofton has quit [Ping timeout: 268 seconds]
rburton has quit [Ping timeout: 268 seconds]
mithro has quit [Ping timeout: 245 seconds]
cengiz_io has quit [Ping timeout: 250 seconds]
rsalveti has quit [Ping timeout: 250 seconds]
dagmcr has quit [Ping timeout: 250 seconds]
YogeshSiraswar_ has quit [Ping timeout: 265 seconds]
smurray has quit [Ping timeout: 265 seconds]
rmmr has quit [Ping timeout: 246 seconds]
flynn378 has quit [Ping timeout: 246 seconds]
aeroraptor has quit [Ping timeout: 260 seconds]
thierryE has quit [Ping timeout: 268 seconds]
armpit has quit [Ping timeout: 250 seconds]
Tartarus has quit [Ping timeout: 250 seconds]
CosmicPenguin has quit [Ping timeout: 246 seconds]
jamestperk has quit [Ping timeout: 265 seconds]
georgem has quit [Ping timeout: 265 seconds]
ldts has quit [Ping timeout: 265 seconds]
NishanthMenon has quit [Ping timeout: 250 seconds]
halstead has quit [Ping timeout: 250 seconds]
paulbarker has quit [Ping timeout: 268 seconds]
nohit has quit [Ping timeout: 268 seconds]
drewfustini_ has joined #yocto
jonmason has quit [Ping timeout: 268 seconds]
armpit has joined #yocto
thierryE has joined #yocto
paulbarker_ has joined #yocto
ldts has joined #yocto
georgem has joined #yocto
smurray has joined #yocto
jonmason_ has joined #yocto
darknighte_ has joined #yocto
jamestperk has joined #yocto
CosmicPenguin has joined #yocto
dl9pf_ has joined #yocto
ernstp_ has joined #yocto
halstead has joined #yocto
drewfustini has quit [Ping timeout: 260 seconds]
awafaa has quit [Ping timeout: 260 seconds]
madisox_ has joined #yocto
darknighte has quit [Ping timeout: 265 seconds]
dl9pf has quit [Ping timeout: 265 seconds]
ernstp has quit [Ping timeout: 265 seconds]
jmiehe has joined #yocto
rmmr has joined #yocto
dl9pf_ is now known as dl9pf
drewfustini_ is now known as drewfustini
ernstp_ is now known as ernstp
darknighte_ is now known as darknighte
madisox_ is now known as madisox
madisox has quit [Ping timeout: 264 seconds]
ndec_ has joined #yocto
elfenix|cloud has quit [Ping timeout: 268 seconds]
ndec has quit [Ping timeout: 268 seconds]
ndec_ is now known as ndec
fancer has quit [Ping timeout: 265 seconds]
dagmcr has joined #yocto
nohit has joined #yocto
NishanthMenon has joined #yocto
mithro has joined #yocto
Tartarus has joined #yocto
cengiz_io has joined #yocto
rsalveti has joined #yocto
flynn378 has joined #yocto
Crofton has joined #yocto
awafaa has joined #yocto
fancer has joined #yocto
elfenix|cloud has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
xtopher_ has joined #yocto
rhadye has joined #yocto
rburton has joined #yocto
bradfa has joined #yocto
moto-timo has joined #yocto
aeroraptor has joined #yocto
YogeshSiraswar_ has joined #yocto
<kanavin>
RP: perhaps there can be a buildbot ticket to propose ability to specify weeks (by their number)? then it's elegantly solved with week=range(1,52,2), dayofweek=6
<RP>
kanavin: the native/cross reproducibility isn't as easy as it sounds as the native compiler can and will be different
<ernstp>
so Pseudo abort on rm -rf packages-split in the cleandirs step before do_package
<kanavin>
RP: right, didn't think of that :-/ but at least it can be made reproducible on the same host
<RP>
ernstp: if you remove the file, you should be removing the entry from the pseudo db so I don't think that is right at all
<RP>
kanavin: right, we should test that we get deterministic results for rebuilding native/cross recipes on a given host
<ernstp>
RP: pseudo is complaining about two hardlinked files having the same inode number
<kanavin>
RP: I wonder if in the future we can offer a hard reproducibility option, on the condition that it involves building gcc-native
<kanavin>
not now though :)
<RP>
kanavin: that is effectively buildtools-tarball-extended ;-)
<kanavin>
hah!
<RP>
kanavin: basically you'd just have to check everything in HOSTTOOLS comes from the tarball
<RP>
ernstp: I can see how that patch makes the error go away but the real question is how the database is "corrupted" in the first place
<ernstp>
RP: I get it.
<RP>
kanavin: btw, was there issues with the go upgrade? I think there was a patch a while back but it was never rebased?
<RP>
kanavin: There are 3 CVEs in go atm out of 10 in OE-Core currently
<kanavin>
RP: yes, I asked the submitter to resend and they never responded. The good news is that I am about to start getting paid to make go support shine :)
<RP>
nasm, libarchive and qemu don't have patches, rburton is on the gmp one
<kanavin>
that's why I did anything yet :)
<kanavin>
*didn't do
<RP>
kanavin: sounds good, you love a challenge :)
<ernstp>
RP: it fetches the source code with PSEUDO_DISABLED. And I got the error on package/usr/src/debug/tcp-wrappers/7.6-r10/tcp_wrappers_7.6/diag.c for example
<RP>
ernstp: everything up to do_install is done without pseudo
<ernstp>
RP: can you point me in the right direction to find where tmp/work/cortexa7t2hf-neon-fslc-linux-gnueabi/tcp-wrappers/7.6-r10/pseudo/ is cleaned?
<RP>
ernstp: it isn't, that is dangerous :/
<ernstp>
RP: oh...
<ernstp>
that's why I didn't find it :-)
<RP>
ernstp: I just had a look at a tcp-wrappers build locally and the files in ${S} aren't in my pseudo DB. This is with master though
<RP>
ernstp: I can "bitbake tcp-wrappers -c package -f" which should do what you describe in the bug and I don't see any abort
<ernstp>
RP: i did a build, worked fine, enabled "GCC section removal", built again, fail when cleaning the old packages-split (from the previous run I guess) before do_package
<RP>
ernstp: which host OS is this?
<ernstp>
RP: ubuntu 18.04, ext4 fs
<RP>
ernstp: do you know if it is a totally standard ubuntu 1804?
<ernstp>
RP: it's not, running in Azure. like the extra horsepower when rebuilding everything...
<RP>
ernstp: I'm wondering if there is some syscall we're not intercepting :/
<RP>
ernstp: can you dump out a copy of the pseudo database after building tcp-wrappers successfully?
<RP>
ernstp: I'd like to understand the pattern of files contained in it
<ernstp>
RP: ok
<RP>
I just checked a dunfell build and the pseudo database there for tcp-wrappers doesn't have ${S}/diag.c either but your database does for some reason
<RP>
ernstp: ok, so there are a load of things not making it into the pseudo database. This means there is some kind of syscall on that platform which we're not intercepting
<ernstp>
RP: it happened on my Ubuntu 20.04 laptop now also
<ernstp>
path mismatch [2 links]: ino 9217867 db '/home/ernsjo/code/cu1/build/tmp/work/cortexa7t2hf-neon-fslc-linux-gnueabi/glibc/2.31+gitAUTOINC+f84949f1c4-r0/package/usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/build-arm-fslc-linux-gnueabi/stdio-common/errlist-compat.c' req
<ernstp>
the CFLAGS_SECTION_REMOVAL variable doesn't do anything on its own...
<ernstp>
if I check tmp/work/x86_64-linux/pseudo-native/1.9.0+gitAUTOINC+60e25a3655-r0/temp/log.do_compile it wasn't compiled with -ffunction etc...
<RP>
ernstp: I don't know then. I am very suspicious that pseudo seems to be missing intercepts and file coverage looks wrong
MauroAnjo has joined #yocto
<RP>
ernstp: I think you need to start a fresh build without sstate and without these changes and see if you can get a more normal looking pseudo database files list for tcp-wrappers
<RP>
ernstp: then add changes back and see what triggers it
<RP>
kroon: the intercept patches are interesting. I was wondering if we can reduce the fork overhead in them?
<RP>
ernstp: I'm not sure the xattrdb stuff works :/
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
chep has joined #yocto
<ernstp>
RP: xattrdb is only performance right? Just xattr should be enough for all the features?
<RP>
ernstp: I'm not even sure it performs better but yes, effectively
<RP>
you do just want xattr
<kroon>
RP, yeah that is something we can improve on
<RP>
kroon: much as I hate intercepts, I think we may have little choice htere
<kroon>
RP, ill check how many times those wrappers are invoked during on of my image builds
<kroon>
RP, *nod*
<RP>
kroon: it may be cheaper to just invoke python to do things for example
vd has joined #yocto
<kroon>
RP, yes, although i'd guess starting up python does not come for free..
<kroon>
but i have no statistics to back up any reasoning, wether it should be a shell script, python script or a C application
<RP>
kroon: experience says that "fork overhead" is one of our bigger slowdowns so whilst python isn't free, it may still be faster to have the one exec that those pipelines :/
<marex>
khem: seems if I build the chromium with meta-clang/dunfell (on oe-core dunfell) , it fails as described
<marex>
khem: seems if I build the chromium with mildly tweaked * meta-clang/honister (on oe-core dunfell) , it works as it should
<marex>
(* means patch to conf/layer.conf to make dunfell supported again, and dropped busybox bbappend)
<marex>
khem: so ... why would the upgrade of clang "fix" the chromium ?
sakoman has joined #yocto
MauroAnjo has joined #yocto
<MauroAnjo>
Hello! I'm trying to build poky honister for raspberrypi0-2w-64 and currently got stuck when it starts to build meta/recipes-graphics/cairo when linking the lib with -lbrcmEGL and -lbrcmGLESv2 , it states that they were not found ( cannot find -lbrcmGLESv2 and cannot find -lbrcmEGL )
rob_w has quit [Ping timeout: 245 seconds]
<dwagenk>
Hi there. Anyone familiar with this error message when installing extsdk:
<dwagenk>
/path/to/sdk/sysroots/x86_64-tqsdk-linux/usr/bin/python3: line 5: /path/to/sdk/sysroots/x86_64-tqsdk-linux/usr/bin/python3.9.real: No such file or directory
<dwagenk>
the offending line from that script looks like this: exec -a "$0" $realdir/python3.9.real "$@"
zyga has joined #yocto
<dwagenk>
the file actually exists. The sdk installation also seemingly succeeds anyhow (gives the "SDK has been successfully set up and is ready to be used." message) and sourcing the env setup script works fine. Any invocation of devtool then fails with a similar error message:
<dwagenk>
/path/to/sdk/sysroots/x86_64-tqsdk-linux/usr/bin/python3.9: 5: exec: -a: not found
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
<dwagenk>
To me it seems like this scipt is either messed up or some substitution during the sdk install messes up the script. Haven't found anything about a "-a" flag in the man pages for exec (1).
rob_w has joined #yocto
<dwagenk>
Is this a known bug? I will try to reproduce with a minimal setup throwing out the external layers.
<moto-timo>
wyre: the pain point is with pyo3 (python bindings for rust), which 'fastcrc' uses as well
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<moto-timo>
JPEW: do your zuul builds include your crates patches? I'm not able to build with latest tip
<moto-timo>
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception NoMethodError: Could not find a fetcher which supports the URL: 'crate://crates.io/atk-sys/0.9.1'
rob_w has quit [Remote host closed the connection]
<moto-timo>
rburton: at least on my system, I need to guess at where to be (lower and to the left) to get it to work
<moto-timo>
rburton: the rpi4 build is as expected, no issues. so it's something specific to qemu (or perhaps my host configuration)
camus1 has joined #yocto
camus has quit [Ping timeout: 264 seconds]
camus1 is now known as camus
<alex88>
it seems that systemd-timesyncd is broken in last release (if you're using ipv6), anyone uses anything else that they can recommend? (other than disabling ipv6 which seems to cause issues anyway)
<alex88>
nvm seems that after quite a few minutes, ntp did its job
<alex88>
*ntpd
fleg has quit [Read error: Connection reset by peer]
fleg has joined #yocto
wwilly has joined #yocto
fleg has quit [Read error: Connection reset by peer]
ahs3_ has quit [Quit: Ex-Chat]
fleg has joined #yocto
fleg has quit [Read error: Connection reset by peer]
fleg has joined #yocto
fleg has quit [Read error: Connection reset by peer]
fleg has joined #yocto
fleg has quit [Read error: Connection reset by peer]
<moto-timo>
JPEW: whatever issue was previously causing QEMU to be off-canvas went away, I was able to do a bunch of screen captures finally
<moto-timo>
JPEW: the QEMU window resizes during launch to a larger screen which it did not do previously (so the bottom part of the screen used to be off-canvas)
fleg has joined #yocto
florian__ has quit [Ping timeout: 264 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
tnovotny has quit [Quit: Leaving]
Guest67 has joined #yocto
dev1990 has joined #yocto
MauroAnjo has joined #yocto
<Guest67>
What is the correct way to remove an option from the OVERRIDES variable? Say I have a machineX.conf file that, by default adds some item like this: OVERRIDES:append =":itemX". Say I then include a different a conf file using the -r switch to the bitbake command that performs a OVERRIDES:remove =":itemX". This, however, does not seem to work
<Guest67>
as itemX is still in the OVERRIDES list
manuel1985 has quit [Quit: Leaving]
<qschulz>
Guest67: IIRC, :remove applies only to space separated lists?
<qschulz>
is machineX.conf from you?
<qschulz>
if yes, you could add a variable instead, which would be XOVERRIDES = ":itemx" OVERRIDES:append = "${XOVERRIDES}" and in your machineY just set XOVERRIDES to nothing
zyga has quit [Quit: Leaving]
zpfvo has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
<Guest67>
Yes, both conf files are from us
ahs3 has joined #yocto
<rburton>
moto-timo: typically because qemu is pretending to be a tablet and the calibration broke
<moto-timo>
rburton: hence the reason we used to launch the touchscreen calibrator first…
prabhakarlad has joined #yocto
<rburton>
some BSPs pre-configure the calibration
<rburton>
and for wayland... the X tool doesn't work
<moto-timo>
thanks for saving me from wasting time on that
<rburton>
but i'd look at calibration using whatever debug tool wayland has
<moto-timo>
or gnome
<moto-timo>
Thank you
<Guest67>
Thanks qschulz, I think the XOVERRIDES method you mention will likely suffice for what I need.
fleg has quit [Read error: Connection reset by peer]
<dvorkindmitry>
do I have to always add LIC_FILE_CSUM into my reipes or LICENSE is enougth?
mvlad_ has joined #yocto
mvlad has quit [Read error: Connection reset by peer]
mvlad_ has quit [Client Quit]
Guest67 has quit [Quit: Client closed]
<qschulz>
dvorkindmitry: except if CLOSED yes
<qschulz>
dvorkindmitry: you would have seen if you had tested :)
<dvorkindmitry>
qschulz, oh, it is so annoying. thats why I've asked
<dvorkindmitry>
I mean specify license twice in every recipe: name and also refer tothe certain fil
<dvorkindmitry>
file
<rburton>
the checksum is so you get told if the license changes, and to make it easy to validate
<rburton>
ship binaries and suddenly you love that field
troth has quit [Ping timeout: 245 seconds]
<dvorkindmitry>
rburton, but I am moving to hardknott from dunfell and see that filenames are changed. why can't I use aliases then?
Guest77 has quit [Quit: Client closed]
<qschulz>
dvorkindmitry: what do you mean by "aliases"?
<dvorkindmitry>
why can't I refer to the license name, not the complete filename If my sources foes not include the license file?
chep has quit [Ping timeout: 245 seconds]
troth has joined #yocto
wwilly has quit [Quit: Leaving]
chep has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
Vonter has quit [Quit: WeeChat 3.3]
<qschulz>
dvorkindmitry: how would you be able to know if the license changes between versions if you point to the license name only without giving a file in the project?
<qschulz>
a project which does not have a license explicit somewhere is a project you shouldn't be using
<qschulz>
it might be embedded at the top of a file somewhere, that is supported by bitbake
<dvorkindmitry>
qschulz, but the license files names are changed and I'd like to refer same files without additional efforts... :(
<dvorkindmitry>
would like to be compatible with both branches - dunfell and honister
<smurray>
dvorkindmitry: the easiest way that comes to mind would be to just check in a license file in your source and point at it
<dvorkindmitry>
why can't refer with something like this LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/${LICENSE:alias};md5=xxx ?, where ${LICENSE:alias} is "mapped" to license file in ,eta/files/comon-licenses/
<smurray>
dvorkindmitry: no one else has ever asked for that?
kroon has joined #yocto
ecdhe has quit [Ping timeout: 256 seconds]
<smurray>
dvorkindmitry: you can try sending a patch to add that functionality, I suspect there will be little interest
<dvorkindmitry>
smurray, but most sources is not under my control. othervise O have to add license file as patch/additional src_uri for the recipes...
<smurray>
dvorkindmitry: make a separate branch for honister, then
<dvorkindmitry>
may I refer to SPDXLICENSEMAP[${LICENSE}] somehow in my recipe file?
<smurray>
I suspect it'd likely take some anonymous python
<dvorkindmitry>
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/${SPDXLICENSEMAP[${LICENSE}]};md5=..." it says LIC_FILES_CHKSUM points to an invalid file: /home/dv/..../common-licenses/${SPDXLICENSEMAP[Proprietary]}
<dvorkindmitry>
it is very near to what I'd like to have, but not working due to syntax (array/property expansion)
<smurray>
you'll need to use anon python since the [ ] are varflags, it's not really an array/map as you're thinking
<smurray>
dvorkindmitry: it'll take python, might be possible with the ${@blah} inline python expansion, might take an anon python snippet
troth has quit [Ping timeout: 268 seconds]
<smurray>
dvorkindmitry: as someone who works on a project that consumes a bunch of layers IMO it's better when people do different branches for different Yocto releases instead of trying to hack around things
florian__ has joined #yocto
<rburton>
dvorkindmitry: the real question is where is the license defined in the sources youve got in SRC_URI
troth has joined #yocto
rhowell has joined #yocto
<rburton>
because if the source has a one-line comment that's sufficient for LIC_FILES_CHKSUM, and if it doesn't then you have a license validation problem.
Guest25 has quit [Quit: Client closed]
* zeddii
is not grok'ing something about how to get an image feature into validitems
<rhowell>
Is there a best practice for patching a file in a recipe that is local to the .bb file? IE it's being pulled in via the "file://" fetcher? I would like to patch a file in a recipe provided by poky, but it's just a config file for the recipe, not a source file. Should I just copy the entire file over to my bbappend and modify as desired or
<rhowell>
should I create a proper patch file? I realize I can do both, but just asking if there is a "proper way" to do this?
<rhowell>
Sorry.. it's a config file for the daemon the recipe builds. Not a config for the recipe or for the make system.
florian__ has quit [Ping timeout: 260 seconds]
TikityTik has joined #yocto
<TikityTik>
is bitbake essentially yocto?
<JPEW>
moto-timo: Branch merged
<JPEW>
Feel free to open a new PR with any new changes you have. I'll look at getting the daily builds to publish persistent images
<JPEW>
Also, you mentioned slides, but I can't recall if you sent me a link or not
kiran has quit [Quit: Konversation terminated!]
kiran has joined #yocto
<khem>
marex: chromium does not guarantee backward compatibility as far as compiler used to build it is considered. So we have to use latest clang with latest chromium
<rburton>
TikityTik: bitbake is a tool that is part of "yocto"
<rburton>
rhowell: both work, depends what sort of changes you need to make. if you were changing one setting i'd patch, but if it was a large change i'd provide a replacement file
<rburton>
rhowell: another approach is to sed the file during the build :)
<rhowell>
rburton that's a good idea. I forgot about just using sed in the do_install_append(). That will be must easier for one scenario of mine
<TikityTik>
How do I successfully utilize the install command inside a bitbake recipe? i.e. somerecipe.bb
<TikityTik>
I notice sudo doesn't work and without sudo I don't see it installing.
prabhakarlad has quit [Quit: Client closed]
<rhowell>
The other change I have will have a lot of changes, so maybe I will stick my replaceing the entire file
leon-anavi has quit [Quit: Leaving]
alimon has joined #yocto
<rburton>
TikityTik: install works fine, you're "root" already, just remember that you need to do all operations under ${D}, eg install -d ${D}${bindir}
MauroAnjo has quit [Quit: Client closed]
<TikityTik>
thanks, i'll look into it then
prabhakarlad has joined #yocto
<rburton>
literally hundreds of examples in oe-core
<rburton>
$ git grep 'install -'|wc -l
<rburton>
1275
<marex>
khem: oh ... well ... so maybe we need to bump clang
<marex>
khem: btw. all I had to do is drop the busybox bbappend and patch layer.conf on the honister branch to make it build with dunfell
<marex>
khem: and I told rakuco already, that I'm totally happy to try reproducing that chromium bugreport here too
<marex>
I ran into it on mx6q
<moto-timo>
JPEW: sent link (gmail), I think you previously had access, but doesn't hurt to send again
<TikityTik>
rburton, sorry i'm not really sure how to even find these examples as I'm working with a build chain that happens to utilize yocto. afaik I don't even have bitbake as a command and instead it utilizes some binary that gets pulled via git
florian__ has joined #yocto
kiran has quit [Ping timeout: 264 seconds]
kiran has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
troth has quit [Ping timeout: 268 seconds]
<TikityTik>
i mean that it utilizes a bitbake binary that gets pulled via git
vd18 has joined #yocto
vd has quit [Ping timeout: 256 seconds]
troth has joined #yocto
MauroAnjo has joined #yocto
florian__ has quit [Ping timeout: 245 seconds]
<TikityTik>
I don't get install -d ${D}${bindir} doesn't this expand to something like /home/dev/repo/.../image/home/dev/repo/.../usr/bin?
<TikityTik>
that's what I'm seeing from an echo
florian__ has joined #yocto
troth has quit [Ping timeout: 260 seconds]
kroon has quit [Quit: Leaving]
<rhowell>
TikityTik try doing "bitbake -e somerecipe". That command will print out all the variables for that recipe. Then grep the output for the variable you are looking for. I typically save the output of the command "bitbake -e somerecipe > output". And then grep the file for the var I want like ${D}. Like this: grep "\^D=" output
<TikityTik>
Thanks
florian__ is now known as florian
ecdhe has joined #yocto
rhowell is now known as rhowell_
GNUmoon has joined #yocto
rhowell has joined #yocto
rhowell_ has quit [Quit: Client closed]
rhowell has quit [Client Quit]
rhowell has joined #yocto
jimjim has joined #yocto
nad has joined #yocto
rhowell has quit [Client Quit]
rhowell has joined #yocto
rhowell has quit [Client Quit]
troth has joined #yocto
MauroAnjo has quit [Ping timeout: 256 seconds]
nad has quit [Client Quit]
kroon has joined #yocto
jham583 has joined #yocto
jham583 has left #yocto [#yocto]
jham583 has joined #yocto
jham583 has quit [Client Quit]
jham583 has joined #yocto
jham583 has quit [Client Quit]
florian has quit [Ping timeout: 264 seconds]
jham583 has joined #yocto
jham583 has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
rhowell has joined #yocto
jimjim has quit [Quit: Client closed]
kiran has quit [Ping timeout: 245 seconds]
TikityTik has quit [Ping timeout: 264 seconds]
bps has quit [Ping timeout: 260 seconds]
florian has joined #yocto
bps has joined #yocto
bps has joined #yocto
<khem>
RP: seeing | ../git/meson.build:1:0: ERROR: Unknown linker(s): [['ar']] in compiling dtc with latest master-next
ecdhe has quit [Remote host closed the connection]