khem has quit [Quit: Connection closed for inactivity]
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
mbulut has joined #yocto
amitk_ has quit [Remote host closed the connection]
Vonter_ has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
Chaser has joined #yocto
Schlumpf has joined #yocto
Chaser has quit [Quit: Chaser]
kpo has quit [Ping timeout: 246 seconds]
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
mvlad has joined #yocto
alessioigor has joined #yocto
rob_w has joined #yocto
goliath has joined #yocto
ajfriesen84737 has joined #yocto
ajfriesen8473 has quit [Ping timeout: 244 seconds]
ajfriesen84737 is now known as ajfriesen8473
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rfuentess has joined #yocto
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
LocutusOfBorg has joined #yocto
Joel90 has joined #yocto
<Joel90>
Good day! My Yocto build only seems to build net kernel drivers. How do I figure out why it's not building the rest?
<Joel90>
My kernel .config file seems to have all the flags set
<Joel90>
to build drivers
mckoan has joined #yocto
<mckoan>
good morning
Guest98 has joined #yocto
Kubu_work has joined #yocto
Guest98 has quit [Ping timeout: 246 seconds]
olani_ has quit [Ping timeout: 245 seconds]
olani has quit [Ping timeout: 245 seconds]
olani has joined #yocto
olani_ has joined #yocto
varjag has joined #yocto
Guest98 has joined #yocto
frieder has joined #yocto
Guest68 has joined #yocto
Guest98 has quit [Ping timeout: 246 seconds]
Joel90 has quit [Quit: Client closed]
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
tnovotny has joined #yocto
<LetoThe2nd>
yo dudX
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 246 seconds]
gsalazar has joined #yocto
sudip_ is now known as sudip
tnovotny_ has joined #yocto
florian has joined #yocto
tnovotny has quit [Ping timeout: 255 seconds]
xmn has quit [Quit: ZZZzzz…]
belsirk is now known as rfuentess
Guest98 has joined #yocto
Guest68 has quit [Ping timeout: 246 seconds]
<mckoan>
hi LetoThe2nd
leon-anavi has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
Guest98 has quit [Ping timeout: 246 seconds]
florian_kc has joined #yocto
Guest98 has joined #yocto
tnovotny_ has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 245 seconds]
ptsneves has joined #yocto
zpfvo has joined #yocto
frieder has quit [Ping timeout: 246 seconds]
Guest98 has quit [Ping timeout: 246 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
rfuentess has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 258 seconds]
starblue has quit [Ping timeout: 250 seconds]
ptsneves has joined #yocto
starblue has joined #yocto
frieder has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
valdemaras has joined #yocto
dvergatal has joined #yocto
Joel94 has joined #yocto
<Joel94>
Moin! I build the Sunxi (OrangePi Zero2) image but it only loads 1 driver according to lsmod. The stock Ubuntu image loads a whole bunch. I see that drivers get built and packaged but they don't show up under lib/modules/.../kernel/ for example, and modules.devname is empty. How do I troubleshoot this?
<Joel94>
LetoThe2nd you mean this isn't done by default?!
<LetoThe2nd>
Joel94: no, why should it?
<Joel94>
LetoThe2nd This was done automatically in by RPi3 build so I assumed it would be done for Sunxi as well. Trying your suggestion now, thanks!
<LetoThe2nd>
Joel94: machines can declare it as a default, images can include it..
Guest98 has joined #yocto
<Joel94>
LetoThe2nd It didn't seem to do anything after I changed local.conf and baked core-image-minimal. Do I need to clean anything?
BrziCo has joined #yocto
<LetoThe2nd>
Joel94: you can always inspect whats going on via bitbake -e, respectively bitbake-getvar -r core-image-minimal IMAGE_INSTALL.
<LetoThe2nd>
Joel94: let me check
<BrziCo>
Hello, I'm trying to run Yocto project on imx 8QuadMax MEK board, and I followed official build instructions by NXP (https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf). I ran build for imx-image-full. Build was successful but when I boot my board i get this error
<BrziCo>
[FAILED] Failed to start Weston, a …mpositor, as a system service.
<BrziCo>
See 'systemctl status weston.service' for details.
<BrziCo>
Anyone know whats the problem?
<mckoan>
BrziCo: which MACHINE and DISTRO you specified ?
<mckoan>
BrziCo: could you give a try to bitbake imx-image-multimedia ?
<mckoan>
BrziCo: and maybe pastebin the boot log
Guest98 has quit [Ping timeout: 246 seconds]
_lore_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Guest98 has joined #yocto
_lore_ has joined #yocto
<LetoThe2nd>
Joel94: just verified with a core-image-minimal build, and the line in local.conf that it behaves as expected.
<Joel94>
LetoThe2nd Yes, indeed! No cleaning needed. You are da man!!
<LetoThe2nd>
Joel94: have fun!
Guest98 has quit [Ping timeout: 246 seconds]
landgraf1 is now known as landgraf
Guest98 has joined #yocto
<Joel94>
LetoThe2nd One more question... I get a few more drivers now (13 instead of 1 before) but no USB drivers, for example. Also, the pre-built Ubuntu image loads some 40+
<LetoThe2nd>
Joel94: then those are probable not configured in, respectively as modules in the kernel config in question.
<Joel94>
Will check, thanks!
<LetoThe2nd>
Joel94: Yocto vs. classic multipurpose distros is like: "give you the minimum to fulfill what you asked for, then please add explicitly if you need more" vs. "provide a catch-all solution for most users at the cost of additional resource usage".
<speeder>
hello! bitbake question (seemly bitbake doesn't have a channel so I am asking here): 1. is SRCREV needed? 2. what are the best practices around AUTOREV? for example can I just set all SRCREV to AUTOREV?
<KanjiMonster>
at least from my personal experience the best practice is to not use it, except temporarily (locally) while developing
<speeder>
why is that?
Guest98 has quit [Ping timeout: 246 seconds]
<KanjiMonster>
for each recipe using it, bitbake will need to ask the vcs server what is the top revision each time you run bitbake, and if any of these fails the build will fail. Even if you didn't even attempt to build that package
<KanjiMonster>
also makes scanning all recipes slower, makes it impossible to work offline, and breaks reproducability
Guest98 has joined #yocto
valdemaras has quit [Quit: valdemaras]
lexano has joined #yocto
_lore_ has joined #yocto
<ptsneves>
KanjiMonster: nice summary :)
<speeder>
yep
<speeder>
I am having this issue: whenever I update code in the main repo (the one with the actual source code, and no build-related stuff), I have to go to the meta-layer repo (the one with the .bb files) and meddle with SRCREV, there must be a better way of doing this.
<mckoan>
speeder: if you want to stay on a known release that's the right way
<mckoan>
speeder: if you want to build every time aligned to the latest commit set SRCREV to AUTOREV
<varjag>
if i have $FOO set in the shell i run bitbake from, it should be visible in do_configure() of a recipe, or?
<mcfrisk>
varjag: no. only a few variables are exposed to bitbake builds because they can and will break build reproducibility.
<varjag>
that explains it
<varjag>
am trying to forward a license key, is there a way it could be done then
dvergatal has joined #yocto
<mcfrisk>
expose something to bitbake recipe tasks via recipe data
frieder has quit [Ping timeout: 245 seconds]
<mcfrisk>
recipe should embed/include the license key in a reproducible way, in the sources or in recipe meta data (e.g. variables)
tgamblin_ is now known as tgamblin
<mcfrisk>
for example git fetch will use the build users ~/.netrc with embedded passwords, though this is very insecure and those passwords can leak easily
<varjag>
i totally don't want it to end up in a repo
<varjag>
that's why variables sounded like a better idea
<mcfrisk>
depends what you really want to protect
<mcfrisk>
pre-compiled license/application keys can be in repository
<varjag>
the recipe meta data you mentioned, are there any reserved variables for user's discretion
<KanjiMonster>
speeder: depending on how often you update the code, you could temporarily add something like 'SRCREV:pn-<yourpackage> = "${AUTOREV}"' to your local.conf while developing, and then when you are finished update the .bb to the final/stable revision
<varjag>
mcfrisk: thank you so much
<mcfrisk>
I've been bitten by that I don't recommend doing that. breaking all developer builds, making e.g. CI builds mandatory is really annoying
<mcfrisk>
separating signing step from build, before or after, is IMO better
zpfvo has joined #yocto
amitk has joined #yocto
<varjag>
it's not signing, these are activation keys for third party tool
<mcfrisk>
not everything has to run under bitbake...
<varjag>
…for a compiler that builds part of the product
<varjag>
i mean we build it currently on a separate host but it's a lot of pain
<varjag>
integrating it into the build flow is the whole point of the exercise
<mcfrisk>
hope it works for you then
Guest98 has quit [Ping timeout: 246 seconds]
<varjag>
finger's crossed
<mcfrisk>
I mean, think of builds failing when random tools run out of licenses... I had that, in CI systems, on release critical times.. a proprietary tool is frequently not that reliable, their license server flaky, builds consume too many licenses e.g. multiple parallel builds..
<KanjiMonster>
^- hey, my suggestion from a few days ago ;P
<varjag>
hmm
<mckoan>
LOL
<kanavin>
systemd vs musl is the new GNU vs pkg-config
frieder has joined #yocto
<KanjiMonster>
the musl people can also be quite stubborn sometimes. "Sorry, POSIX says this is this way, even if it is broken and everyone else defines it differently"
<kanavin>
the correct solution is to fix POSIX
<kanavin>
POSIX is basically a snapshot of common practices, not some kind of committee product
hightower3 has joined #yocto
<hightower3>
I got some embedded thing with yocto. How do I list installed packages, and what is the name of default dhcp client? (there is nothing named dh*)
mbulut has quit [Ping timeout: 250 seconds]
<kanavin>
hightower3, if you are asking about system at runtime, it may be possible there is no package database on the device, and no dhcp client installed or running.
rfuentess has quit [Quit: Leaving]
<kanavin>
hightower3, if you want to get this out of the yocto build, log.do_rootfs is the simplest way to see what was installed and why into an image
<hightower3>
no file log.do_rootfs anywhere on the system. Is it a file or?
<varjag>
where would you put a target arch binary that your -native recipe has to run with qemu
<varjag>
$datadir?
<kanavin>
hightower3, it's a file in a yocto build directory. Did you build the image yourself?
<hightower3>
no, the board came with yocto preinstalled
<kanavin>
varjag, -native recipe should never produce or consume target binaries
kpo has joined #yocto
<hightower3>
I see busybox-udhcpc installed
<hightower3>
i figured that `apt` works
<varjag>
kanavin: i have a vendor supplied arm arch compiler (not C) that i have to run as part of the build on x86
<varjag>
there is no cross compiler
<mcfrisk>
^that, -native recipes should not DEPENDS on target recipes, only the other way round. When building a target recipe, you can use -native tools to produce binaries for target (with qemu or not)
<varjag>
that all sounds nice but isn't possible
<kanavin>
varjag, you need to write a target recipe regardless
<kanavin>
pick a MACHINE, and build for that machine, the recipe doesn't have to use yocto's cross-toolchain, and can do something entirely custom
<varjag>
i'll have a target recipe for sure
<varjag>
kanavin: i have an arm binary executable from a vendor, that's it
<varjag>
i have to run it on x86
<varjag>
hence qemu
<varjag>
the executable is the compiler
<varjag>
arm elf executable producing arm binaries
<varjag>
the compiler itself should be part of the target
<varjag>
it is not distributed
<varjag>
s/shoud/should not ofc
Guest81 has joined #yocto
<varjag>
so my thinking was compiler-native fetches compiler, activates it with license key and adds a wrapper script for executing it with qemu
<varjag>
and the artifact recipe (target) uses the wrapper to build stuff
frieder has quit [Ping timeout: 250 seconds]
speeder has quit [Ping timeout: 246 seconds]
<rburton>
Sounds acceptable but I’d be screaming at your vendor for a x86 binary
<rburton>
Qemu-user has very serious limitations which might make that plan not work
hightower3 has left #yocto [Leaving]
<mcfrisk>
I would integrate a precompiled binary in bitbake build and use the toolchain elsewhere. too many things can go wrong. the toolchain could even be used inside bitbake but I would use a pre-compiled ipk/rpm/deb/tar ball for 'normal' release critical builds
<kanavin>
I'd be screaming at management for signing contracts with vendors that allow blobs
<kanavin>
source, or no deal
frieder has joined #yocto
<kanavin>
rburton, I have a perl 5.38 build running
<varjag>
rburton: they supplied us with a bunch of arm-linux libraries for qemu-user to go with this
<mckoan>
kanavin: managers understand only purchase price
rob_w has quit [Remote host closed the connection]
<kayterina>
Hello, I try to build collectd with rrdcached plugin. I add it in the .bbappend in PACKAGECONFIG="rrdtool sensors rrdcached " and I get Nothing PROVIDES 'rrdcached' but .../collectd_5.12.0.bb DEPENDS on or otherwise requires it). Close matches: rrdtool RPROVIDES rrdcached ERROR: Required build target 'collectd' has no buildable providers. Missing or unbuildable dependency chain was: ['collectd
<kayterina>
then I changed collectd recipe after suggestion by Saur, turned the PACKAGECONFIG as a runtime dependency PACKAGECONFIG[rrdcached] = "--enable-rrdcached,--disable-rrdcached,,rrdcached"
<kayterina>
bu then it fails when I install it with a packagegroup
<kayterina>
* Problem 1/1: * - package packagegroup-blah.all requires collectd, but none of the providers can be installed * - conflicting requests * - nothing provides rrdcached needed by collectd-5.12.0-r0.cortexa9hf-vfpv3
speeder_ has joined #yocto
Vonter_ has quit [Ping timeout: 246 seconds]
speeder has quit [Ping timeout: 255 seconds]
hrberg has joined #yocto
kpo has quit [Ping timeout: 246 seconds]
speeder__ has joined #yocto
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
speeder_ has quit [Ping timeout: 255 seconds]
khem has joined #yocto
Vonter has joined #yocto
speeder_ has joined #yocto
speeder__ has quit [Ping timeout: 246 seconds]
goliath has quit [Quit: SIGSEGV]
Guest81 has quit [Quit: Client closed]
<ptsneves>
kayterina: can the package be empty
<ptsneves>
kayterina: that is normally happening when the package you request to be installed is empty and does not get generated. Empty packages are only generated if ALLOW_EMPTY_<pn> = "1"
mckoan is now known as mckoan|away
frieder has quit [Remote host closed the connection]
valdemaras has joined #yocto
Joel94 has quit [Quit: Client closed]
<kayterina>
the packages are there, there is an rrdtool/1.7.2-r0/package/usr/bin/rrdcached and a ./package/usr/lib/collectd
AndreRicardo has joined #yocto
goliath has joined #yocto
Herrie has quit [Ping timeout: 255 seconds]
old_boy has joined #yocto
<old_boy>
wayland-utils-git-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://gitlab.freedesktop.org/wayland/wayland-utils.git;branch=main;protocol=https')
<old_boy>
any clue?
Herrie has joined #yocto
zpfvo has quit [Quit: Leaving.]
<kayterina>
@old_boy perhaps an error in the url? Have you checked log.do_fetch?
<old_boy>
kayterina: yes, same error in there as well.
<old_boy>
This website is down looks like from yesterday...
<khem>
old_boy: can you git clone that repo outside yocto build on same build machine ?
<old_boy>
khem: git clone git://gitlab.freedesktop.org/wayland/wayland-utils.git;branch=main;protocol=https -- is stuck
mvlad has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
silurian_invader has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
florian_kc has quit [Ping timeout: 244 seconds]
florian_kc has joined #yocto
Perflosopher0 has joined #yocto
Perflosopher has quit [Ping timeout: 246 seconds]
Perflosopher0 is now known as Perflosopher
speeder_ has joined #yocto
speeder__ has quit [Ping timeout: 255 seconds]
dgriego_ has joined #yocto
speeder_ has quit [Ping timeout: 245 seconds]
dgriego has quit [Ping timeout: 255 seconds]
dgriego_ has quit [Ping timeout: 244 seconds]
old_boy has quit [Quit: Client closed]
valdemaras has quit [Quit: valdemaras]
mbulut has joined #yocto
old_boy has joined #yocto
Ram-Z has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 246 seconds]
prabhakarlad has joined #yocto
Ram-Z has joined #yocto
goliath has quit [Quit: SIGSEGV]
Vonter has joined #yocto
DvorkinDmitry has joined #yocto
<DvorkinDmitry>
in Mickledore I am trying to add additional files into kernel module recipe with FILES:${PN} += "myfile" and it looks like myfile is not sipped into the package. Why?
GNUmoon has quit [Ping timeout: 246 seconds]
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
GNUmoon has joined #yocto
mbulut has quit [Remote host closed the connection]
mbulut has joined #yocto
dgriego has joined #yocto
prabhakarlad has quit [Quit: Client closed]
dgriego has quit [Quit: Bye]
Haxxa has quit [Ping timeout: 255 seconds]
mbulut has quit [Remote host closed the connection]