<ziga_>
@grembeter I tried this and it did not solve my problem. Problem presists.
huseyinkozan has joined #yocto
goliath has joined #yocto
ykrons has joined #yocto
smsm has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
kroon has joined #yocto
alessioigor has quit [Client Quit]
coldspark29 has quit [Ping timeout: 260 seconds]
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
frieder has quit [Client Quit]
rfuentess has joined #yocto
mckoan|away is now known as mckoan
mvlad has joined #yocto
zpfvo has joined #yocto
michalkotyla has quit [Read error: Connection reset by peer]
michalkotyla has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
NishanthMenon has quit [Ping timeout: 268 seconds]
armpit has quit [Ping timeout: 268 seconds]
armpit has joined #yocto
Emantor[m] has quit [Ping timeout: 268 seconds]
T_UNIX[m] has quit [Ping timeout: 268 seconds]
Spectrejan[m] has quit [Ping timeout: 268 seconds]
Dhruvag2000[m] has quit [Ping timeout: 268 seconds]
jsbronder has quit [Ping timeout: 268 seconds]
hmw[m] has quit [Ping timeout: 268 seconds]
zagor has quit [Ping timeout: 268 seconds]
glembo[m] has quit [Ping timeout: 268 seconds]
Starfoxxes has quit [Ping timeout: 268 seconds]
rsalveti has quit [Ping timeout: 268 seconds]
darknighte has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
NishanthMenon has joined #yocto
jsbronder has joined #yocto
darknighte has joined #yocto
rsalveti has joined #yocto
Emantor[m] has joined #yocto
Spectrejan[m] has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
lucaceresoli has joined #yocto
zpfvo has joined #yocto
glembo[m] has joined #yocto
hmw[m] has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
Dhruvag2000[m] has joined #yocto
zagor has joined #yocto
Starfoxxes has joined #yocto
T_UNIX[m] has joined #yocto
zpfvo has joined #yocto
<ziga_>
I am trying to create a "makefile" example which is in some folder which is not part of Yocto. I created a recipe and used (a) inherit externalsrc, (b) EXTERNALSRC = <path to sources> (this path has "main.c" and "makefile" inside), (c) EXTERNALSRC_BUILD = <path to build folder>, (d) SRC_URI += "file://main.c file//makefile". Then a recipe has a "do_compile(){make}" task and that is it. When I run the recipe it complains: "do_fetch: Fetcher
<ziga_>
failure: 0Unable to find file file://makefile" I tried removing SRC_URI -- in this case do_compile() runs and prints error: "make: *** No targets specified and no makefile found. Stop." How do I specify sources???
<qschulz>
ziga_: remove your custom do_compile
<qschulz>
ziga_: there's usually no need to redefine EXTERNALSRC_BUILD
<qschulz>
except if your makefile is broken, in which case you might want to make it point to the same directory as EXTERNALSRC
<ziga_>
@qschulz Hmmm. Now it compiled. How do you mean I should not redefine EXTERNALSRC_BUILD? I just defined it once.
<qschulz>
ziga_: because therer's already a default for it
<olani>
ziga_: Make will do very many things for you out of the box.
<olani>
ziga_: I'm not sure I got the tab-characters right in that gist, make sure to check.
<olani>
ziga_: If you want to use the Makefile outside OE, you'll want to add a default for bindir: bindir ?= /usr/bin
<qschulz>
olani: before adding an install target, we need it to compile something :)
<olani>
qschulz: And it should. Make has default rules for building an exe from a single c-file.
<qschulz>
olani: yet it does not, so we need to fix this first and I'm 99% sure it's an issue with the recipe. Next pain point would have been the install target like you highlighted
<qschulz>
and this sums up why somebody should try to not create new projects with makefiles in 2022 :)
<olani>
qschulz: Pshh! Make is great :)
<ziga_>
olani: I think you are wrong about the makefile. @qschulz was right. It compiled if I put same path to EXTERNALSRC_BUILD & EXTERNALSRC. But why? Can I keep these two in a separate folder?
<olani>
ziga_: Your makefile happens to work. It's still wrong. I'll explain later
<olani>
ziga_: Make uses the same build and source directory unless you tell it how to use separate.
<olani>
ziga_: So you need EXTERNALSRC and EXTERNALSRC_BUILD to point to the same dit.
<olani>
dir
<ziga_>
olani_: Ah... I thought that Yocto somehow automates this! :////
<ziga_>
olani_: One more question. How can I make sure that bitbake will run the appropriate compiler i.e. "arm-gnu-eabi", "arm-none-eabi"... once it runs that makefile?
<olani>
ziga_: do nothing :) Try the makefile I gave you.
<qschulz>
ziga_: by using $(CC) like you did and checking the ${WORKDIR}/temp/log.do_compile
<qschulz>
also, Yocto checks the arhictecture of binary files matches the expected one, so you'd have a big warning (or a failure) if the wrong toolchain/compiler is used IIRC
<olani>
ziga_: Make uses the CC variable, and has a usable default for it. bitbake will set CC as an environment variable and override the makefile default
<ziga_>
So I should just avoid defining CC = gcc at the top and use ${CC} in the line that actually compiles the program? Bitbake will then replace ${CC} automatically?
<olani>
ziga_: yes
<ziga_>
Ah okay.
<ziga_>
Thank you very much.
<qschulz>
ziga_: you can have CC ?= gcc at the top to have a sane default, but it's not necessary
<qschulz>
(it's in case your desktop distribution does not set this variable when you compile manually)
<olani>
qschulz: I'm pretty sure make has ok defaults for CC.
Thorn has quit [Ping timeout: 250 seconds]
Thorn has joined #yocto
<kanavin>
halstead, just wondering if we are any closer to restoring AUH emails to the mailing list? :)
Schlumpf has joined #yocto
<Schlumpf>
Hi, I'm trying to create a recipe for a third-party tool. The tool uses autotools for building. I created a recipe with recipetool, and changed some mistakes. But it doesn't configure: "configure: error: Couldn't find or include bfd.h" What does it mean?
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
<Schlumpf>
Schlumpf: Fixed, I have to depend on binutils
clemA has joined #yocto
dgriego has quit [Ping timeout: 240 seconds]
dgriego has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
<kanavin>
Schlumpf, it helps if we see your recipe
dgriego has quit [Ping timeout: 256 seconds]
dgriego has joined #yocto
<Wouter0100>
Howdy guys! I'm not sure were to search/ask for help, but I'm buiding a Yocto image using Poky (&KAS) and the Node-performance (and performance of another process) seems to really suffer. In the past we had a Raspbian image, which worked just fine and fast - but with our own image performance suffers a lot. I've done 2 strace's with `-c` (same RPi
<Wouter0100>
3b) on both images, and you see that it takes WAY longer to start Node: https://paste.ee/p/tzZX7 (15 seconds vs ~0.5 seconds). Some syscalls are called a lot of times as well (e.g. `mprotect`). Anyone any idea what this could be? Are we missing some DEBUG vars or so? Thanks!
smsm has quit [Ping timeout: 256 seconds]
asdf23 has joined #yocto
kroon has quit [Remote host closed the connection]
zyga-mbp has quit [Ping timeout: 256 seconds]
<asdf23>
Hello everyone,
<asdf23>
I have a weird time and date issues on the target:
<asdf23>
$ date
<asdf23>
Fri Mar 9 17:02:30 UTC 2018
<asdf23>
The time of the host is correct
<asdf23>
$ date
<asdf23>
Mo 31. Jan 13:40:16 CET 2022
<asdf23>
Can you help me?
dgriego has quit [Ping timeout: 268 seconds]
zyga-mbp has joined #yocto
dgriego has joined #yocto
dgriego has quit [Ping timeout: 268 seconds]
zyga-mbp has quit [Ping timeout: 268 seconds]
dgriego has joined #yocto
alex_b has joined #yocto
zyga-mbp has joined #yocto
<rburton>
asdf23: you're not running something like ntp to set the time correctly
<rburton>
asdf23: (march 9th 2018 is the fallback epoch in the metadata)
<rburton>
time on the host is irrelevant, the target needs to either already know the time, or it finds it out when the network comes up (with ntp or similar)
<asdf23>
rburton: Hmm, according to the output of 'systemctl status systemd-timesyncd.service -l' everything seems fine https://pastebin.com/KsZhEqPv
zyga-mbp has quit [Ping timeout: 256 seconds]
<rburton>
why is it syncing to ubuntu.com?
<asdf23>
rburton: Can I somehow set the "initial time" of the target image
<asdf23>
?
BobPungartnik has joined #yocto
<rburton>
going by the timestamp you pasted, set REPRODUCIBLE_TIMESTAMP_ROOTFS
BobPungartnik has quit [Client Quit]
<qschulz>
and no it's not fine, requests time out
<asdf23>
rburton: ntp.ubuntu.com is set in /etc/systemd/timesyncd.conf as FallbackNTP
asdf8 has joined #yocto
<rburton>
asdf23: what yocto are you using?
asdf8 has quit [Client Quit]
asdf2318 has joined #yocto
asdf23 has quit [Ping timeout: 256 seconds]
asdf2318 has quit [Client Quit]
asdf23 has joined #yocto
sakoman has joined #yocto
<kanavin>
rburton, finally stap fixes :)
florian_kc has joined #yocto
<kanavin>
hopefully for real this time?
<rburton>
hopefully!
<rburton>
it passed on the AB a few times
<rburton>
but hey, random, who knows
<asdf23>
rburton: I am using dunfell
<rburton>
neither oe-core or upstream set ubuntu as the fallback, fwiw
<rburton>
the systemd fallback is google.com
zyga-mbp has joined #yocto
xmn has quit [Quit: xmn]
zyga-mbp has quit [Ping timeout: 268 seconds]
zyga-mbp has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Tokamak has joined #yocto
zyga-mbp has quit [Ping timeout: 268 seconds]
zyga-mbp has joined #yocto
zyga-mbp has quit [Ping timeout: 256 seconds]
zyga has joined #yocto
Vonter has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
clemA has quit [Quit: Client closed]
alex_b has quit [Quit: Client closed]
zyga has quit [Ping timeout: 268 seconds]
<vd>
regardless of INITRAMFS_IMAGE_BUNDLE value, 'fitImage' doesn't include the initramfs (but fitImage-${INITRAMFS_IMAGE}-${MACHINE}-${MACHINE} does). Is that expected?
zyga-mbp has joined #yocto
<vd>
rburton: I have an RFC patch for KERNEL_DEVICETREE_BUNDLE btw, do you want me to Cc: you (since you signed-off the initial implementation)?
<rburton>
nah, i don't have enough interest/knowledge to have a proper opinion
<vd>
okay
<vd>
(my fitImage question is unrelated though)
florian_kc has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
manuel1985 has joined #yocto
codavi has joined #yocto
<kergoth>
vd: if you read kernel-fitimage.bbclass you'll see that do_assemble_fitimage_initramfs writes fitImage if INITRAMFS_IMAGE_BUNDLE is set, otherwise fitImage-${INITRAMFS_IMAGE}. doesn't sound like what you're seeing would be expected unless i'm misreading it
<kergoth>
which, admittedly, is possible
ar__ has joined #yocto
codavi has quit [Ping timeout: 256 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
zyga-mbp has quit [Ping timeout: 268 seconds]
zyga-mbp has joined #yocto
<vd>
kergoth: you were correct! Thank you. It's weird that kernel-fitimage doesn't produce a fitImage-initramfs-${MACHINE}.bin similar to zImage-initramfs-${MACHINE}.bin, and use ${INITRAMFS_IMAGE} instead.
<kergoth>
That does seem inconsistent. Perhaps open a bug to propose aligning those?
<JPEW>
Most of my ideas were related to seeing if we can trim down the things that end up in that list
<JPEW>
(too improve reuse)
zpfvo has quit [Remote host closed the connection]
Vonter has quit [Read error: Connection reset by peer]
<RP>
JPEW: I wondered about looking at the side of the manifest for the component
<RP>
size
<JPEW>
instead of the taskhash?
<RP>
JPEW: I mean only include it if the sstate contains files (or maybe certain kinds of files like headers)
Vonter has joined #yocto
<JPEW>
Ah, ya. So you don't include do_populate_sysroot tasks that don't populate anything?
<RP>
JPEW: right
<JPEW>
Are there a lot of those?
<RP>
JPEW: not sure we often do that though
GillesM has joined #yocto
asdf23 has quit [Ping timeout: 256 seconds]
olani has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
Michael90 has joined #yocto
<Michael90>
I am trying to trim my yocto image. One suggestion from the mega manual is "To eliminate all the packaging requirements for an image, be sure that "package-management" is not part of your IMAGE_FEATURES statement for the image. When you remove this feature, you are removing the package manager as well as its dependencies from the root filesystem."
<Michael90>
Can someone point me to the file I would look for this information?
<Michael90>
When I do a "grep -r package-management *" many files show and none are what I expect
<rburton>
your image recipe, or possibly local.conf, will be adding package-management to IMAGE_FEATURES
<rburton>
do 'bitbake -e [imagename]', search that for IMAGE_FEATURES=, and above you'll see where the changes occur
<Michael90>
In my local.conf there is an EXTRA_IMAGE_FEATURES += " package-management" It is using package_deb. Would there be any other place telling my build to use a package manager?
<rburton>
removing that will remove the package management tools (dpkg and apt, in your case) and the database, so a fair few MB
dmoseley has joined #yocto
olani has joined #yocto
<Michael90>
Looking at sources/poky/meta-poky/conf/distro/poky.conf I am looking at the DISTRO_FEATURES. I see it as DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}". The POKY_DEFAULT... is defined three lines above but the DISTRO_FEATURES_DEFAULT is not defined in this file. Where can I find its definition
<Michael90>
Does anyone know the approximate kernel size when building core-image-full-cmdline? I can not find documentation on relative kernel sizes
manuel1985 has quit [Quit: Leaving]
<khem>
kernel size depends on many factors, e.g. architecuture/machine kernel version, yocto version etc.
Michael90 has quit [Quit: Client closed]
Michael32 has joined #yocto
Schlumpf has quit [Quit: Konversation terminated!]
<Michael32>
If I understand correctly "core-image-full-cmdline" does not support Wi-Fi be default. In order to enable this, do I need to add the packagegroup-base-extended as an EXTRA_IMAGE_FEATURES in my local.conf?
<Michael32>
Or do I need to add MACHINE_EXTRA_RDEPENDS and MACHINE_EXTRA_RRECOMMENDS sections?
Michael32 has quit [Client Quit]
<khem>
is driver loaded ? what does ifconfig -a say
rfuentess has quit [Remote host closed the connection]
huseyinkozan has quit [Quit: Konversation terminated!]
Michael82 has joined #yocto
<Michael82>
The folder I run bitbake from is called build-fb. I am trying to use ksize.py. When I run it I get all 0's. What folder do I run this from?
ekathva has joined #yocto
mvlad has quit [Remote host closed the connection]
<Michael82>
Also how can I use Wi-Fi with the core-image-full-cmdline? I added iw and wpa-supplicant in my core-image-full-cmdline.bb
prabhakarlad has quit [Ping timeout: 256 seconds]
ekathva has quit [Remote host closed the connection]
Michael82 has quit [Quit: Client closed]
fitzsim has quit [Ping timeout: 250 seconds]
ekathva has joined #yocto
ekathva has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 260 seconds]
xmn has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
fitzsim has joined #yocto
Michael100 has joined #yocto
<Michael100>
How does one properly use ksize.py?
Michael100 has quit [Quit: Client closed]
<vmeson>
wyre: that's a link to a RPi CM with 4 GB -- I don't have one but there are comments/code in the meta-raspberrypi layer that mention it. Have you tried that?
florian_kc has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
olani has joined #yocto
florian_kc has quit [Ping timeout: 256 seconds]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
Minvera has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
florian_kc has joined #yocto
Dracos-Carazza has quit [Ping timeout: 240 seconds]
JaMa has quit [Quit: off]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]