seninha has quit [Remote host closed the connection]
lrossett has quit [Ping timeout: 268 seconds]
amitk has joined #yocto
camus has quit [Ping timeout: 264 seconds]
alessioigor has joined #yocto
mischief has quit [Ping timeout: 248 seconds]
mischief has joined #yocto
camus has joined #yocto
camus has quit [Client Quit]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
dmoseley has quit [Ping timeout: 252 seconds]
beneth has quit [Read error: Connection reset by peer]
dmoseley has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
mischief has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
beneth has joined #yocto
mischief has joined #yocto
mischief has quit [Ping timeout: 260 seconds]
kaiwan has joined #yocto
mischief has joined #yocto
roussinm has quit [Quit: WeeChat 3.0]
mischief has quit [Ping timeout: 252 seconds]
florian has joined #yocto
rob_w has joined #yocto
vladest has joined #yocto
pgowda_ has joined #yocto
mischief has joined #yocto
mischief has quit [Ping timeout: 268 seconds]
MrFrank has quit [Remote host closed the connection]
MrFrank has joined #yocto
mischief has joined #yocto
MrFrank has quit [Remote host closed the connection]
barometz has joined #yocto
MrFrank has joined #yocto
rfuentess has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
Schlumpf has joined #yocto
dev1990 has joined #yocto
dev1990 has quit [Client Quit]
<marek>
morning
sstiller has joined #yocto
mvlad has joined #yocto
<qschulz>
o/
leon-anavi has joined #yocto
<chrysh>
rburton: Thanks, that makes a lot of sense! And when are -dbg ipks added? When you enable that in EXTRA_IMAGE_FEATURES?
inisider has joined #yocto
alessioigor has quit [Quit: alessioigor]
<inisider>
hello. could you please tell me if i can to do stuff similar to #if #else in C. I would like to do PACKAGECONFIG_remove="pam" in recipe just in case when VAR1==release. Is it possible?
MrFrank has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Bardon has quit [Ping timeout: 252 seconds]
Bardon has joined #yocto
MrFrank has joined #yocto
DennisE has joined #yocto
xmn has quit [Ping timeout: 265 seconds]
kalj has joined #yocto
<kanavin>
inisider, it's better to conditionally add pam where it is added in the first place
<kanavin>
the more things like this, the harder it becomes to understand how your distro is constructed, and where mysterious fails come from
<kalj>
Hey, If I add a new layer in bblayers.conf - Should bitbake pick that out without deleting some directories (e.g. tmp) ?
<kalj>
I.e. rebuild everything that was affected?
<mckoan>
kalj: depends(TM)
<LetoThe2nd>
mckoan: sometimes it rdepends(TM)
<kalj>
:)
<mckoan>
kalj: if in the new layer you have anything impacting the underlying latyers
<mckoan>
LetoThe2nd: LOL
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<kalj>
If the new layer includes something in my MACHINE_EXTRA_RRECOMMENDS which wasn't previously available
<LetoThe2nd>
kalj: lets put it like that. a properly constructed and well-behaving layer (e.g., yocto project compatible) must not have any effect by just being added. as such, it should be properly picked up once you start enabling things in the layer.
<LetoThe2nd>
kalj: MACHINE_EXTRA_RRECOMMENDS should be strongly tied to a specific MACHINE, and therefor unproblematic, AFAICS
<kalj>
Okay, I am making some experiments now.
<kalj>
Second question, if I change by local.conf, by adding a DISTRO_FEATURES:append entry, should bitbake rebuild everything affected too?
<inisider>
kanavin: thanks. the issue is actually that weston is built with PAM by default but in my distro was decided to disable login so pam isn't available any more so that's why the dicsion of removing 'pam' from PACKAGECONFIG of weston was made.
<inisider>
qschulz: thanks
<kanavin>
inisider, then it's better to reset PACKAGECONFIG completely, not use _remove
<LetoThe2nd>
kalj: it should unless somebody did something dirty somewhere.
<kalj>
LetoThe2nd: Interesting.
<LetoThe2nd>
kalj: are you seeing something unexpected?
<kalj>
Yeah, maybe :) I am trying to build a custom image based on core-image-base for raspberrypi3 using meta-raspberrypi
<kalj>
I am trying to see what enables wifi support. I think DISTRO_FEATURES:append = " wifi" and/or MACHINE_FEATURES:append = " wifi" is necessary
<qschulz>
kalj: check with bitbake-getvar -r recipe DISTRO_FEATURES to see if wifi is actually part of DISTRO_FEATURES or not
<LetoThe2nd>
kalj: nah, i don't think the wifi flag has an effect there. those DISTRO_FEATURES are sometimes rather outdated.... and what qschulz said.
<kalj>
qschulz LetoThe2nd are you saying that adding " wifi" to DISTRO_FEATURES is a no op?
<qschulz>
kalj: it does something, do a git grep in poky to see the lines of DISTRO_FEATURES with wifi in it
<LetoThe2nd>
kalj: its not a no op, but its not guaranteed to magically enable wifi. because a lot of MACHINES and recipes just don't look at it.
<qschulz>
kalj: however from a quickl look, there does not seem to be any user of wifi in MACHINE_FEATURES
lrossett has joined #yocto
<LetoThe2nd>
ah ya, its also MACHINE_FEATURES, not DISTRO_FEATURES
<qschulz>
LetoThe2nd: no, wifi is used when in DISTRO_FEATURES, but not in MACHINEFEATURES
<kalj>
How can I learn what having "wifi" in these _FEATURES affect ? I tried grepping in poky, but got a bit overwhelmed
rob_w has quit [Quit: Leaving]
<qschulz>
kalj: git grep "DISTRO_FEATURES.*wifi" does not return too much
<qschulz>
kalj: very quickly, it enables rfkill support in busybox/systemd, adds wifi support to conmnan, adds runtime dependency of wpa-supplicant to neard and add the wifi packagegroup to your image if it includes packagegroup-base already
MrFrank has quit [Remote host closed the connection]
<kalj>
Ah, yeah thanks.
MrFrank has joined #yocto
<kalj>
"packagegroup-base-wifi"
<kalj>
That makes sense
<kalj>
What does wifi in MACHINE_FEATURES do then ?
<qschulz>
kalj: nothing
<kalj>
that really doesn't show much relevant neither in poky nor in meta-raspberrypi
<qschulz>
kalj: nothing in the core, don't know about third party layers
<kalj>
Perfect, strange that it is listed here though:
<DennisE>
I cloned the repository to the sources directory and tried to add this layer via bitbake. Since LAYERSERIES_COMPAT in layer.conf was set to "warrior" this failed. I changed that variable to "kirkstone" and updated the syntax in all bb files, basically changing *_append/*_prepend to *:append/*:prepend.
<DennisE>
Now when I try to run bitbake adu-image-base I get this error:
<DennisE>
ERROR: No recipes in default available for:
<DennisE>
I searched for this error and found out that sometimes there are "dangling appends". As I found out a fix for that could be to set "BB_DANGLINGAPPENDS_WARNONLY ?= "true"" in the layer.conf.
<DennisE>
After running bitbake adu-base-image again the next error is:
<DennisE>
ERROR: adu-base-image-1.0-r0 do_rootfs: Could not invoke dnf.
<DennisE>
[...]
<DennisE>
No match for argument: adu-agent-service
<DennisE>
Error: Unable to find a match: adu-agent
<DennisE>
So I'm pretty stuck here. I think that the dangling appends are the reason for that error - the adu-agent-service isnt build so cannot be packed in the image, for me this makes sense since the root_fs is part of the OTA functionality. My approach would be to revert the "BB_DANGLINGAPPENDS_WARNONLY" change and get this layer to build properly, but
<DennisE>
I'm struggling to debug this further.
<DennisE>
As said. I'm a beginner with yocto, so it would be nice if you can give me some pointers how to figure out this problem and help me to solve that for myself. :)
<DennisE>
P.S if the proposed layer is utterly broken and there is no easy way to get this to work with the kirkstone release a hint would be great :P
amitk has joined #yocto
amitk_ has quit [Ping timeout: 265 seconds]
odra has quit [Remote host closed the connection]
odra has joined #yocto
goliath has joined #yocto
<kalj>
Shouldn't you check out the corresponding "warrior" branch of poky etc rather than changing what meta-azure-device-update specifies?
<kalj>
(should probably add that I am a beginner too)
seninha has joined #yocto
<DennisE>
The custom distro is for my company which produces vending machines. There is no way to work with a deprecated release with EOL support.
jclsn has joined #yocto
jclsn has quit [Client Quit]
jclsn has joined #yocto
amitk_ has joined #yocto
<jclsn>
So another deparment of ours wants to buy an Apple M1 Ultra build server for building Yocto in Docker containers. Do you think that is a good idea? :D
<jclsn>
They haven't evaluated it yet. I am really curious to see their results. I mean if they are Apple fanboys, they have to do this I guess. But I would never...
<rburton>
jclsn: a studio would possibly be a better bet
amitk has quit [Ping timeout: 264 seconds]
<rburton>
I've done builds on a M1 MPB in a container, and it's very fast considering it's a laptop
<rburton>
you can spend the same amount of money on an amd workstation and get a lot faster builds though
<jclsn>
rburton: Yeah I would guess the same
<rburton>
compromise being full size tower vs laptop, obviously
<jclsn>
I think it is supposed to be a build server, so it can be a tower
<rburton>
https://www.lenovo.com/gb/en/thinkstation-p620 <-- i've done a core-image-sato on a 32-core p620 in 27 minutes, and that includes seven minutes of waiting for rust-native to finish
<kalj>
DennisE That makes sense, then I am out of luck.
<jclsn>
rburton: Yeah I suggested one of those about a year. My boss didn't want to spend the money. It's been a year now and our pipelines are still not running xD
<rburton>
but they want a ultra mpb?
<jclsn>
That is another department, where they are not as stingy
<rburton>
ha
amitk has joined #yocto
<rburton>
i mean, offer to trial a Studio with a M1 Ultra, i'm curious :)
<jclsn>
Yep me too. I will definitely present the results here ^^
amitk_ has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 248 seconds]
sstiller has quit [Quit: Leaving]
<rburton>
fwiw my ghetto benchmark is a a clean poky clone, kirkstone branch, bitbake core-image-sato --runall fetch; time bitbake core-image-sato
<jclsn>
ghetto benchmark? :D
<rburton>
27 minutes on the p620 (32-core, nvme storage, 32gb ram). from a empty tmp but full sstate in 48s.
<jclsn>
Does it include chromium?
amitk has joined #yocto
<rburton>
no, core-image-sato
<jclsn>
A test with chromium would be nice
<jclsn>
I would guess it to be like three ours
<rburton>
i can test if you'd like :)
<jclsn>
My boss is still clinging to it unfortunately
<jclsn>
Yeah that would be great
<rburton>
i wonder if i still have access to the machine
<rburton>
jclsn: are you happy with just how long chromium takes to build?
<jclsn>
Nope
<jclsn>
I hate it from the bottom of my heart
<rburton>
haha
<rburton>
i mean are you happy with me telling you how long just chromium takes
<jclsn>
Oh for me Chromium takes like 4 hours on my P15 Gen 1
<jclsn>
and that is only Chromium...
<jclsn>
Total build is like 6 hours
<jclsn>
Let me have a look at the Pipeline on our EPYC server
<rburton>
ok its just building clang so give me a bit
<jclsn>
288 minutes and 16 seconds
<jclsn>
So like 4 hourse and 48 minutes I guess
<jclsn>
On the biggest processor available on the market
<rburton>
are you aware you can lock sstate and stop it rebuilding
<jclsn>
Yeah we have all cache turned off atm
<jclsn>
Short on performant storage
<rburton>
you can lock specific recipes to specific sstate hashes, so things never get rebuild
<jclsn>
I used the gitlab cache for sstate and downloads before and rebuilds were down to 6 minutes or so
<rburton>
i've used it when poking at recipes low in the stack and don't want to rebuild the world, but you can use it to pin chromium and just let it rebuild every week or whatever
<jclsn>
chromium gets rebuilts when its dependencies change
<rburton>
*unless you lock the sstate* :)
<jclsn>
How to do that?
odra has quit [Remote host closed the connection]
odra has joined #yocto
<rburton>
bitbake chromium -S none, then look in locked-sigs.inc for the chromium line. put that in your local.conf and voila, chromium will never rebuild
<rburton>
oh you might need to set SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "" too
<qschulz>
kalj: if you already have built the applications (because they are needed by something else for example, e.g. a runtime dependency on wpa-supplicant), then you won't notice anything because there's nothing to build. If you have built them in the past, it can have been already in the cache and rebuilding the image just puts those packages in without needing to rebuild the m
<qschulz>
DennisE: there's no u-boot-fw-utils anymore, it's called libubootenv now
<vvn>
Hi there -- Back to package exclusion, PACKAGE_EXCLUDE += "kernel-devicetree" excludes all kernel-module-* as well. I fail to find where this implicit dependency is defined
<qschulz>
you need your layers to be in sync. If you're using an outdated layer with no newer release, you need to do some fixups or port it yourself to support newer releases
<jclsn>
I can't find a locked-sigs.inc
<qschulz>
DennisE: the layer has a dunfell branch which doesn't have this bbappend anymore, so try with that one for starters
<qschulz>
if you need some (possibly paid) advice about mender, LetoThe2nd is likely a good first point of contact on this chat
<jclsn>
So grepped it
<jclsn>
Got this chromium-ozone-wayland :101.0.4951.54-r0
<prabhakarlad>
Hi, is there a way i can install tslib package without graphics (x11)? just enabling tslib isnt installing the tools/tests in file system (when using core-image-minimal)
<jclsn>
Do I need to put all the buid septs or only configure and compile?
<rburton>
prabhakarlad: define "enable"?
<rburton>
jclsn: to be honest, do_build might be sufficient. can't remember.
<prabhakarlad>
sorry for not being clear, I meant "IMAGE_INSTALL_append = " tslib"
<rburton>
you really don't want libgles3-mesa depending on the -dev package
<rburton>
the change that was reverted was making the gles2 -dev depend on the gles3-dev
amitk has quit [Ping timeout: 260 seconds]
<jclsn>
rburton: What if chromium is updated now? Then the signatures will change and I will need to update the signatures, don't I?
<roussinm>
the main package doesn't provide anything. the gles-3 provides headers and headers are never installed into the SDK when virtual/libgles3 is present inside a DEPENDS of a recipe.
<rburton>
jclsn: one you lock the sstate hash then it will never rebuild. if you wanted a weekly build then you can remove the lock, build, and re-lock with the new hash
<jclsn>
rburton: So it will always pull the right chromium-ozone-wayland version, no matter what commit the meta-browser is on?
<rburton>
it will just grab from sstate the hash that you'd told it
<jclsn>
But what if the sstate was cleaned?
<rburton>
then you get a file not found
<rburton>
(iirc)
<jclsn>
Yeah that is unfortunate
<jclsn>
So you can't use this and build from scratch
<roussinm>
rburton: The current problem is that Qt is built with the support of opengles32 and when a developer does a targetted build through the target SDK, qt3d can't find the gl32.h header. gl2.h is present tho.
<roussinm>
I can add libgles3-mesa-dev to our meta-toolchain, but that seemed not correct.
<rburton>
jclsn: worth a test to see if my guess was right
<rburton>
jclsn: 41 minutes for chromium recipe to build
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Schlumpf has quit [Quit: Client closed]
<jclsn>
wtf
<jclsn>
I need that machine
<jclsn>
Threadripper with 64 cores?
<vvn>
rburton: looks like you have about 32 cores as well :)
<jclsn>
Yes, but why is it so slow then
<rburton>
32 core
<vvn>
~30min is about what the 5950X needs for qtwebengine for me
<jclsn>
Hmm
* roussinm
cry with 4 core
<jclsn>
Probably because that server is part of a Kubernets cluster and many other people are building on it
<rburton>
this is AMD Ryzen Threadripper PRO 5975WX 32-Cores
<jclsn>
I was asking for a dedicated Yocto machine then
<rburton>
the best practise is to work out how long you spend waiting for a build and multiply it by your hourly pay
<rburton>
if a £5K machine does builds in a quarter of the time, that can pay for itself fairly quickly
<roussinm>
rburton: do you have any idea on the issue above for the `libgles3-mesa-dev` package why it wouldn't install even if qt depends on `virtual/libgles3`
<roussinm>
install inside the target sdk.
<Schiller>
Greetings, i have a general Question to Buildbot/Autobuilder. I try to use the E-Mail-Notifier in the Python-Skript services.py from the Autobuilder. It finds the E-Mail-Server. But there it just hangs. E-Mail-Server says <Lost connection after STLS>. Maybe someone experienced a similar behavior and knows the reasoning.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<roussinm>
One thing I tried to understand is why the libgles2-mesa-dev is installed inside the sdk when someone depends on it. Apparently it's part of the complimentary packages, but if a recipe depends on virtual/libgles3 it doesn't look like the libgles3-mesa-dev is part of the complimentary packages. Maybe something to do with the fact that the libgles3-mesa package is empty?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
leon-anavi has quit [Quit: Leaving]
ptsneves has joined #yocto
sakoman has joined #yocto
ptsneves1 has joined #yocto
ptsneves has quit [Ping timeout: 265 seconds]
ptsneves1 is now known as ptsneves
kaiwan has quit [Ping timeout: 252 seconds]
Schiller has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
ptsneves has quit [Ping timeout: 268 seconds]
<rburton>
yeah, complementary -dev installation is basically "list all packages installed, add -dev to each, install those"
<roussinm>
but libgles3-mesa-dev isn't listed. Is it because libgles3-mesa is empty?
Medos has quit [Quit: Leaving]
<roussinm>
During the invocation of dnf, libgles3-mesa isn't showed either.
Minvera has joined #yocto
<rburton>
so if libgles3-mesa isn't installed then the -dev package won't be either
<roussinm>
right, but if my recipe depends on it, shouldn't be installed? Maybe it's not installed because it's empty?
<rburton>
does your recipe DEPEND on RDEPEND
<roussinm>
DEPENDS = "virtual/libgles3"
ptsneves has joined #yocto
<rburton>
if libgles3-mesa is empty then you won't be automatically rdepending on it
<roussinm>
ok does setting ALLOW_EMPTY to 1 would help here?
<roussinm>
for that package.
<rburton>
you still won't be rdepending on it
<rburton>
presumably you rdepend at some point on some GL libraries
<roussinm>
Currently the only recipe that I installed inside the sdk, for testing purpose, is the kmscube.
<vvn>
if you were using a generic sound capable board, but for a product not intended to use sound, would you remove 'sound' from MACHINE_FEATURES in your product's machine definition, or would you remove the resulting packages by other means? (because let's say you assume that one could plug a USB sound device for some reason and you expect this to work)
<roussinm>
which as a DEPENDS = "virtual/libgles3", but no RDEPENDS.
<roussinm>
s/as/has/
<roussinm>
ok so `RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"` you are saying that when I depends on libgles3 that rdepends installs the libgles2, ok yes that makes sense.
<vvn>
s/sound/alsa/
<roussinm>
but how someone would get the libgles3-mesa-dev without directly specifying it inside a RDEPENDS from a packagegroup-sdk-target.
<rburton>
typically, there's just a single -dev package which makes things easier
<rburton>
mesa has lots for some reason
<rburton>
you could make gles2-dev depend on gles3-dev, on the grounds that the library is the same and its just headers
<roussinm>
when I build mesa, the packages-split directory is mostly empty which is weird.
ptsneves has quit [Remote host closed the connection]
ptsneves has joined #yocto
<roussinm>
the libgles{2-3}-mesa-dev are empty for some reason.
<roussinm>
depend or rdepends?
<rburton>
they're not empty
<rburton>
if they're empty, what value can they bring?
<roussinm>
the packages themselves are not empty but they are empty in the directory structure, I do not understand how the recipe work honestly its so different
<roussinm>
Is that from the packages-split directory?
<rburton>
no, because that could be empty if a build was from sstate
<rburton>
its from oe-pkgdata-util
<roussinm>
ok yes, I get the same thing.
<roussinm>
Wondering that if we do install the gles3 headers, with the depends, but that the hardware doesn't support it. Is that an issue?
ptsneves has quit [Ping timeout: 265 seconds]
goliath has quit [Quit: SIGSEGV]
<vvn>
hum, answering to myself, you would remove 'alsa' from the DISTRO_FEATURES, not MACHINE_FEATURES, so that packagegroup-base-also isn't pulled in.
<vvn>
should that be an image feature instead?
<rburton>
not really
<rburton>
roussinm: just headers, doesn't matter.
<rburton>
ok anyone understand eSDKs here?
<roussinm>
rburton: would you go with RDEPENDS here or: `RRECOMMENDS:libgles2-mesa-dev += "libgles3-mesa-dev"`
<rburton>
depends, as complementary are installed with recommends disabled...
Starfoxxes has quit [Ping timeout: 265 seconds]
<roussinm>
Doesn't it looks weird like a circular dependency if `RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"` is present and `RDEPENDS:libgles2-mesa-dev += "libgles3-mesa-dev"` is present too?
ptsneves has joined #yocto
xmn has joined #yocto
<vvn>
rburton: correct, the distro really is what must be customized for a product, even though I would intuitively customize the machine configuration or the image recipe for some reason
<rburton>
roussinm: should be fine
ptsneves has quit [Read error: Connection reset by peer]