<jsandman9>
Hi good morning! Does someone know a way to skip the recipe parsing bitbake does all the time? Say I know my recipes have not changed but I'm doing some devtool development or something like that. It sometimes slows me down having to wait for the parsing all the time I run bitbake or devtool
tgamblin has joined #yocto
<mckoan>
jsandman9: you can't
<kanavin_>
jsandman9, that usually happens when there is a global change affecting all recipes, e.g. in local.conf
florian_kc has joined #yocto
<jsandman9>
Alright. Thanks for the info! I'll look for ways to keep the config stable then
<kanavin_>
jsandman9, recipe parsing is multithreaded, so the more cpu cores you have, the faster it is
Guest51 has joined #yocto
<Saur[m]>
jsandman9: If you have devtooled a recipe, then bitbake will always parse that recipe every build.
<Guest51>
morning all, ported our project to Dunfell from Rocko and to my surprise Dunfell generated a root password which Rocko did not do. I do not want a password for the resulting embedded linux, is there something I missed?
osama4 has joined #yocto
osama3 has quit [Ping timeout: 256 seconds]
<kanavin_>
RP: \0/ nice
<kroon>
jclsn[m], I think you need to dig deeper into those error messages. maybe you can get more in depth help from devicetree-discuss@lists.ozlabs.org, or some linux-nxp specific ml
gsalazar has joined #yocto
<jclsn[m]>
@kroon I wouldn't know how. Will try to ask in the devicetree mailing list
<jclsn[m]>
* kroon: I wouldn't know how. Will try to ask in the devicetree mailing list
<LetoThe2nd>
yo dudX
<kroon>
jclsn[m], i suggest you look for "hdmi_video" in other dts files that include that dtsi. then see why your dts doesn't declare it
<LetoThe2nd>
Guest51: probably you just missed or accidentially disabled the debug-tweaks IMAGE_FEATURE
<kroon>
jclsn[m], or, if you are patching away the declaration
zagor has quit [Quit: You have been kicked for being idle]
berton[m] has quit [Quit: You have been kicked for being idle]
<jclsn[m]>
<kroon> "jclsn, i suggest you look for "..." <- Problem is that I have a similar error for my other board's .dts as well. If I delete the erroneous lines, I get new errors in the .dtsi files below. Even the imx8mm.dtsi from freescale has the same errors.
<jclsn[m]>
So I am thinking that there is maybe some flag missing that supports the #include syntax
<jclsn[m]>
I just wouldn't where in the Yocto toolchain that flag is passed
<jclsn[m]>
Only thing I have done is having recently pulled upstream commits from linux-fslc
<jclsn[m]>
Otavio said he is not aware of any related changes though
<kroon>
jclsn[m], "your other board .dts" - so I assume you have a custom dts for your custom hw. then you update the fslc layer. then I'd expect you need to go through your dts to make sure it is still compatible with any updated dtsi files
<kroon>
that can be trivial or non-trivial, i wouldn't know
<jclsn[m]>
kroon: That is why I had expected as well, but then why would the imx8mm.dtsi coming from Freescale have the same syntax error?
Guest51 has quit [Ping timeout: 256 seconds]
<kroon>
you don't compile dtsi files, you compile dts files. maybe the dtsi expects some label to be set
<jclsn[m]>
Okay, I only tried deleting the faulty lines, but I guess that would have been too easy. Will dig a bit deeper now. Thanks
<kroon>
so can you build any other dts(one that is offical from the kernel tree, not modified by you) that uses the dtsi ?
Guest51 has joined #yocto
<jclsn[m]>
I would have to remove my .bbapends
<jclsn[m]>
Worth a try
<Guest51>
LetoThe2nd: from my local.conf: EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
<RP>
kanavin_: auh change applied
<kanavin_>
RP: thanks, but there's two of them, also for autobuilder-helper
<LetoThe2nd>
Guest51: that should give you a password less root login. If that doesn't apply, then bitbake -e your image and see if it actually is applied or overridden somewhere.
<RP>
kanavin_: it is there now, my tree was out of date and the push I backgrounded failed
<jclsn[m]>
kroon: Yep it builds without our .dtsi for this board at least
<kanavin_>
RP: right, let's try it then :)
<kroon>
jclsn[m], you say "our dtsi" - that sounds unusual. usually the dtsi are common for multiple hw configurations, and you only provide your own custom dts. but maybe you have your reasons
Schlumpf has joined #yocto
Thorn has quit [Ping timeout: 240 seconds]
<jclsn[m]>
kroon: I guess we have those, because we have our custom boards
<jclsn[m]>
I am pretty new to device trees, so I can't really say why
* RP
thinks we might be close to the M3 build
* RP
isn't sure what to do with the cmake cflags patches
<kroon>
jclsn[m], dts can include a dtsi, which can include another dtsi, etc. you just need to track down why/how "hdmi_video" label got removed somewhere along the line
* LetoThe2nd
inserts lame arm M3 pun
Thorn has joined #yocto
<jclsn[m]>
kroon: It should be in here, but I can't find it here or in any of the other included files
<jclsn[m]>
It definitely still used to work in 5.4
<kroon>
jclsn[m], if you have the git tree you can look for with "git log -Ghdmi_video"
<kroon>
jclsn[m], maybe it got removed along with the fslc layer update
<Guest51>
LetoThe2nd: does not seem to be inhibited by any variable that I can see
alessioigor has joined #yocto
<LetoThe2nd>
Guest51: so if you look at the final contents of IMAGE_FEATURES for your image then it is there?
<Guest51>
LetoThe2nd.: what is the best way to see the "final content" of IMAGE_FEATURE?
<LetoThe2nd>
Guest51: bitbake -e your image, and look at IMAGE_FEATURES :)
alessioigor has quit [Client Quit]
<Saur[m]>
Guest51: If you are working with Honister or master, you can also use `bitbake-getvar IMAGE_FEATURES`.
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<jclsn[m]>
kroon: Last commit regarding hdmi was in March 2021, so I guess not
<jclsn[m]>
It is more probable that I broke something
florian_kc has quit [Ping timeout: 256 seconds]
kahlenberg has joined #yocto
Thorn has quit [Ping timeout: 256 seconds]
<kahlenberg>
Hi
<kahlenberg>
How can I install newer arm-poky-gcc compiler with c++20 in yocto?
Thorn has joined #yocto
MbinIcyer[m] has joined #yocto
<LetoThe2nd>
kahlenberg: *in* Yocto? like, into the target? or use it for the build process?
prabhakarlad has joined #yocto
Guest51 has quit [Ping timeout: 256 seconds]
<kahlenberg>
I mean, I want to build a software with c++20 support with sdk.
<LetoThe2nd>
kahlenberg: on which release?
<kahlenberg>
Do I need newer arm-gcc ?
<kahlenberg>
I am using yocto 3.1.10
<LetoThe2nd>
kahlenberg: thats dunfell, so should hopefully work. does the compiler not accept -std=c++20?
lukma has quit [Ping timeout: 256 seconds]
kahlenberg has quit [Quit: Client closed]
kahlenberg has joined #yocto
<kahlenberg>
I didn't try -std=c++20, but I think when I write arm-poky-linux-gnueabi-gcc -std=c++20 not every feature of c++20 might be available. gcc version 11 supports c++-20 features.
<kahlenberg>
My arm-poky-linux-gnueabi-gcc has version 9.3.0
<kanavin_>
kahlenberg, backporting new gcc onto old yocto is very difficult, you need to update your yocto
<kahlenberg>
From which version of yocto is it available?
<kanavin_>
for example, master
Guest51 has joined #yocto
<kahlenberg>
ok, thanks
lukma has joined #yocto
<Guest51>
Saur[m]: bitbake-getvar command not found, the output of bitbake coore-image-minimal -e is confusing and I cannot say what the "final value" of IMAGE_FEATURES is
manuel1985 has joined #yocto
<qschulz>
Guest51: the line starting with IMAGE_FEATURES= is the final value
<Guest51>
qschulz: it is IMAGE_FEATURES="debug-tweaks"
gsalazar has quit [Ping timeout: 256 seconds]
Schlumpf has quit [Ping timeout: 256 seconds]
<Guest51>
qschulz: still the image is asking for a root password
<Etheryon>
anyone know how can I add boot options in yocto?
<Guest51>
qschulz: all research on the net point to that debug_tweaks line in local.conf so am at in a bit of a loss here
<Etheryon>
I'm using EXTRA_IMAGE_FEATURES ?= "debug-tweaks" in local.conf
kanavin_ has quit [Quit: Leaving]
<Etheryon>
also you can do something like 'bitbake core-image-minimal -e > env.txt' and look through that text file
<Etheryon>
you'll find something like this: IMAGE_FEATURES="splash ssh-server-openssh" with a bunch of comments preceding it in the lines above explaining how it got to that value
kanavin has joined #yocto
<abelloni>
or use bitbake-getvar
<Etheryon>
I've tried using procps but that doesn't seem to do what I need
<qschulz>
Etheryon: can you give us more info on what exactly you want to do?
<Etheryon>
at startup rfkill puts a soft block on the wifi interface, which I need to be on. I've searched around and found that people suggested adding rfkill.default_state=1 to boot options, but tbh I'm not even sure what that means
<Etheryon>
but I'm not sure how to get it into my build
<qschulz>
Etheryon: if you use U-Boot bootloader, you need to set bootargs environment variable appropriately and that should be it
kahlenberg has quit [Quit: Client closed]
gsalazar has joined #yocto
<Etheryon>
I don't think I'm using u-boot
michalkotyla has joined #yocto
gsalazar has quit [Ping timeout: 272 seconds]
<qschulz>
Etheryon: well, youll need to figure out which bootloader you're using and how they pass information to the kernel via the kernel command line
jmiehe has joined #yocto
<Etheryon>
systemd-bootx64.efi. grub-efi-bootx64.efi I'm guessing these are bootloaders?
<qschulz>
Etheryon: Pretty sure it's not, but I'm not super familiar with where UEFI stands in the boot process
<qschulz>
at least between the bootloader and the kernel for sure but I don't think that's a bootloader
starblue has quit [Ping timeout: 272 seconds]
<qschulz>
anyways, you probably have grub then?
<Etheryon>
yes
<Etheryon>
"Examples of first-stage bootloaders include BIOS, coreboot, Libreboot and Das U-Boot." so I'm guessing in my case it's BIOS
<Etheryon>
with GRUB as second stage?
starblue has joined #yocto
<Etheryon>
got any recommendation for useful resources where I can learn more about this boot process?
<Etheryon>
linux /bzImage LABEL=boot root=/dev/sda2 <- I;m guessing somewhere here? This is from grub.cfg
huseyinkozan has quit [Ping timeout: 256 seconds]
<qschulz>
sounds about right?
<qschulz>
try and see :)
<qschulz>
(and let us know:) )
<Etheryon>
so I found I have this in grub_live.cfg menuentry 'boot'{
<Etheryon>
linux /bzImage LABEL=boot root=/dev/ram0 rfkill.default_state=1
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
Schlumpf has joined #yocto
Tamis has joined #yocto
otavio has joined #yocto
<Etheryon>
ok, so I installed the image on the machine, edited /boot/grub/grub.cfg and added rfkill.default_state=1 to the boot line and that had no effect on my rfkill issue
<Etheryon>
so back to the drawing board I guess
<qschulz>
Etheryon: check that it made it to your kernel by checking the content of /proc/cmdline
<Tamis>
hello. I am build an image for powerpcspe arch. This image was compiled fine in sumo branch and now I am trying to upgrade to dunfell branch. All recipes have been compiled fine. But when the core-image is being compiled the postinst_intercept scripts are getting invoked which are calling the qemu-ppc. The qemu is failing with: qemu: uncaught
<Tamis>
target signal 4 (Illegal instruction) - core dumped
<Tamis>
Illegal instruction (core dumped)
<Tamis>
Even of the simplest command. This was not happing with the previous sumo branch. And I also found that the newer qemu version program does not have an issue in dunfell branch (I executed the command with the parameters and paths of the sumo branch and worked fine).
<Etheryon>
so I guess it's there
<Tamis>
So I suspect a problem in the glibc libraries? Does anyone have seen something like that before? And can anyone propose what I can do to debug the issue?
<RP>
michaelo: should I merge the master-next docs changes that are queued?
Wouter0100 has quit [Quit: Ping timeout (120 seconds)]
<Etheryon>
to wrap up the boot options saga I got the option set with APPEND += "rfkill.default_state=1" in image recipe
<Etheryon>
that seemed to add it to grub configuration
willo has joined #yocto
mckoan is now known as mckoan|away
Guest51 has quit [Quit: Client closed]
Thorn has quit [*.net *.split]
jmiehe has quit [*.net *.split]
osama4 has quit [*.net *.split]
dmoseley has quit [*.net *.split]
Tokamak has quit [*.net *.split]
alimon has quit [*.net *.split]
chep has quit [*.net *.split]
rsalveti has quit [*.net *.split]
LetoThe2nd has quit [*.net *.split]
paulbarker has quit [*.net *.split]
jonmason has quit [*.net *.split]
flynn378 has quit [*.net *.split]
rhadye has quit [*.net *.split]
marka has quit [*.net *.split]
rfried has quit [*.net *.split]
vquicksilver has quit [*.net *.split]
Shaun has quit [*.net *.split]
opello has quit [*.net *.split]
warthog9 has quit [*.net *.split]
alex88 has quit [*.net *.split]
Thorn has joined #yocto
dmoseley has joined #yocto
chep has joined #yocto
Tokamak has joined #yocto
alimon has joined #yocto
rsalveti has joined #yocto
marka has joined #yocto
LetoThe2nd has joined #yocto
jonmason has joined #yocto
paulbarker has joined #yocto
flynn378 has joined #yocto
jmiehe has joined #yocto
osama4 has joined #yocto
opello has joined #yocto
rfried has joined #yocto
warthog9 has joined #yocto
vquicksilver has joined #yocto
Shaun has joined #yocto
rhadye has joined #yocto
alex88 has joined #yocto
Schlumpf has quit [Quit: Client closed]
<frosteyes>
Hey folks. Trying to include clang in a SDK using meta-clang (dunfell with dunfell-clang12 of meta-clang)
<frosteyes>
I add CLANGSDK = "1" in local.conf
<frosteyes>
And don't change anything else. And I have then problem with compiler-rt
<frosteyes>
The dependency target "clang" of target "check-all" does not exist.
michalkotyla has quit [Quit: michalkotyla]
sakoman has joined #yocto
tlwoerner has quit [Ping timeout: 256 seconds]
tlwoerner has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
tlwoerner_ has joined #yocto
tlwoerner has quit [Ping timeout: 256 seconds]
kroon has quit [Quit: Leaving]
gsalazar has joined #yocto
florian_kc has joined #yocto
rob_w has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
florian_kc has quit [Ping timeout: 240 seconds]
Tamis has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
gsalazar has joined #yocto
<JaMa>
RP: I know it's not contest (and more is worse), but after seeing your e-mail about native populate_sysroot I've checked and my biggest is 92091 tmp-glibc/sstate-control/manifest-x86_64-enact-dev-native.populate_sysroot
<JaMa>
and it's nodejs and downloads half the npm registry during do_compile, so the number of files it installs is only one of its issues :/
osama4 has quit [Read error: Connection reset by peer]
<RP>
JaMa: out of interest are there any other offenders you noticed at are particularly common?
<RP>
JaMa: what triggered my interest was how horrible the docs builds sysroots are
<JaMa>
RP: top 4 recipes were all from webOS :/ top9 in http://dpaste.com/74X83UMEV show the python3 and cmake you've already tackled
<JaMa>
all 4 are using nodejs and there is nodejs-native itself as well, probably not coincidence :/
<RP>
JaMa: thanks, that does at least suggest we're right to tackle those then
<RP>
JaMa: If python/perl are bad, I thought node might be a nightmare :(
<RP>
JaMa: qt4 is better than expected tbg
<RP>
tbh
* JaMa
luckily haven't touched qt4 for last 8 years
<JaMa>
even qt5 is slowly dying out
osama4 has quit [Ping timeout: 240 seconds]
roussinm has joined #yocto
<moto-timo>
too bad meta-qt6 isn't on the layerindex... but branch naming la la la la
frieder has quit [Remote host closed the connection]
alimon has quit [Quit: Leaving.]
alimon has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
gsalazar has joined #yocto
Tamis has joined #yocto
<kanavin>
RP, halstead: AUH emails are back \0/
<kanavin>
hopefully less upgrade 'rollups' will fall to me now
<RP>
kanavin: nice. Success rate doesn't look bad either.
<RP>
kanavin: I'm thinking of being a bit more flexible on upgrades in the run up to this release FWIW
<kanavin>
RP: how come?
<RP>
kanavin: because it helps with CVEs and general release health post release and it isn't where we hit significant issues in the stabilisation window usually.
<RP>
kanavin: obviously there are some upgrades I'd say no to
<kanavin>
RP: right, I think in the latest batch there's very little that could destabilize things
<mickeypash>
Does anyone have a YT video, blog post, wiki post on best practices in 2021 for patching/update management?
<mickeypash>
At my company the approach we take is we build our images using Yocto. We host them in S3 and then we use mender to do over the air updates
<mickeypash>
But then we still need to do some post update steps to configure the device so we make API calls to our platform which more or less just pulls state from a DB
<ad__>
vd: thanks, that solved
<mickeypash>
I don't know much about this space but I've seen a very different approach taken when configuring machines in the cloud
<mickeypash>
Using things like Puppet, Ansible and Chef to managed this config