PobodysNerfect has quit [Ping timeout: 268 seconds]
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #yocto
PobodysNerfect has joined #yocto
PobodysNerfect has quit [Ping timeout: 240 seconds]
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
Guest39 has joined #yocto
<Guest39>
Hi All, I am trying to build kirkstone on a centos7 VM and hitting an issue with dbus. The error message says "ERROR: dbus: useradd command did not succeed." so I tried running bitbake dbus and it gives the same error. I tried `BBDEBUG=1 bitbake dbus` command and i dont know what I am looking at. Can some one help me ?
<mcfrisk>
Guest39: build dependencies from build host are nontrivial so please use a host distro from suported releases which yocto CI also builds on. See poky/meta-poky/conf/distro/poky.conf and SANITY_TESTED_DISTROS variable. CentOS7 isn't listed.
rob_w has joined #yocto
PobodysNerfect has joined #yocto
<mcfrisk>
Guest39: actually I'm wrong, centos-7 is there in the list. It may be that some tools required for building were not installed to your machine, please check https://docs.yoctoproject.org/singleindex.html#required-packages-for-the-build-host which doesn't currently list centos but for other distros the needed tools are listed
leon-anavi has joined #yocto
<Entei[m]>
khem: Would it be advisable to remove the riscv exclusion from llvm recipe under yocto/oe core layer?
<Entei[m]>
The layer meta-clang doesn't have any bbappends that remove that exclusion, and clang itself complains about zicsr isa extension.
PobodysNerfect has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
JaMa has quit [Ping timeout: 248 seconds]
PobodysNerfect has joined #yocto
bps has joined #yocto
bps has joined #yocto
leohoo_sdu[m] has joined #yocto
leohoo_sdu[m] has left #yocto [#yocto]
rfuentess has joined #yocto
gsalazar has joined #yocto
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
Guest39 has quit [Quit: Client closed]
bps has quit [Ping timeout: 240 seconds]
PobodysNerfect has quit [Quit: Gone to sleep. ZZZzzz…]
<rburton>
if you're doing something in production, use a LTS
<rburton>
eol.date is, ironically, out of date
<qschulz>
I think we can also mention that more funding would result in likely longer term support, so feel free to become a sponsor :)
<Guest81>
qschulz I would like to, however I'm just a worker bee (engineer) working under managers that have no clue of technology but at the same time get 3x my salary #reality xD
<Guest81>
I am aware of LTS, just wondering whether 2 years of support for a certain release is "enough" (sorry for stating this like this)
<rburton>
management won't know they should be throwing a bit of cash at yocto if nobody tells them :)
<rburton>
every little helps
<qschulz>
Guest81: LTSes are a new things for us, we started with Dunfell and you can see that thanks to funding we could extend from the initial 2 years to 4 years.
<Guest81>
rburton true, I'll see if they want to become a sponsor
<qschulz>
Guest81: remember also that the high majority of people involved in this project are not paid by the project but by companies working on the project (and I think the maintainer receives a bit of money for their effort in maintening LTSes)
<rburton>
the cash goes directly to things like paying for the LTS maintainer
<Guest81>
to be honest I expected big companies such as microsoft to fund these kind of projects as lots of devices in the world are running linux and linux is funded by microsoft...
<rburton>
lol
<qschulz>
Guest81: we all wish big companies using FOSS would sponsor them, the reality of it is that most companies do not sponsor OSS projects (or at least not in a very sustainable way)
<rburton>
we'd really appreciate more smaller companies joining at the lower levels, many do just assume that the big companies pay for it all
<qschulz>
I don't know enough about the financial situation of Yocto so won't say more, but finances is a big issue in the FOSS world
<qschulz>
(I can also say that outside of sponsoring, having more contributors is also a good thing, any way we can have help is good :) )
<qschulz>
(this includes documentation too :) )
<Guest81>
thank you all of you for your hard work, i will bring this up for sure :)
alessioigor has quit [Quit: alessioigor]
<qschulz>
i'll let rburton handle this now, he knows more than I do and you don't need two people telling you the same thing :)
alessioigor has joined #yocto
<rburton>
Guest81: if you want to speak to someone about the perks of your company joining, even at the lowest tiers, then LetoThe2nd is the man to talk to :)
<LetoThe2nd>
rburton: literally as of one hour ago ;-)
<ndec>
LetoThe2nd: heh ;-)
<rburton>
ndec: do you feel that freedom? :)
<ndec>
yeah :)
<LetoThe2nd>
Guest81: indeed, as rburton put it - if you need ammunition or help in presenting YP to your company, I'm the one to talk to.
<Guest81>
LetoThe2nd thanks :) , will keep in touch (fingers crossed, it depends on the managers)
Guest81 has quit [Quit: Client closed]
patersonc[m] has quit [Remote host closed the connection]
florian_kc has joined #yocto
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
<mischief>
is there a list of sponsors? my company might already
<tomzy_0[m]>
LetoThe2nd: We will definitely send one or more CFPs from our company :) Do you have maybe some roughly estimates on how this event will look like? Other part from us will be at Xen Developer & Design Summit at the same day and we wonder how to manage to be on both.. kind of :D
<LetoThe2nd>
tomzy_0[m]: i *think* that it is essentially colocated and you can move in and out as much as you want :-)
<rburton>
the kvm summit was colocated last year but it was a separate payment, not sure how its being handled this year
kpo has joined #yocto
<LetoThe2nd>
separate registration, separate fee, of course. (speakers are free at YPDD, though ;-) )
rob_w has quit [Remote host closed the connection]
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
goliath has joined #yocto
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<fabatera[m]>
Building a image with a bundled initramfs.
<fabatera[m]>
Kernel compilation happens twice: on do_compile and do_bundle_initramfs.
<fabatera[m]>
do_compile runs with -j20, while do_bundle_initramfs is not setting -j parameter, -j defaults to 1, which means serial execution (one thing at a time) and takes 40 minutes to finish
PobodysNerfect has quit [Quit: Gone to sleep. ZZZzzz…]
florian_kc has quit [Ping timeout: 240 seconds]
kpo has joined #yocto
embetrix has joined #yocto
florian has quit [Quit: Ex-Chat]
ptsneves has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
seninha has joined #yocto
Guest48 has joined #yocto
Guest65 has joined #yocto
rfs613 has quit [Ping timeout: 264 seconds]
yannd has quit [Remote host closed the connection]
<vvmeson>
jonmason: as I mentioned privately, I sent an update about an hour ago.
rfs613 has joined #yocto
PobodysNerfect has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
bps2 has joined #yocto
yannd has joined #yocto
<Guest48>
I need a little assistance. I've been working on a Yocto project for a Dell OptiPlex Micro 3000 based on the `Dunfell` branch (long story). I had a defect with the 3000 and after working with Dell they decided to send me a replacement but now the 3000 is discontinued. Instead they've sent a system that has a much newer NIC (I219-LM) which
<Guest48>
apparently isn't supported until linux kernel 5.7 (Dunfell is 5.4). This project is behind schedule as-is so I need to find the quickest remedy. I'm trying to create a recipe to install the latest e1000e drivers but I can't seem to get it to compile. It does `inherit module` (which I see sets the kernel headers path) but errors "Kernel header files
<Guest48>
not in any of the expected locations". I saw some SO questions saying to add `MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"` but that made no difference. So far we haven't been building/using the SDK at all but it looks like that's a necessity for kernel module development, is it?
bps2 has quit [Ping timeout: 265 seconds]
<khem>
Entei: Zicr and Zifencei were moved out of base spec in 2.1 but they were part of base spec in 2.0 and LLVM implements 2.0 so they should be part of clang16 without any extentions unless you explicitly demand 2.1 spec via `-misa-spec`
<khem>
its a little hostile to users to do this but anyway it was done
PobodysNerfect has quit [Quit: Gone to sleep. ZZZzzz…]
florian_kc has joined #yocto
gsalazar has quit [Ping timeout: 240 seconds]
<Guest48>
Actually... I see what it's doing. The makefile for e1000e is hardcoded to get the kernel source based on a value derived from uname -r. I can't actually tell it to use the kernel source for Yocto
<rburton>
you can potentially override it when you call make
<rburton>
or just hack it up with a patch :)
<rburton>
BUILD_KERNEL=$(shell uname -r) ?
<rburton>
just add your own BUILD_KERNEL=... to EXTRA_OEMAKE
<rburton>
khem: we'll see if it actually passes first ;)
<khem>
s/batch/badge
<khem>
I think that was a thorny one
<khem>
last time I ran that was the only one left
<rburton>
agreed. i'll run it again to check :)
<rburton>
i had this weird behaviour earlier where bitbake was building clang despite toolchain not being set, so i wonder if something regressed
<Guest48>
I can override it with a different variable "KSRC", but now it's complaining that it can't find version.h. That's also overrideable too though so I guess I need to find the equivalent files
pabigot has quit [Remote host closed the connection]
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
<khem>
rburton: the next problem is overriding llvm from oe-core
<khem>
Dependency on task clang/clang_git.bb:do_populate_sysroot:virtual:native was added with hash 7028b2d8f8f61266283da3ae4092e9fc0bffe00e9311886a9bb883d799b782d1
<khem>
Dependency on task llvm/llvm_git.bb:do_populate_sysroot:virtual:native was removed with hash 54920721975c79e1d79050c7779ca2265514cf4952df7a787c75bd8101c72890
<khem>
clang-native provides llvm-native as well
<khem>
maybe I should give that up
<khem>
and let llvm be built from oe-core alone,
<khem>
this will add yet another llvm copy to be built
<khem>
we build I think 4 to 5 copies of llvm in OE today
seninha has quit [Remote host closed the connection]
<khem>
I think there should be an exception allowed for meta-clang to override llvm from oe-core
florian_kc has quit [Ping timeout: 240 seconds]
<Guest48>
Slowly making progress... I need to overwrite where the makefile is trying to install the drivers. I want it to install them into STAGING_KERNEL_BUILDDIR, right?
Guest65 has quit [Quit: Client closed]
ecdhe_ has joined #yocto
ecdhe has quit [Ping timeout: 246 seconds]
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
<mischief>
hm. seems like i can't cache bitbake code outside of docker container so that it persists between runs
<Guest48>
are you using a mounted volume to do it?
<mischief>
host bind mount
<mischief>
or perhaps the issue is multiple instances of bitbake using the same directory
<mischief>
inode mismatch: '/home/jenkins/bitbake-cache/bb_persist_data.sqlite3-wal' ino 109056935 in db, 109056933 in request.
Tamis has joined #yocto
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
<Tamis>
Hello, I am trying to use INCOMPATIBLE_LICENSE = "GPL-3.0* LGPL-3.0* AGPL-3.0*" variable per-image recipe but it seems not to be working in kirkstone branch. When I' am putting into distro conf it restricts everything. But for some dev image recipes I want some *GPL-3* packages. How should I do it?
xmn has quit [Quit: xmn]
ecdhe_ has quit [Ping timeout: 240 seconds]
<mischief>
i'm kinda surprised that psuedo even tracks this bitbake sqlite file
ecdhe has joined #yocto
embetrix has quit [Quit: Client closed]
<LetoThe2nd>
Tamis: I'm pretty sure it works, tested it a couple of weeks back. What effect do you expect but are not seeing?
xmn has joined #yocto
<Tamis>
LetoThe2nd: I added INCOMPATIBLE_LICENSE ??= "GPL-3.0* LGPL-3.0* AGPL-3.0*" as weak variable into distro conf and in my dev image I set INCOMPATIBLE_LICENSE = "" and added to IMAGE_INSTALL eg binutils. I immediately got an erorr that binutils cannot be build because is GPLv3
Guest48 has quit [Quit: Client closed]
<LetoThe2nd>
Tamis: that is kinda expected and makes sense from the evaluation point - not from the practical one, though.
<Tamis>
LetoThe2nd: Right now I did something different to test. I used into distro.conf: INCOMPATIBLE_LICENSE:release-image = "GPL-3.0* LGPL-3.0* AGPL-3.0*"
<Tamis>
And I added again into release-image the binutils to test.
<Tamis>
Now it started to build the whole release-image again. So I expect to see what will happen at the end. Will include binuitls into the image although is restricted?
<Tamis>
LetoThe2nd: How you did the per-image INCOMPATIBLE_LICENSE since you said that you tested it some weeks ago?
<LetoThe2nd>
Tamis: the key is that per-image INCOMPATIBLE_LICENSE only falls over if you actually have something in the image that would be incompatible. as long as stuff does not end up in the image, e.g. just needed for building, no problem.
<LetoThe2nd>
Tamis: I usually add bash to IMAGE_INSTALL to make it go boom.
<Tamis>
LetoThe2nd: You use INCOMPATIBLE_LICENSE in distro/local.conf or directly into the image recipe? And do you override the parameter like INCOMPATIBLE_LICENSE:image_recipe?
<LetoThe2nd>
Tamis: directly in the image. and if the build even starts, then you did something wrong, it should fail on the dependency tree evaluation already.
xmn has quit [Read error: Connection reset by peer]
<Tamis>
LetoThe2nd: ty. I will test that also. But I think that directly into the image is not respected. Will see ...
<LetoThe2nd>
Tamis: I'm pretty sure it is, but heading off for today. Ping me Monday plz :-)
Guest48 has joined #yocto
Guest48 has quit [Client Quit]
Guest48 has joined #yocto
PobodysNerfect has joined #yocto
florian_kc has joined #yocto
<Guest48>
Is there a macro to define the full path to the linux-${IMAGE}-standard-build directory? e.g. .../linux-yocto/5.4.237+gitAUTOINC+c7e2e52889_936721bc39-r0/linux-optiplex_micro_3000-standard-build I can't find one in the documentation
<Tamis>
LetoThe2nd:Will do :). Have a nice weekend!
<mischief>
nevermind, i guess it just doesn't work even without parallel bitbake
<sudip>
Guest48: try ${B}
<mischief>
can i just make psuedo ignore PERSISTENT_DIR somehow? i don't really get the impression psuedo needs to track it
<Tamis>
mischief:Maybe add to PSEUDO_IGNORE_PATHS the PERSISTENT_DIR folder?
<rburton>
khem: make llvm a proper virtual and switch provider if toolchain=clang?
<Guest48>
sudip thanks, that helps for the recipe itself at least. I need to find another way to access it for `linux-yocto` though
<Tamis>
mischief: Maybe add to PSEUDO_IGNORE_PATHS the PERSISTENT_DIR folder?
<mischief>
where would i set that so that? right now i set PERSISTENT_DIR in auto.conf in CI
<mischief>
aha
<mischief>
PSEUDO_IGNORE_PATHS .= ",${DEPLOY_DIR},${BUILDHISTORY_DIR},${TOPDIR}/cache,${COREBASE}/scripts,${CCACHE_DIR}" is already in bitbake.conf
<mischief>
so cache dir is indeed supposed to be ignored
sgw has quit [Quit: Leaving.]
<Guest48>
What does `STAGING_KERNEL_DIR` actually equate to?