<mcfrisk>
when some recipe fails to apply patches, build eventually fails. But when I enter devshell of the recipe, and something else goes wrong like other patches fail to apply too, then a lot more recipes start to get compiled. This is odd.
<mcfrisk>
takes to much time for bitbake exit when things fail
<mcfrisk>
now I wait for rust, cargo, clang etc native unpack tasks
michaelo has quit [Ping timeout: 252 seconds]
tperrot has quit [Ping timeout: 250 seconds]
abelloni has quit [Ping timeout: 264 seconds]
<LetoThe2nd>
yo dudX
zpfvo has quit [Ping timeout: 265 seconds]
<mcfrisk>
if this because devshell depends on all the native tools to be in sysroot? I guess so. need to find an alternative to avoid waiting for all the clang, rust, cargo things to compile before I can see if a patch can be dropped or not. the host dependencies are getting really complicated
xmn has quit [Quit: ZZZzzz…]
zpfvo has joined #yocto
leon-anavi has joined #yocto
GNUmoon has quit [Remote host closed the connection]
<wyre>
hi guys, not sure why I'm having this issue WARNING: Setscene task (/home/pokyuser/builds/joifi-engicam-mx6-dunfell/sources/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_package_setscene) failed with exit code '1' - real task will be run instead for qemuwrapper-cross_1.0.bb:do_package_setscene
pidge has quit [Ping timeout: 246 seconds]
<mcfrisk>
wyre: were there files missing or corrupt on your sstate cache? If that was the case, then falling back to real tasks is handy
<wyre>
mcfrisk, so should I remove sstate-cache folder?
<LetoThe2nd>
i have a situation where I *think* wic damages a partition. the partition content is pre-generated, and the binary blob is fine judging by fsck. then it goes into wic, using a "part --source rawcopy" line, and the partition content is defective. any ideas/pointers?
<mcfrisk>
wyre: no, don't. the warning just means that sstate cache for that task failed and real task got executed instead. the build is recovering from the failure. You could try to understand what had gone wrong. possibly an interupted build or sstate cache action, or maybe files were really damaged.
bps has quit [Ping timeout: 255 seconds]
florian has joined #yocto
vm1 has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
amitk__ has joined #yocto
amitk_ has quit [Ping timeout: 276 seconds]
prabhakarlad80 has joined #yocto
prabhakarlad has quit [Quit: Connection closed]
prabhakarlad80 has quit [Client Quit]
prabhakarlad has joined #yocto
<jbo>
Hey guys, I am trying to create a new layer with the sole goal of modifying some configuration of the 'microchip-headless-image' recipe provided by meta-atmel. From what I understand by now, all I have to do is creating a new layer (eg. via bitbake-layers create-layer) and then having a .bbappend file in there named the same as the one supplied by meta-atmel. Is that correct? From there, do I have to do anything other than adding the layer using bitbake-layers
<jbo>
add-layer ? How can I verify that my .bbappend file is actually being processed?
<vm1>
Hi. did you try bitbake-layers show-appends?
<LetoThe2nd>
jbo: bitbake -e and bitbake-layers show-appends.
<mcfrisk>
jbo: conf/bblayers.conf needs to have the new layer, then verify with "bitbake -e recipe" that your changes in bbappends are taking effect.
<jbo>
thanks, I'll give that a try
Idontknow has joined #yocto
<Idontknow>
Why should one learn yocto if there is always someone or some group that prepares all the meta- layers anyway? Please note I'm trying to get an understanding of the possible scenario's that one can find in practice (obviously there is a more advanced method of using it for a particular scenario). Because as an end-user I'll be spoiled and I need to
<Idontknow>
do some minor modifications at the end, so why should someone delve into the yocto project if everything is chewed for us? Again, I'm trying to understand it not deteriorate the amazing yocto project.
<LetoThe2nd>
Idontknow: two reasons, very practical: 1) somebody has to do the chewing, so the skill raises ones market value 2) the "minor modifications" are often not that minor, and trying to do them without at least some level of understanding leads to a lot of wasted time.
<LetoThe2nd>
Idontknow: especially the latter we see time and again. "i just want to...", but it often doesn't work like thatä.
bps has joined #yocto
bps has joined #yocto
<Idontknow>
LetoThe2nd Now I know:)
<Idontknow>
thanks
<Idontknow>
Is Rust the new savior on the block that will take over in the technology space this decade? Especially with new projects coming up.
<jbo>
some say yes, others say no.
d-s-e has joined #yocto
<Idontknow>
Because it makes it difficult to choose now which one to go for, C++ has established itself now but if I learn Rust there is currently nothing really going on...
<jbo>
I'm more than happy with modern C++. getting better on each release.
<jbo>
but this is not the channel for that.
<jbo>
these questions just spark heavily biased religious flamewars that won't provide you with a reasonable "answer" (because there probably isn't any other than "it depends")
alessioigor has quit [Quit: alessioigor]
<vm1>
go with go ;-)
<Idontknow>
jbo true
alessioigor has joined #yocto
<Idontknow>
vm1 I'd rather use assembly...
<jbo>
if that is your stake then I think rust it not for you. just use C++.
seninha has joined #yocto
<LetoThe2nd>
Idontknow: it sounds like you either are trying to get confirmation from us for some idea you have. what is your actual goal, or reason why you joined us? "should I learn yocto", "should i use rust", "should i..." - such question should not be answered based on what somebody likes best, but what actually matches your requirements. so maybe better tell us about the *actual* project and requirements.
<jbo>
+1
kanavin has joined #yocto
<Idontknow>
LetoThe2nd The actual project is to create GUI's for embedded systems. GTK uses C, Slint uses Rust (beta stage), Qt uses C++, etc. However, Google said that in its chrome project 70% are bugs due to memory stuff going on (so C++ programming) which is why I'm doubting to delve into C++ in the first place. Rust seems to solve that problem, but there
<Idontknow>
isn't much going on in terms of actual big frameworks (slint is ju
<Idontknow>
slint has just started
<LetoThe2nd>
Idontknow: that is no requirement, thats a goal.
<Idontknow>
I don't want to spend all my time learning GTK+C or Qt+C++ and then after a year something hot comes up with Rust which solves the problems that Google is facing...
<Idontknow>
LetoThe2nd Can't a goal be a requirement for an engineer?
<LetoThe2nd>
Idontknow: no.
<Idontknow>
On job advertisements they say: Requirements: .... C++, etc.
<LetoThe2nd>
Idontknow: there are projects that have goals but no requirements, but those are rare (and mostly its just engineers ignoring that they have to think about requirements)
<svuorela_>
memory stuff in c++ stuff is also happening more in old codebases from before allowing c++11, 17 and later... chrome's code base is very old. from before 2000.
<Idontknow>
LetoThe2nd hmm
<LetoThe2nd>
Idontknow: example: "has to build from source" is a possible requirement. "has be compliant to this licensing situation" is a requirement. "has to be maintained upstream for this period of time" is a requirement.
<Idontknow>
svuorela_ aaaah like that
<Idontknow>
LetoThe2nd I understand now
<Idontknow>
thanks
<LetoThe2nd>
Idontknow: so if your project is "i want to build a gui and i want to use the latest and coolest sh**tz", that is not a requirement, tbh, thats a junior/student/intern statement about a thing that will not leave their table.
<LetoThe2nd>
"has to run on this hardware" is a requirement. "has to fulfill this standard" is a requirement.
<jbo>
and on the notion of "rust seems to solve that problems" new languages arise all the time that claim to solve a problem. in practise, they rarely do - or they introduce new problems. There is no such thing as a free lunch. new hype languages come and go. some stay, but few do.
<LetoThe2nd>
"has to have this cool buzzword" is... marketing.
<Idontknow>
As a junior I want to be future-proof basically if I'm going to spend my time on it, but I'm glad I got your feedback (sorry if this wasn't the channel for it but there are some very smart people here, won't ask it in the future though)
<Idontknow>
Thanks!!!
<jbo>
when I invest time writing something I want to do it once and then re-use it for the decades to come. This is why I am still defaulting to C/C++ for most stuff. $NewHypedLanguage can disappear and definitely changes frequently enough to break working stuff.
<LetoThe2nd>
it just DEPENDS(tm)
<jbo>
also it's easy to use stuff written in C/C++ in other, higher level languages. you can use your C/C++ stuff in go, rust, javascript, python.... but it doesn't work the other way around.
<jbo>
but yes, as mentioned initially and now again by LetoThe2nd: "it depends" - as always. If you just need a one-off with no resuability requirements, do whatever. this always applies: the right tool for the job.
mihai2 has joined #yocto
<Idontknow>
jbo Good point, it was just that Google stated their problems and that they're switching to Rust (e..g. android codebase) and Rust is developed by some very good developers which made me doubt. Using C++ stuff in other languages is done by bindings which detoriate performance though
<jbo>
Idontknow, google also just brought 'carbon' to the world to solve problems. Google is not just one thing. And as a person having to work with google libraries, languages and infrastructure way too often I can tell you one thing: When google does something, it's to solve one of their problems. And the types of problems that Google has rarely to never applies to anybody else.
<LetoThe2nd>
jbo: think about this : "if you had problems the kind and scale Google has, you would not be here asking us"
<LetoThe2nd>
jbo: heh, great minds think alike it seems.
<jbo>
LetoThe2nd, indeed
<jbo>
LetoThe2nd, glad that I could illustrate that after my noob questions yesterday.
<Idontknow>
jbo LetoThe2nd You don't know how happy I am to get your feedback, thanks a lot I learnt so much! Wish you all the best!
<rburton>
urgh, i missed google announcing carbon. someone definitely is getting a bonus for each new language released.
<jbo>
Idontknow, this is personal/subjective: I spent time learning C and later C++. and I did it properly. And I do not regret it at all. Whenever other people are stuck because they can't do something because they only know $FancyLanguageA and $FancyLanguageB they are either incapable of learning the proper stuff (because they lack the deeper knowledge you get when doing C/C++) or they have to spend months learning $FancyLanguageC. Meanwhile, I can do virtually anything
<jbo>
with C/C++.
<LetoThe2nd>
jbo: i try (not always succeed, but hey!) to judge people by their behaviour, not by the level of their questions.
<jbo>
LetoThe2nd, reasonable approach +1.
<LetoThe2nd>
rburton: there has been a lot of word about them having bonuses for projects going live, and probably programming languages count as projects.
<rburton>
indeed
<jbo>
just had to increase my ubuntu VM disk because the yocto build aborted :x
Idontknow has quit [Quit: Client closed]
<rburton>
rm_work ftw, in a vm
<jbo>
I assume that would make any subsequent builds rebuilding instead of doing incremental builds?
<rburton>
it removes the build tree for each recipe when they finish. if a recipe needs a rebuild it will build from scratch anyway.
<rburton>
_if_ you're doing incremental builds on a slow recipe that you're iterating on then you can disable it for that recipe.
<jbo>
thanks for the hint
ImNotABot has joined #yocto
<barath>
what are people's thoughts on properly isolating layers per multiconfig? it seems that currently layer priorities are calculated based on which layers are enabled for the "default" mc only. so another multiconfig might enable a layer not enabled in the "default" multiconfig, and it'll work, but all the bbfiles in that layer will be priority 0 because it those priorities are calculated for the "default" multiconfig...
<jbo>
it seems like my .bbappend to modify the microchip-headless-image has succeeded. It is being listed under bitbake-layers show-appends and it is currently no longer building nodejs (which I removed in my append file)
<LetoThe2nd>
jbo: tip: usually its *MUCH* better to create a standalone image, based on core-image-minimal or core-image-base and add from there, instead of tying stuff to an existing, bloated demo image and removing stuff.
<ImNotABot>
I get: ERROR: Task (/home/dell/poky/meta/recipes-connectivity/bluez5/bluez5_5.66.bb:do_compile) failed with exit code '1' and I am on the master branch, I'm trying to compile for qemu (arm). Is there something with the master branch because on internet they say to change the bluez version?
<rburton>
ImNotABot: can you share the actual error?
<rburton>
ImNotABot: also best to use a release branch, not master, unless you want to work on master. mickledore is about to release so use that if you want to feel modern.
<ImNotABot>
Sstate summary: Wanted 76 Local 0 Mirrors 0 Missed 76 Current 1530 (0% match, 95% complete)
<ImNotABot>
WARNING: exit code 1 from a shell command.
<ImNotABot>
I did ctrl+c it when my internet speed dropped and then I re-run it again after re-connecting to another wifi access point
<rburton>
try bitbake bluez5 -C unpack to force it to rebuild
<jbo>
LetoThe2nd, that makes sense. I'll try to go down that road. I guess I can always have a look at the demo image to figure out which bits & pieces I might need.
<ImNotABot>
Is it generally recommended to use the latest release branch, for example mickledore? Or will the answer be: it depends:)
<rburton>
yes, unless you're developing yocto/oe then work on either the latest stable or LTS release
<rburton>
depending on your needs
<rburton>
(they have different lifetimes)
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ImNotABot>
rburton I've used "bitbake bluez5 -C unpack" and it seems to be working as it continues the build with no errors, currently at 96%
<rburton>
your rapid control-c probably left make writing broken files and make is terrible so it needed a clean
<rburton>
a single control-c will let all tasks finish cleanly and not cause problems like this
<ImNotABot>
Will force rebuilding take care of any broken files and thus the final image won't be corrupted? Single control-c seemed to be stuck so I pressed it again :(
<rburton>
it didn't finish compiling, so there are no broken files to install
<ImNotABot>
rburton Thanks it worked: NOTE: Tasks Summary: Attempted 1951 tasks of which 1912 didn't need to be rerun and all succeeded.
<ImNotABot>
Summary: There was 1 WARNING message.
<ImNotABot>
WARNING: /home/dell/poky/meta/recipes-connectivity/bluez5/bluez5_5.66.bb:do_unpack is tainted from a forced run
leo738 has joined #yocto
pidge has joined #yocto
d-s-e has quit [Ping timeout: 265 seconds]
suwako[m] has joined #yocto
vm1 has quit [Ping timeout: 245 seconds]
vm1 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
leo738 has quit [Quit: Client closed]
amitk__ has quit [Ping timeout: 265 seconds]
yssh has quit [Ping timeout: 245 seconds]
<ImNotABot>
rburton I did expect the entire build to continue after "bitbake bluez5 -C unpack" but it seems I have to re trigger the build core-image-base (which is not a problem of course). With linux whenever I install vscode and it says it is missing a package and I install that missing package, then vscode continues installing after that which is pretty
<ImNotABot>
neat.
<ImNotABot>
Are the "core-image-*" pure examples or can they be used for production ready devices (bitbake core-image-base for example)?
<rburton>
ImNotABot: bitbake bluez5 will just build bluez5, yes
<rburton>
write your own images, so you own them
<rburton>
same reason you make your own distro and not ship product using poky
xmn has joined #yocto
<ImNotABot>
poky is a example indeed. Could you please direct me to a starting point (as in the manual the main topic is centered around poky)?
<ImNotABot>
Because as it stands now, I do not understand why poky which builds a customizable bootable image should not be production ready? sorry
<ImNotABot>
even though poky is a reference/example
vm1 has quit [Quit: Client closed]
<jbo>
if I'd like to add alsa-utils to my core-minimal-image based layer, would I simply do a PACKAGES += alsa-utils or is it more invovled than that?
<jbo>
ah, seems like it's IMAGE_INSTALL += alsa-utils need to read up on the difference.
<landgraf>
jbo: IMAGE_INSTALL:append intead of += to avoid funny ordering issues
<jbo>
thank you! It appears to be building alsa-utils now :)
<jbo>
a question regarding kernel configs: I'm not yet clear whether I should use menuconfig and it then stores the .conf in the build (?) directory or whether the kernel config tweaks should also happen via my custom layer. could somebody provide a hint so I know which direction to dig?
ImNotABot has quit [Quit: Client closed]
<landgraf>
jbo: docs.yoctoproject.org has good extensive documentation on the topic
<jbo>
the instructions tell you to go to the poky dir, then running: bitbake linux-yocto -c kernel_configme -f
<jbo>
that also applies if I will subsequently run bitbake core-minimal-image right?
<jbo>
core-minimal-image*
<jbo>
running the command in the /poky dir yields: ERROR: Task do_kernel_configme does not exists for target core-image-minimal
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
<rburton>
jbo: menuconfig is specific to the kernel, not the image
<jbo>
rburton, indeed. just trying to figure out whether there is any magic happening under the hood that would be good to know about - thanks for the clarification!
amitk_ has joined #yocto
<rburton>
the magic is any recipe that inherits cml1 gets a menuconfig task
<rburton>
so thats the kernel and uboot
<jbo>
as in: the docs tell you to source oe-init-build-env first, which I do. but then that drops me into a new build dir rather than the build dir I was using for the core image before. Yocto will just pull the kernel from /build then when I later rebuild the core-image from my /build-myproject?
Xagen has quit [Ping timeout: 240 seconds]
<rburton>
jbo: . oe-init-build-env takes a build directory name, and only uses ./build/ if you don't tell it otherwise
<jbo>
ah, so the idea is indeed to use the same build dir as I was before when doing the kernel config, right?
<rburton>
yeah, separate build directories are entirely separate
<jbo>
great - thanks for the clarification.
<rburton>
if you have multiple you can configure them to share DL_DIR and SSTATE_DIR
<jbo>
I'll save that for when I know what I'm actually doing :)
<jbo>
alright, doing the bitbake linux-yocto -c kernel_configme -f in my /build-myproject build dir yields the error that 'Nothing PROVIDES 'linux-yocto'. I assume that the atmel layer I use uses their own kernel and I need to figure out which one that is / what it is named, right?
<jbo>
linux-mchp it is :)
<rburton>
virtual/kernel will work and pick the right recipe
<jbo>
alright, that would be bitbake -c menuconfig virtual/kernel and my assumption is that virtual/* allows to setup sort of "symlinks"?
<rburton>
yeah
<jbo>
thanks!
prabhakarlad has joined #yocto
rob_w has quit [Remote host closed the connection]
<jbo>
okay, this seems to work out well. removed bluetooth support, created the image, flashed, booted -> no more bluetooth :)
<rburton>
you removed bluetooth by changing DISTRO_FEATURES, right
<jbo>
nah, removed bluetooth support from the kernel config (Networking support -> Bluetooth subsystem support)
davidinux has joined #yocto
<jbo>
based on your comment/question I take it that this is not the way to go?
amitk_ has quit [Ping timeout: 248 seconds]
<rburton>
well, there's two parts. the kernel not supporting something doesn't stop bluez being in the images.
davidinux has quit [Quit: WeeChat 3.5]
d-s-e has joined #yocto
<jbo>
indeed
<jbo>
I did assume that the core-image-minimal wouldn't include something such as bluetooth functionalities/utilities.
<jbo>
but I'm still in the process of getting comfortable with the overal system & environment
kscherer has joined #yocto
<landgraf>
jbo: "Everything Is Better With Bluetooth" (c)
<jbo>
hah :p
<jbo>
just did an ifconfig eth0 down on my target device and it rebooted. fun.
sakoman has joined #yocto
Xagen has joined #yocto
Spooster has joined #yocto
Spooster has quit [Read error: Connection reset by peer]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
ajfriesen has joined #yocto
florian_kc has joined #yocto
amitk_ has joined #yocto
xmn has quit [Quit: xmn]
bps has quit [Ping timeout: 252 seconds]
pidge has quit [Ping timeout: 276 seconds]
d-s-e has quit [Quit: Konversation terminated!]
rfuentess has quit [Remote host closed the connection]
meego has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
zpfvo has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 248 seconds]
frieder has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 248 seconds]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 255 seconds]
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
jtoomey has joined #yocto
xmn has joined #yocto
<meego>
Mmh can *.inc files be required from another layer? I'm trying to extend a raspberry machine, and have created a new machine definition that contains "require conf/machine/include/raspberrypi3-64.inc" but it fails
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
alessioigor has quit [Quit: alessioigor]
florian_kc has joined #yocto
rfs613 has quit [Ping timeout: 250 seconds]
<jbo>
meego, as I understood the way to do this is by creating a new layer and then overriding the machine config in there (so you don't have to include anything)
LocutusOfBorg has quit [Quit: ZNC 1.8.2+deb3 - https://znc.in]