GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
jmiehe has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
wooosaii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaii has joined #yocto
marka has joined #yocto
amitk has joined #yocto
jmiehe has quit [Quit: jmiehe]
goliath has joined #yocto
ziga_ has joined #yocto
ziga_ has quit [Read error: Connection reset by peer]
huseyinkozan has joined #yocto
djsands has quit [Quit: Client closed]
GNUmoon has quit [Ping timeout: 276 seconds]
kroon has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
jmiehe has joined #yocto
rob_w has joined #yocto
<coldspark29[m]>
Morning
<coldspark29[m]>
What is the difference between linux-imx and linux-fslc? It is not clear to me
<kroon>
coldspark29[m], check the SUMMARY/DESCRIPTION for the corresponding recipes
<coldspark29[m]>
So linux-fslc is community and linux-imx is from NXP. Does linux-fslc have graphics support?
mckoan|away is now known as mckoan
<mckoan>
good morning
<mckoan>
coldspark29[m]: linux-fslc has graphics support as well
<mckoan>
coldspark29[m]: we usually use only linux-fslc
<mckoan>
coldspark29[m]: but actually depends on your vendor BSP
<coldspark29[m]>
We have our custom board based on an imx8mm
<coldspark29[m]>
s/imx8mm/imx8/
kroon has quit [Quit: Leaving]
GNUmoon has joined #yocto
<coldspark29[m]>
On gatesgarth we based it on the official imx8mm configuration and that worked
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #yocto
leon-anavi has joined #yocto
gsalazar has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
dev1990 has joined #yocto
zpfvo has joined #yocto
Schlumpf has joined #yocto
florian has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<coldspark29[m]>
qschulz: Why does kas not automatically fetch new commits from the layers? I always have to delete the layer and run kas checkout again
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
<qschulz>
coldspark29[m]: I don't have this problem as I use commit hashes and not branch names
<coldspark29[m]>
qschulz: I thought so. It is a pity that this isn't possible
<coldspark29[m]>
Does bitbake not support Gitlab btw? I am getting a fetcher failure, which I can't seem to solve
<coldspark29[m]>
First I was changing the @ from git@gitlab to git://gitlab, but I don't know what else to change
<coldspark29[m]>
I just exchanged the Gerrit repository with the one from Gitlab. That is all
<qschulz>
coldspark29[m]: it's a slash and not a colon between the url and the repo IIRC
<qschulz>
before vti-basesystem
<coldspark29[m]>
I already tried that and in fact it isn't
<coldspark29[m]>
This is the link I get from Gitlab git@scm-ih-02.custom.de:mymachine-basesystem/meta-custom.git
<coldspark29[m]>
when I click on clone and copy paste the link
<hmw[m]>
Hi, i think i mis somthing in my distro im getting no key input in the qt application ( qt.qpa.wayland: xkbcommon not available on this build, not performing key mapping)
<qschulz>
coldspark29[m]: the URL you get from gitlab with ssh protocol is not the one you should put in SRC_URI
<qschulz>
Replace : by /
<coldspark29[m]>
I tried that and it doesn't work
<coldspark29[m]>
and bitbake should be able to use the one I get from Gitlab imo
<qschulz>
that's not exactly the code Bitbake is using but it gives you a reason for that
<qschulz>
coldspark29[m]: is your browser able to deal with that kind of URL?
<qschulz>
I don't think so, because it isn't a URL :)
<qschulz>
: usually splits domain name and port
<qschulz>
I'm not saying it cannot be done, I'm just explaining why it is currently like this (or at least the reason I see)
<coldspark29[m]>
qschulz: No, because the protocol is ssh
<coldspark29[m]>
I hear you but it still doesn't work with those fixes
<coldspark29[m]>
I tried everything. Exchanging @ for ://, : for / and removing the .git at the end
<qschulz>
coldspark29[m]: are you building with kas-container?
<coldspark29[m]>
s/for/with/, s/for/with/
<coldspark29[m]>
No Pyrex
<coldspark29[m]>
But both have the same outcome
<qschulz>
git://gitlab.com/you/yourproject.git;protocol=ssh is what's it's suypposed to be
<qschulz>
yeah but they are building in a container
frieder has joined #yocto
<qschulz>
so yourssh-agent needs to be running and passed to the container
zpfvo has quit [Ping timeout: 256 seconds]
<qschulz>
coldspark29[m]: SSH_AUTH_SOCK
<qschulz>
env variable that needs to be passed to Pyrex (see pyrex.ini I think)
<coldspark29[m]>
I already did that
<coldspark29[m]>
That was also necessary when the repo was still on Gerrit
<qschulz>
true
frieder has quit [Remote host closed the connection]
<coldspark29[m]>
Ah actually no
<coldspark29[m]>
I was just binding the .ssh directory
zpfvo has joined #yocto
<coldspark29[m]>
But well the same error occurs
<coldspark29[m]>
Just tried it
<qschulz>
otherwise, it seems you can enter the Pyrex container by running pyrex-shell and try git clone of your gitlab repo there just to make sure it isn't an issue with the keys
dlan has quit [Remote host closed the connection]
frieder has joined #yocto
<coldspark29[m]>
No issue there
kanavin has quit [Remote host closed the connection]
<qschulz>
what's your SRC_URI now?
<qschulz>
FYI, mounting .ssh in containers is not a good practice security wise
<qschulz>
hence the use of SSH_AUTH_SOCK instead
<qschulz>
which forwards the SSH agent without having the private key (and authorized_keys, known_hosts et al) in the container
kanavin has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
<coldspark29[m]>
Do you just uncomment SSH_AUTH_SOCK?
<ad__>
hi, on dunfell, i cannot see separate rootfs files before the image is created. Is ther ean option to allow this ?
<qschulz>
and envsockproxy I assume coldspark29[m]
<qschulz>
ad__: not sure to understand the question. What do you want to do exactly?
<coldspark29[m]>
Yeah, it doesn't work. Maybe something is wrong with our local Gitlab server.
<qschulz>
coldspark29[m]: which distribution are you using currently on your desktop/
<coldspark29[m]>
Ubuntu
<qschulz>
what I could suggest is to ditch pyrex for a moment and build directly from your system.
<qschulz>
by using master poky for example
<coldspark29[m]>
So use kas build?
<qschulz>
and just run bitbake -c fetch your-recipe
<qschulz>
until you get it working
<qschulz>
at least we'd know it's not something weird with bitbake+containers
<coldspark29[m]>
kas builds on the host, doesn't it?
<qschulz>
use bitbake directly, i.e. source oe-init=build-env ../build from the poky git repo
<qschulz>
the less tools in play, the better
<coldspark29[m]>
Same issue on the host
<coldspark29[m]>
It is not a Pyrex issue
<qschulz>
coldspark29[m]: wait
<qschulz>
no I don't know
<coldspark29[m]>
Yeah me neither
<coldspark29[m]>
What an awful week already :D
<qschulz>
also, not sure it's really worth putting a kernel behind ssh auth since it's all open-source but eh :)
<coldspark29[m]>
Yeah I know
<coldspark29[m]>
My colleague thinks it is easier to host the kernel ourselves and just commit our patches
<coldspark29[m]>
Plus they want to be able to build in case the network should be down
<coldspark29[m]>
Like that ever happens...
* qschulz
coughs upstream coughs the coughs patches
kroon has joined #yocto
<ad__>
qschulz: in some yocto version i can see all the target rootfs files in a specific dictory, actually in this dunfell not. Maybe it get deleted after packing ext4 image ?
<qschulz>
but yeah it's extremly common to have fork of the Linux kernel
<qschulz>
if the network being down is an issue, just host a PRE_MIRROR on your premises and you're done with this problem
<coldspark29[m]>
Which would fail in this case :P
<qschulz>
ad__: do you have INHERIT rm_work in your local.conf? otherwise, I think it might be in tmp/work/<machine>/<image-name>
<qschulz>
coldspark29[m]: what would fail?
florian_kc has joined #yocto
<coldspark29[m]>
The PREMIRROR source
<coldspark29[m]>
Being our Gitlab server
<qschulz>
ad__: yocto/build/tmp/work/puma_haikou-poky-linux/core-image-minimal/1.0-r0/rootfs is where's mine
<coldspark29[m]>
'!"§'gmrl"!)&%§=
<coldspark29[m]>
which is anger expressed in pre-emoji times
<qschulz>
coldspark29[m]: no no no, the PREMIRROR is an HTTP server serving the tarball you have in your build/downloads
<qschulz>
and it'll ask this PREMIRROR server first before going for the upstream URL
<qschulz>
if your company is going to do a lot of CI, I would highly recmomend looking into hosting your own PREMIRROR and a SSTATE_MIRROR
<coldspark29[m]>
But you can't push to repos checked out with http
<qschulz>
coldspark29[m]: yocto does not push to repo, it's read-only
<coldspark29[m]>
CI?
<qschulz>
continuous intgegration
<coldspark29[m]>
Yeah, but first things first. I can't even build this bloody honister release
<qschulz>
basically building automatically your images/distros for you (and ideally testing them right after)
<qschulz>
sure
<coldspark29[m]>
So frustrating
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
pgowda_ has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<rburton>
RP: vim and lighttpd cve fixes sent
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
florian_kc has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<RP>
rburton: awesome, thanks :)
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<rburton>
zeddii: 99% sure you broke python3-dtc
<rburton>
(100% sure0
<RP>
rburton: clearly we need better tests :/
<rburton>
the 'port to setuptools' result in do packaging happening
<rburton>
s/do/no/
<coldspark29[m]>
@qschulz It is git://git@gitlab.com/project/repo.git
<coldspark29[m]>
It worked from the host like this
<coldspark29[m]>
Now that it has fetched, it doesn't fetch again. Is there a way to force the refetch to test it for Pyrex as well?
camus has quit [Ping timeout: 250 seconds]
camus1 has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
camus1 is now known as camus
<coldspark29[m]>
I tried `clean` and `cleansstate` without success
<qschulz>
coldspark29[m]: -c fetch -f (note that any task run with -f will require a cleansstate at one point int time)
<coldspark29[m]>
and fetching only works if I bind the .ssh directory. SSH_AUTH_SOCK is not sufficient
<coldspark29[m]>
which is insecure you said
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
davidinux has joined #yocto
otavio_ has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<qschulz>
coldspark29[m]: from within containers, run `ssh-add -l`. If a pubkey is not returned, you need to fiddle with things
<coldspark29[m]>
qschulz: That is too complicated. I will just bind the .ssh container from now. We are in our own network anyway and it is readonly
<coldspark29[m]>
Pyrex really loses its charm if you have to fiddle with things inside the container.
<coldspark29[m]>
Any other idea here @JPEW?
<coldspark29[m]>
s/Any other idea here @JPEW?/Any other idea here JPEW ?/
Schlumpf has quit [Quit: Client closed]
otavio has joined #yocto
Saur has joined #yocto
<qschulz>
coldspark29[m]: mmmm, I did mount read-only ~/.ssh/known_hosts. I think otherwise it complains .ssh/known_hosts does not exist when trying to add your gitlab server to it. While when it's mounted RO, it just fails to write to it but does not fail the build. But that's very vague recollection from months ago
<qschulz>
I haven't used Pyrex for a while now
oberonc has joined #yocto
<qschulz>
also, it's very likely your host distribution is compatible with honister branch. I am on fedora35 and I don't build inside container locally
<oberonc>
Gםא איןד קררםר וגרןמע נןאנשלק:
<oberonc>
kernel-image-bzimage-5.10.63-yocto-standard-5.10.63+git0+e0147386e9_c4f9e689da-r0.intel_x86_64: sha256 check failed: 6386446dea6133df79e77296ec5862eb2173735f6f3d3287711e26c3c37ebdc9 vs cecfb00ba16f5925ec58da8cf7e2e59e668015263fc696c72c71730a9cbcaaf7
<oberonc>
Package "kernel-image-bzimage-5.10.63-yocto-standard-5.10.63+git0+e0147386e9_c4f9e689da-r0.intel_x86_64" from local repository "oe-repo" has incorrect checksum
<oberonc>
Error: Some packages from local repository have incorrect checksum
<oberonc>
-> Got this error during 'bitbake':
<oberonc>
something to do with the git repository ?
<oberonc>
how can I solve this ?
<coldspark29[m]>
qschulz: It is, but I don't like to see warnings
<qschulz>
you can mount it read-write too if you want
<coldspark29[m]>
Yeah I guess
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 240 seconds]
<zeddii>
rburton: hah. I had that same fix, but I was just switching to a new SRCREV to pick it up.
<rburton>
they need to get on and make a new release
xmn has joined #yocto
<zeddii>
maybe, the pypi stuff rob is doing is likely slowing things down.
<rburton>
zeddii: how far are you bumping the SRCREV?
<rburton>
go enough and they move setup.py to another directory and you'll have the same problem again
zpfvo has quit [Ping timeout: 256 seconds]
<zeddii>
to the tip. one from early jan, IIRC. I was adapting to it over the weekend, when I did a build on a new machine and my old dtc wasn't around to save the day.
<zeddii>
not sure what happened on my main builder, it is not taking 5 minutes to clean dtc so I can test.
<zeddii>
s/not/now
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<rburton>
clean is overrated
ar__ has joined #yocto
<rburton>
i have a mini script builddifftron, git checkout sha1 ; bitbake foo ; git checkout sha2; bitbake foo; buildhistory-diff. Useful for stuff like 'builddifftron master featurebranch image-recipe'
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<JPEW>
coldspark29[m]: SSH_AUTH_SOCK is supposed to work, iirc, but we don't it's it so it's possible it got broken. We just bind in .ssh.
<JPEW>
Holiday here, so I'm afk and can't check right now
Schlumpf has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
<RP>
who is cancelling my builds on the autobuilder? :/
zpfvo has joined #yocto
Thorn has quit [Remote host closed the connection]
sakoman has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
gsalazar_ is now known as gsalazar
gsalazar has quit [Quit: Leaving]
gsalazar has joined #yocto
<coldspark29[m]>
<JPEW> "Holiday here, so I'm afk and can..." <- Alright thank your for answering then. Enjoy your holidays!
<coldspark29[m]>
Only solution is to delete the tmp directory and start over so far
ar__ has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
jatedev has joined #yocto
<rburton>
coldspark29[m]: is the sstate on a 'normal' filesystem?
<rburton>
or are you doing something like having recipes with : in their name
<coldspark29[m]>
ext4
<rburton>
a good start would be to catch the valueerror and print out f
<rburton>
figure out what the bad input is
ilunev has joined #yocto
<coldspark29[m]>
rburton: Well, I am on honister so I was figuring this has something to do with the override syntax script I used. The one that you showed me
<coldspark29[m]>
rburton: How?
<coldspark29[m]>
-DDD ?
zpfvo has quit [Ping timeout: 240 seconds]
<coldspark29[m]>
The other weird thing is that there doesn't seem to be a pattern. You can run the command and build successfully the first time. Then when you run again, without having changed anything, this happens.
<coldspark29[m]>
So it's trying to split a filename by :
<coldspark29[m]>
Guess something went wrong porting to honister
<coldspark29[m]>
Or the sstate-cache from gatesgarth is not compatbile with the new syntax
<qschulz>
coldspark29[m]: sstate-caches from different versions aren't mixed so that shouldn't be possible
<coldspark29[m]>
Okay, so I will hold back my delete impulse
<coldspark29[m]>
But how to debug this
<coldspark29[m]>
How can I catch the value it is processing
<qschulz>
you add what rburton is suggesting in the python scripts of bitbake I assume
<rburton>
yeah, find out what it is splitting
alimon has joined #yocto
zpfvo has joined #yocto
<coldspark29[m]>
How?
<coldspark29[m]>
Ah you mean just print the value. Sure
<coldspark29[m]>
The printed value doesn't land in the shell
<coldspark29[m]>
:q
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<coldspark29[m]>
I am going to delete everything now. This is too annoying
<kanavin>
RP: I guess it was me, they were hanging for something like 16 hours or more
<kanavin>
qemuarm-ltp is particularly not doing well lately
<kanavin>
they were all almost complete, except for one hanging job
<RP>
kanavin: could you at least ask before you do that? We really need to go and debug these which is why I'd left it around
<kanavin>
I will, apologies. Typically no one pays attention to those and arm workers get blocked :-/
<RP>
kanavin: right, but someone needs to dive and and work out what the issue is :(
<kanavin>
RP: I have an update patchbomb upcoming, so if anything hangs there, I'll look at it.
<vd>
is it a bad idea to derive multiple distro configs (requiring a common one) to isolate build profiles, rather than managing and switching between multiple local.conf?
<kanavin>
this should roll up our update backlog nicely
<qschulz>
vd: local.conf should be local to the dev/build machine. Typically variables such as SSTATE_DIR or DL_DIR in there for example. Ideally, it should be left untouched from the moment you source oe-init-buildenv. Might want to add DISTRO= and MACHINE= in it but I don't put anything else than the mentioned variables in local.conf
Konsgn has joined #yocto
<rburton>
coldspark29[m]: bb.error() will write it to the console
<Konsgn>
Hi All, How would one modify u-boot so it doesn't load the am335x-pocketbeagle.dtb file? I see the findfdt script, but not where in the u-boot it is instantiate
<Konsgn>
working off of bbb-meta
<vd>
qschulz: here's my concern. I need multiple variants of my builds, developer, customer-branded, etc. The "classic" yocto way would be to set a few variables in the local.conf. But it seems messy when you need to build multiple variants like this at the same time. Having for example a foo-dev variant of the main distro seemed ideal so you could build a common image with MACHINE=bar
<vd>
DISTRO=foo-customer1.
<kergoth>
That doesn't seem unreasonable
<qschulz>
you probably would need to feedle with the default PACKAGE_ARCH value I guess
<qschulz>
fiddle?
<qschulz>
eh, english's hard
<qschulz>
and make use of DISTROOVERRIDES mechanism too probably
<vd>
Having multiple image can be an option too, but with complex images (like embedded images), it creates a lot of duplicate rather than relying on a fixed set of image names.
<qschulz>
biggest benefit of using images instead of distros is that you can build them all at the same time with only one bitbake command
rob_w has quit [Quit: Leaving]
<vd>
true
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<vd>
I guess I must try to make it work with multiple images and find a way to avoid too much duplication.
<kergoth>
qschulz, vd: multiconfig is an option with multiple distros, though depending on the exactly configurations being changed you might also need to separate TMPDIR to be per-multiconfig
<kergoth>
but that would give you the single bitbake command
zpfvo has quit [Ping timeout: 240 seconds]
<qschulz>
kergoth: isn't it technically abusing multiconfig?
<vd>
kergoth: true. I dropped the idea of multiconfig because I figured out SSTATE wasn't shared between them and multiconfig even though they are a cool feature, must be ideally used only for embedded different config into one another. Abusing them only for parallel builds doesn't seem like a good idea
zpfvo has joined #yocto
<kergoth>
I don't believe that's the case, and the purpose is to build multiple configurations at once, how that's utilized is entirely up to you, i wouldn't consider using it to build multiple configs an abuse, that's literally the name :)
<kergoth>
Also some external tooling specifically utilizes it for multiple machines and config sets, see garmin's whisk for example (https://github.com/garmin/whisk)
leonanavi has joined #yocto
<kergoth>
Now whether it meets your particular needs is of course a different question, but I don't personally think it's out of scope
<vd>
kergoth: I did believe that for a while. But what about the shared sstate? Isn't it limited with multiconfig?
zpfvo has joined #yocto
<kergoth>
I've seen shared state utilized across multiconfig boundaries, for example native recipes aren't rebuilt when switching from one multiconfig to another, even when they use different tmpdirs.
<vd>
hum ok
<vd>
kergoth: I think the "issue" here is that you may use yocto to simple build an image (or a few), or use it as a "build system framework" to set up a complex build-all-you-need system. The latter brings in the headache regarding multiple distros, tools managing local.conf fragments, many images, etc.
<vd>
Trying to keep things simple in this case is not that easy :-)
mvlad has joined #yocto
<kergoth>
I think it's just that the situation *is* complecated, so using yocto to solve it also is :) But the fact that there isn't always a single best *way* to do it adds to confusion at times. The flexibility is both an asset and a liability :)
<vd>
kergoth: exactly.
<vd>
So far I've figured out that the simpler the better, so I will try to stick with a single distro and multiple images, even though it duplicates a lot.
<qschulz>
what is duplicated?
<Saur>
Well, one image recipe can require another, so you might be able to have a base image recipe and then extend it into the actual image recipes you need.
<qschulz>
you can also have classes inherited by image recipes
<qschulz>
but as for all recipes, you cannot impact other recipes from your image recipe
<kayterina[m]>
hello. Are 10 minutes a logical time for parsing recipes in a project?
<qschulz>
kayterina[m]: it depends on the build machine and the number of recipes to parse
<kayterina[m]>
it is a big project I suppose, running in docker in wsl. ok.
<qschulz>
I've seen <insert very bad vendor> BSP layer take AGES to parse on a 32c machine
<Saur>
Parsing our 4500 recipes takes 45 seconds on my machine (8 cores with HT)
<qschulz>
yeah 10min seems a lot but depends on the machine
manuel1985 has joined #yocto
<kayterina[m]>
i7-4600U CPU, with 8gb ram given to the wsl.
<qschulz>
although, parsing should get faster overtime since it's cached
oberonc has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 256 seconds]
<rburton>
more ram would be nice, and worst case if the layer is using autorev or similar it will be doing network operations during the parse, which can really slow things down
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<vd>
kergoth: qschulz: well quick shower and kergoth is right once again, multiconfigs aren't abusing the build system. In fact tools like kas wrapping local.conf fragments in yaml are. I can keep one distro, a fixed set of default images, and a few conf/multiconfig/<customerX>.conf files appending TMPDIR/DEPLOY_DIR with "/${BB_CURRENT_MC}" and including tweaks for branding.
manuel1985 has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 240 seconds]
<qschulz>
vd: I meant using multiconfig for building effectively multiple flavors of something for the same board. In my mind, multiconfig is for systems with two or more OS running on the same target
<qschulz>
e.g. Cortex-A + Cortex-M
zpfvo has joined #yocto
<vd>
qschulz: true, but not necessarily
<vd>
I see it as a clean way to store fixed build configs, rather than documenting local.conf snippets in a README
Schlumpf has quit [Quit: Client closed]
marc1 has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
<kergoth>
I think both are viable use cases for it, but depends on your needs
zpfvo has quit [Ping timeout: 256 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
prabhakarlad has quit [Quit: Client closed]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
jatedev has quit [Quit: Client closed]
zpfvo has joined #yocto
<rburton>
hm sure i saw a function somewhere to map a path to a layer name
prabhakarlad has joined #yocto
<kergoth>
rburton: bb.utils.get_file_layer() will get the layer name for a file in a layer
<kergoth>
I used to have a class which would set LAYERDIR_name for each layer that didn't do so in their layer.conf and then used get_file_layer() to get the LAYERDIR for the current recipe. Dropped it ages ago since id idn't need it anymore
osama has joined #yocto
jatedev has joined #yocto
zpfvo has quit [Quit: Leaving.]
<rburton>
RP: what's the state of depending on py3.7 on the host? I can't remember if there is a distro still clinging to 3.6.
<rburton>
(which was EOL last month)
<RP>
rburton: I really don't remember
florian has quit [Quit: Ex-Chat]
xmn has quit [Quit: xmn]
<vd>
did something change with the wic.vdmk image type?
<rburton>
RP: me neither :(
osama has quit [Ping timeout: 256 seconds]
mckoan is now known as mckoan|away
<moto-timo>
RHEL 7.7 was still Python 3.6 at last
<moto-timo>
check
<Konsgn>
what is a series file?
<Konsgn>
Patch remove-redundant-yyloc-global.patch is already applied; check your series file..
ziga_ has joined #yocto
<ziga_>
How can I know which device tree files were used to create the final .dtb which is then included in the image?
<Konsgn>
you can have many dtb's made at once, the loaded dtb then gets selected by your u-boot settings/enviroment
<Konsgn>
first place to look would be uEnv.txt
<ziga_>
In which folder inside the build directory would I find this? U-boots?
camus has quit [Ping timeout: 256 seconds]
<alex88>
is there a way to have BUILD_ID increment on every build in os-release package? it seems the last time it changed the value is when I've I've changed the os-release.bbappend I have
camus has joined #yocto
<Konsgn>
you should be able to see dtb's in tmp/deploy/images/blah/ there you will find dtb's ... at least in my case.
<Konsgn>
they also end up packaged into the root filesystem image in the /boot/ directory... again... in my case
huseyinkozan has quit [Quit: Konversation terminated!]
<ziga_>
Thank you.
<Konsgn>
btw, the u-boot enviroment has a really comfortable fdt tool to examine the loaded device tree
<Konsgn>
fdt info/ fdt print allow you to print out entries.
<alex88>
I've tried BUILD_ID[vardepsexclude]:remove = "DATETIME" but it says ParseError
<kergoth>
if they didn't use an intermediate variable you can't use :remove, as it doesn't work on flags
<kergoth>
you'd have to use anonymous python to remove it programmatically
<kergoth>
python () { d.setVarFlag('BUILD_ID', 'vardepsexclude', ' '.join(v for v in d.getVarFlag('BUILD_ID', 'vardepsexclude').split() if v != 'DATETIME')) } or so
<alex88>
oh ok got it, I'll se if I can get it to work, trying to just assign it to "" doesn't.. it says "The metadata is not deterministic and this needs to be fixed."
<alex88>
thanks a lot for the example!
<kergoth>
It's correct, trying to let the checksums include a date/timestamp is going to end in failure, as it'll change every time the recipe is parsed, and it's parsed more than once even in a single build
<kergoth>
I'd suggest taking a step back to revisit the purpose
<alex88>
oh, ok, so it might be probably better to set the variable somewhere else
<kergoth>
removing it from vardepsexclude will also make that recipe rebuild itself every time you do a bitbake build
leonanavi has quit [Quit: Leaving]
<alex88>
that's kind of what I want, because I want the os-release file to change on every build to include the build timestamp
<alex88>
to be able to keep track of what's in each release by knowing the build it comes from
<alex88>
unless there's a more "yocto-way" of doing so
<alex88>
there's no timestamp in that, but the git commit might be enough!
florian_kc has joined #yocto
codavi has quit [Ping timeout: 240 seconds]
<rgov[m]>
I want to add a function to execute after poky/meta/classes/kernel-uboot.bbclass's uboot_prep_kimage. Would it be correct to create a .bbappend file in my layer's recipes directory and write `uboot_prep_kimage_append () { ... }` ?
<alex88>
I've just copied that bbclass and added the timestamp myself, thanks!
<alex88>
nvm, timestamp isn't updated... :/
<Konsgn>
thanks vmeson
jatedev has quit [Quit: Client closed]
jatedev has joined #yocto
otavio has quit [Remote host closed the connection]
<zeddii>
grass was sticking out before this storm!
TundraMan has quit [Remote host closed the connection]
TundraMan has joined #yocto
<vd>
qschulz: multiconfigs are very slow though :)
mvlad has quit [Remote host closed the connection]
<LetoThe2nd>
o dudX
<LetoThe2nd>
can anybody give me a short rundown of this arm edk2 thing?
GNUmoon has quit [Ping timeout: 276 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
Guest68 has joined #yocto
<Guest68>
Hello Everyone. Starting with Honister, I can't access the network from do_compile (for example, calling ping result in "ping: socket: Operation not permitted", of course, ping from the command line works correctly)
<vd>
how can I print FILESEXTRAPATHS for recipe?
<rfs613>
vd: maybe with bitbake -e recipename | grep FILESEXTRAPATHS=
<rgov[m]>
But I notice if I inspect my .config file after the fact, some of the settings didn’t make it over. Like CONFIG_ARCH_LPC32XX should definitely be set.
prabhakarlad has quit [Quit: Client closed]
<rfs613>
rgov[m]: might be due to configuration fragments being added? Maybe check KCONFIG_MODE setting.
tangofoxtrot has quit [Remote host closed the connection]
<rgov[m]>
rfs613: The docs say "An “in-tree” defconfig file can be selected via the KBUILD_DEFCONFIG variable. KCONFIG_MODE does not need to be explicitly set." I do not set it anywhere.
<LetoThe2nd>
Guest68: why would you want to do that anyways? it's called do_compile, not do_network_stuff
<rburton>
LetoThe2nd: quite a vague question. It’s UEFI firmware, for arm. Same as what runs on x86.
<Guest68>
LetoThe2nd: because the do_compile calls the dart compiler, which in turn, needs to download package from the net
tangofoxtrot has joined #yocto
<LetoThe2nd>
Guest68: well AFAIK yocto doesn't actively block network access unless you set BB_NO_NETWORK = "1" (or similar, not sure about the exact name), but random network accesses by random toolchains in random tasks are the blueprint of broken reproducibility, therefore discouraged
<LetoThe2nd>
rburton: so in th meta-arm context, its... a uefi firmware drop-in, and which is the first stage in bootloading? or not?
florian_kc has joined #yocto
goliath has quit [Quit: SIGSEGV]
prabhakarlad has joined #yocto
<rfs613>
rgov[m]: while the manual should be correct, I know that we had to set the MODE in our recipe, and it was related to getting the config to come out correctly. This was done a few years back and details are foggy.
GNUmoon has joined #yocto
florian_kc has quit [Ping timeout: 250 seconds]
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #yocto
<zeddii>
it's better to just set it. That part of the manual hasn't been clear for years now, and this is the second time in a week I've had it mentioned.
<zeddii>
once I get out from under a pile of other things, I plan to update the docs.
xperia64 has joined #yocto
<bluelightning>
anyone had an issue where bitbake sometimes waits forever after showing a parsing error instead of exiting? I'm debugging it now (on top of dunfell)
<rgov[m]>
The kernel image produced by Poky is much larger than the one I get if I just manually do a Linux build with `make intree_defconfig && make all` -- if I diff the .config files I see a couple options creeping in like CONFIG_NET_INGRESS=y. Where are these happening? Is there a diagnostic I can use to track them down?