thomasd13 has quit [Remote host closed the connection]
rfuentess has joined #yocto
thomasd13 has joined #yocto
thomasd13 has quit [Remote host closed the connection]
thomasd13 has joined #yocto
<mcfrisk>
sigh, Linux Foundation sending too much spam about risc-v conference, stopped all email notifications from them. I guess I had the account because of yocto...
thomasd13 has quit [Ping timeout: 265 seconds]
thomasd13 has joined #yocto
leon-anavi has joined #yocto
jclsn has quit [Quit: WeeChat 3.7.1]
jclsn has joined #yocto
jclsn has quit [Client Quit]
jclsn has joined #yocto
<kanavin>
khem, the listed pain points are not wrong. But I'm baffled why the actual sales pitch is behind a form.
invalidopcode has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
thomasd13 has quit [Remote host closed the connection]
thomasd13 has joined #yocto
prabhakarlad has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
thomasd13 has quit [Remote host closed the connection]
thomasd13 has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
kpo_ has quit [Read error: Connection reset by peer]
<neverpanic>
"Some device manufacturers choose to deploy Yocto-based systems in the field." lol, some.
thomasd13 has quit [Ping timeout: 260 seconds]
kpo_ has joined #yocto
<kanavin>
also, the whole things begs the question, why canonical won't become a yocto vendor ;)
amelius has joined #yocto
ecdhe_ has joined #yocto
<amelius>
hey, is it possible to create symlinks from dev to sys inside do_install? so something like ln -s -r ${D}/sys/class/gpio/gpio123 ${D}/dev/mygpio
<ldericher>
what's the cleanest way of installing a package's dependencies without installing (or even building) the package itself?
<ldericher>
package -> recipe
<qschulz>
ldericher: why would you want to do that?
manuel1985 has joined #yocto
<qschulz>
(what's the usecase)
<neverpanic>
kanavin: why would they? they have their own distro and want to sell you buying your upgrades from them.
<ldericher>
qschulz, we're developing application `foo`, which depends on `bar` and maybe rdepends on `baz`. But `foo` is in a messy state at this time, so I expect most builds of `foo` itself to fail.
<neverpanic>
ldericher: probably running the do_configure task, I guess?
<neverpanic>
s/upgrades/updates/
<ernstp>
if one of my last systemd bootup services start drawing to /dev/fb0, how do I integrate that with Psplash? There seems to be a race condition in my naive setup right now...
<ldericher>
qschulz, Also, we might not want any `foo` to be deployed on our development-stage images.
<qschulz>
ldericher: I guess you could add the noexec varflag on most tasks of the foo application
amitk_ has joined #yocto
<qschulz>
ldericher: development images very likely should be using a distro anyways
<qschulz>
but at that point, you might want to create a placeholder foo recipe which is mostly empty except the dependencies
<qschulz>
maybe use a virtual/package or something
<qschulz>
but spending time on fixing the sw/recipe might make more sense that try to have a passing build with all the dependencies except the package in question
<LetoThe2nd>
neverpanic: where does that "some vendors" statement come from?
<ldericher>
qschulz, thanks for the pointers! :)
<kanavin>
neverpanic, to be compatible with the industry standard, and not have to ask prospective clients to throw away their existing yocto stacks and all investment that went into them
<kanavin>
any resonable CTO should press them on that point :)
<neverpanic>
There was an EEE thing going on? Is there a link where I can find out more about that, I honestly didn't notice.
<neverpanic>
Coming from automotive, I can see why somebody would choose to buy Ubuntu Core or the Red Hat Edge stuff over Yocto. I think there's a market, but it depends what your requirements are.
<LetoThe2nd>
kanavin: hehe, kinda feels cool to be with a small company that the big canonicals feel like required to mention and call out explicitly.
<rburton>
neverpanic: short lived meta-rpm layer which basically looked like oe-core but was actually rhel
<neverpanic>
The thing that'll kill it for the automotive market is probably pricing per unit. They really don't like that in that space.
<rburton>
neverpanic: the plan appeared to be 'convince automotive vendors to use AGL+meta-rpm, switch them to rhel when it breaks as it's a terrible hack'
<LetoThe2nd>
neverpanic: the key wisdom is: there are usecases where yocto fits, and where it does not fit. its not about bashing, its about picking the best tool for the job. see also my YPS presentation :-)
<kanavin>
neverpanic, first there are significant technical hurdles too. rhel needs to be reengineered from the ground up to not contain any gpl3 for starters
<neverpanic>
kanavin: I think the plot is to convince the automotive people that GPL-3 isn't all that bad. And if they can do that, I think that would be great.
<neverpanic>
But, I've been in that boat before, and it was a very leaky one and sinking quickly.
<rburton>
this canonical thing is literally the first time ive ever see people claim yocto is good for fast prototyping on embedded boards
<kanavin>
neverpanic, totally. That I fully support.
<kanavin>
the thing with automotive oems, the whole world is seeing their fumbles and stumbles in trying to become software companies.
<kanavin>
and actual software companies are smelling blood, big time.
<kanavin>
so they all want a piece of that massive pie.
<neverpanic>
I think we had discussions 7 or 8 years ago already that something similar to an Android unlocked bootloader could potentially solve the GPL-3 "problem"
<rburton>
very tempted to write a 'reply' to this
<rburton>
you can't say that yocto gives you complete control and is very complex, so that obviously means its ideal for quick hacks but nothing else
<neverpanic>
rburton: Go for it, I think this could be a nice "unfakeable linux" moment
<kanavin>
neverpanic, I only need to see that it's about volkswagen on the first slide, no further explanatins needed :)
florian has joined #yocto
manuel1985 has quit [Ping timeout: 256 seconds]
tomzy_0 has joined #yocto
<neverpanic>
Makes the whole industry look bad, unfortunately. I worked on OTA update for BMW, and I can tell you it's not as broken as this.
<tomzy_0>
morning
<LetoThe2nd>
neverpanic: judging from the number of people "having worked on OTA for BMW", my estimate is that about every car sold has a customized mechanism.....
* LetoThe2nd
ducks and runs
<neverpanic>
lol
<neverpanic>
Dunno, core team doing the updater was a dozen people or something? Plus equally as many doing testing, plus a bunch more in Munich writing protocol specifications and doing more testing. Maybe some testers in foreign countries.
<LetoThe2nd>
just trolling you a bit, no worries :-)
<neverpanic>
Overall probably <100 people. I guess you're just exceptionally lucky to have met many of them? :D
<LetoThe2nd>
or lets say i just meet a lot of people as part of my job, and exceptionally many involved in OTA?
<LetoThe2nd>
neverpanic: full disclosure, in case you didn't know - I'm leading developer relations for Mender :-)
<mcfrisk>
BMW OTA isn't just a single embedded product OTA, it's an "update 10's of computers, from 10's of vendors, using 10's of different SoC's" thing.
<neverpanic>
I didn't know. You must be furiously scratching your head on why we didn't just use something off the shelf, heh?
<LetoThe2nd>
neverpanic: no.
<LetoThe2nd>
mcfrisk: i know, thats how modern systems are most of the time.
<LetoThe2nd>
neverpanic: i know about industrial, i know about cars (a bit) and i certainly know A LOT about german companies. it would have been a massive surprise if BMW would have used something that somebody else created.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<mcfrisk>
the complexity of German cars...
<neverpanic>
There were talks about buying something initially. I think they talked to Greencurve (name slightly altered), but that all fell apart when their highly praised delta algorithm wasn't actually all that great and one of ours devs wrote something with better delta performance.
<neverpanic>
mcfrisk: Oh yes! :(
<LetoThe2nd>
hehe
thomasd13 has joined #yocto
<mcfrisk>
Canonical has the usual argument: commercial, professional vs. community and open source. Having seen many of the commercial offerings, I can only recommend sticking to open source. Also, don't use Ubuntu in the clouds due to trademark violations, use community supported Debian instead.
Jham has joined #yocto
<phako[m]>
er. Does anyone perhaps know what might have gone wrong here? ERROR: libtirpc-native-1.3.2-r0 do_populate_lic_setscene: Fetcher failure: Unable to find file
<phako[m]>
file://7c/1d/sstate:libtirpc-native::1.3.2:r0::10:7c1d54507dcf6a036d2137eebfdf9eb33c3d2e1734ff8ecc02edba15f963e299_populate_lic.tar.zst.siginfo;downloadfilename=7c/1d/sstate:libtirpc-native::1.3.2:r0::10:7c1d54507dcf6a036d2137eebfdf9eb33c3d2e1734ff8ecc02edba15f963e299_populate_lic.tar.zst.siginfo anywhere. The paths that were searched were:
<phako[m]>
paths that were searched is the correct sstate cache
<rburton>
phako[m]: that usually means something is cleaning the sstate at the same time. the file was there when the sstate scan was done, wasn't when it was unpacked.
<phako[m]>
hrm.
<phako[m]>
odd. this was the only job running on jenkins
thomasd13 has quit [Quit: Leaving]
<qschulz>
phako[m]: no cronjob to remove sstate-cache every now and then?
<rburton>
phako[m]: i blame jenkins :)
<qschulz>
nobody with access to this server or the SSTATE_DIR and ran bitbake -c cleansstate/cleanall of the recipe?
<phako[m]>
qschulz: nah I am just trying to get this build. That is the first yocto build that did not bail out directly at the first call
<phako[m]>
also I am the only one with access to that server who knows what "bitbake" is and how to call it
florian_kc has joined #yocto
<mcfrisk>
and lol, pay/register walled solutions from Canonical. White or toilet paper...
<phako[m]>
crontab -l
<phako[m]>
meh
nate02 has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
<phako[m]>
and now irt just succeeded
<phako[m]>
what.
alessioigor has joined #yocto
<phako[m]>
jenkins ...
<tomzy_0>
<3 I see that love for jenkins is everywhere the same :P
<ldericher>
I use `bitbake -c populate_sdk` to build an SDK for my target arch. Can I also build an SDK for a host arch?
vladest has quit [Ping timeout: 246 seconds]
GNUmoon has joined #yocto
<rburton>
ldericher: when building a SDK, MACHINE is what the sdk targets and SDKMACHINE is what the sdk runs on
<ldericher>
rburton, is there a generic value for an x64 linux machine?
<rburton>
x86-64
<rburton>
the default is "your current host"
<rburton>
see meta/conf/machine-sdk/ for the supported SDKMACHINE values
<ldericher>
so if I let MACHINE be whatever my local.conf specifies - e.g. "some-arm", and SDKMACHINE be "x86-64", the resulting .so-files in the SDK will be "some-arm" or "x86-64"? (It should be the arm, right?)
g-embed has joined #yocto
g-embed has quit [Remote host closed the connection]
<rburton>
there are two parts to the SDK: the host side (the compiler, the tools) and the target (the sysroot)
<rburton>
the former is SDKMACHINE, the latter is MACHINE
g-embed has joined #yocto
kpo_ has quit [Read error: Connection reset by peer]
<hsv>
Are there any resources re editing kernel device tree explained in context of yocto? I'm a noob in both and struggling to make a simple edit.
<phako[m]>
nice. I have just built 4 of the same generic core-image-minimal because all local.conf changes got lost. argh.
* phako[m]
sets fire to jenkins and calls it a week
otavio has quit [Ping timeout: 256 seconds]
otavio has joined #yocto
<rburton>
phako[m]: solid plan
Guest4 has joined #yocto
Guest4 has quit [Client Quit]
<LetoThe2nd>
phako[m]: you forgot the beers.
<phako[m]>
I am past the need of beer.
Guest23 has joined #yocto
<LetoThe2nd>
phako[m]: join the next Yocto BoF and get some Scotch free!
<Guest23>
Hello. How do I define a new image type?
<Guest23>
What I did so far:
<Guest23>
Added my new type to IMAGE_FSTYPES variable
<Guest23>
Created a image_types_mytype.bbclass class, where I define a IMAGE_CMD_mytype function
<Guest23>
Added my new class to the IMAGE_CLASSES variable
<Guest23>
When I try to build the image, I get an error indicating that my IMAGE_CMD_mytype function is being parsed as a Python function, but it is a Shell function
<ThomasRoos[m]>
Any ideas before the first beer about this:
<ThomasRoos[m]>
| ../xorgproto-2021.5/meson.build:22:0: ERROR: Executables created by c compiler arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a15 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/tmp/build/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/xorgproto/2021.5-r0/recipe-sysroot are not runnable.
<rburton>
Guest23: have you looked at the existing image_types.bbclass for similar patterns as yours?
<rburton>
Guest23: hard to debug without seeing anything that you're doing
<rburton>
ThomasRoos[m]: xorgproto?! are you patching or upgrading it?
<LetoThe2nd>
rburton: deleting it.
<rburton>
LetoThe2nd: ?
<rburton>
ThomasRoos[m]: its not wrong, the binaries are not runnable. but no idea why it would want to.
<LetoThe2nd>
rburton: just kidding. things that you should do *after* the first beer. delete xorg.
<rburton>
ah
<ThomasRoos[m]>
Just building with CodeBuild ;)
<ThomasRoos[m]>
And I'm only getting the error there when building e.g. systemd for arm (qemuarm not arm64 or x86...)
<rburton>
our meson does actually support throwing binaries into a qemu-user to run them during the configure but that should work for qemuarm too
<ThomasRoos[m]>
it's working locally totally fine, even in the same docker which is used by CodeBuild, but not in that environment...
<ThomasRoos[m]>
First had that issue, but it's solved by: sysctl -w vm.mmap_min_addr="0"
<ThomasRoos[m]>
qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
<ThomasRoos[m]>
| The Meson build system
PhoenixMage has quit [Ping timeout: 246 seconds]
<rburton>
ah so maybe qemu-user is exploding still
<ThomasRoos[m]>
?
<Guest23>
rburton Yes I did look at image_types.bbclass. There really isn't much more than what I described in the previous message. Here is some of the error messages:
<Guest23>
ERROR: Unable to parse /home/user/project/sources/meta-openembedded/meta-python/recipes-core/images/meta-python-image.bb
<Guest23>
meta-python-image.bb', d=<bb.data_smart.DataSmart object at 0x7f29396f8fd0>, variant=None):
<Guest23>
codeparser.py", line 308, in PythonParser.parse_python(node='\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\
<Guest23>
Added the class to the IMAGE_CLASSES variable
<Guest23>
And added the type to the IMAGE_FSTYPES variable
* g-embed
is very impressed by rburton, RP and qschulz willingness to help with such a vague description. Hoping for the same for me :)
<Guest23>
Simple as that
<rburton>
comment out the TYPEDEP line, that's not often used and might have broken
<Guest23>
Same problem
<qschulz>
don't know if we asked this already but is this reproducible with just poky/oe-core? (no external layer, only this added class and IMAGE_CLASSES+IMAGE_FSTYPES change)?
<qschulz>
I've seen crazy things in 3rd party layers my eyes would like to unsee so maybe there's some weird thing going on there, just trying to rule out the "obvious"
<rburton>
absolutely
<rburton>
so i have a image_type_foo.bbclass which just contains:
<rburton>
IMAGE_CMD:foo () {
<rburton>
bbwarn FOOBAR
<rburton>
}
<rburton>
added to IMAGE_CLASSES, set IMAGE_FSTYPES
<rburton>
all I can say is pastebin your changes to IMAGE_CLASSES and IMAGE_FSTYPES so we know what you're doing, replicate with a plain poky and no annoying vendor layers
<Guest23>
IMAGE_FSTYPES += "tar.bz2 ubi wic.bz2 mytype"
<Guest23>
IMAGE_CLASSES += "image_types_mytype"
<Guest23>
Just added this to my meta-mylayer/conf/machine/mydistro.conf
<rburton>
i'd bisect. fresh poky with no layers, empty class file. add to image_class, check still works. add dummy IMAGE_CMD with just a bbwarn message, check still works. set IMAGE_FSTYPES, check still works.
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
Guest23 has quit [Ping timeout: 260 seconds]
<tomzy_0>
how to efficiently read dependencies graf? let's say I have connman installed on the image, but not provided via IMAGE_INSTALL in my image recipe. How to find out how it goes there?
<qschulz>
bitbake -g <my-image> and check the dot files with your favorite text editor, that's how I would do it
<qschulz>
tomzy_0: ^
<tomzy_0>
I feared that this will be the answer, think that it is time to learn how to read that file :P
<tomzy_0>
thanks
<tomzy_0>
qschulz task on left of `->` was run because of task on right of `->`?
<qschulz>
I don't remember, but look at one do_compile and check where the do_configure is, do_configure is run because of do_compile
<tomzy_0>
makes sense
<tomzy_0>
thanks once again
<g-embed>
OK, so I need some help with kernel development if someone's up for it.
<qschulz>
g-embed: probably the wrong IRC chan but I have none to recommend specifically right now. You can always try your luck and ask the question here
<rburton>
tomzy_0: stuff like connman gets in via packagegroups
<g-embed>
Well it's linux-yocto related
<tomzy_0>
rburton: yeap, got it, it was `packagegroup-core-tools-testapps`
<tomzy_0>
but I dont think I heard about `oe-depends-dot task-depends.dot --why --key` before
<tomzy_0>
need to check that
<rburton>
which comes in via an image feature
<g-embed>
In the end, I need to achieve two things: Modify config to CONFIG_X=y to get a driver built into the kernel, and would be good to also remove another driver (change to CONFIG_Y=m).
<g-embed>
Secondly I need to provide a device-tree for the peripheral in question.
<g-embed>
I think I've been there qschulz. Let me ask my question and if it's answered in docs already you can tell me to go away, ok? :)
<qschulz>
for the second, I don't know what's the recommended solution for out-of-tree device trees.. I would have a patch adding the dts and patching the Makefile to build it along the other dtses
<g-embed>
Device tree might be easiest. Currently meta-VENDOR (placeholder name to protect the not so innocent) has a MACHINE conf file, which includes MACHINE-extra.conf so I'm creating a file like that in my layer.
<rburton>
you set KERNEL_DEVICETREE to the devicetree filename iirc
sakoman has joined #yocto
<g-embed>
It includes KERNEL_DEVICETREE_append = " THING.dtb ". This adds THING.dtb to the boot directory, so it seems OK. Is there anything else required to make that device tree be actually used?
<g-embed>
It = my -extra file. In short, it seems to be picked up and used. But what controls if a dtb is actually read by the kernel?
xmn has quit [Ping timeout: 256 seconds]
<g-embed>
I.e. is it enough that extra-thing.dtb exists in boot directory. I assume not. Or KERNEL_DEVICETREE does the necessary magic for the compilation of the kernel?
<qschulz>
g-embed: something in the bootloader will pick the proper device tree
<qschulz>
that's device specific so cannot help here
<g-embed>
qschulz, oh yeah, you're right. I have also patched the Makefile. Proof of that is that my .dts becomes a .dtb, I believe.
<qschulz>
g-embed: yes dts is only a source file, dtb is the blob, usable by the kernel
<g-embed>
OK, I'll look at bootloader then. I suppose the alternative is to try to patch my dts into the already used <MACHINE>.dts
<qschulz>
that's one way yes
<qschulz>
it depends in the end
<qschulz>
because if MACHINE is actually your HW, it makes sense
<qschulz>
if MACHINE is just a devkit/base whatever your vendor gave you and you have a different product
<qschulz>
you should create another machine.conf file for your specific machine
<qschulz>
and in that scenario you don't need to append the KERNEL_DEVICETREE but just set it
<qschulz>
and if the Yocto layers are done correctly by your vendor, it should just boot your dtb then automagically
<qschulz>
I believe the first entry in KERNEL_DEVICETREE is usually the default dtb
<qschulz>
so maybe doing a :prepend instead of an :append might do the trick
<qschulz>
(don't forget the trailing space for the prpend)
xmn has joined #yocto
<g-embed>
Yeah that all makes sense, problem is there's so much stuff in vendor layer I'm hesitant to remove/replace/copy it.
<g-embed>
So... first attempt is to just extend the MACHINE they have.
<g-embed>
OK, so config baffles me more. One of the list of patches in meta-VENDOR creates a new <MACHINE>_defconfig in arch/arm64/configs, which I would simply presume is the one intended to be used. But they ALSO add a complete file "defconfig" in SRC_URI so that gets copied into the work dir, and then they add a custom task after do_unpack, to copy the "defconfig" to ${B}/.config
<brabander>
does anyone know an good example project that uses multiconfig ?
<g-embed>
I've been trying to modify these files, even adding deliberate errors, etc. but modifications don't seem to stick, and I've still ended up confused about which _actual_ config is being used in the compilation?
<g-embed>
This might be an easy question to answer, what normally gets used? I've watched other yocto docs/instructions say that you SHOULD provide a "defconfig" file. But what then of <MACHINE>_defconfig and the custom copy step?
<qschulz>
g-embed: read the class source code carefully, the only way to know for sure for me (maybe the docs mention it? not sure).
<qschulz>
I've not used config fragments yet for multiple reasons (some of which are apparently not true anymore/were never true)
<qschulz>
so I cannot help there :/
<g-embed>
Yeah, that's yet another road to take. I was hoping to first do either: Replace config completely with my modified file, or successfully patch "their" config. But so far, it's just been confusing.
<g-embed>
so... haven't tried with config fragments. I'm not sure this will help when the whole setup is not done cleanly according to the Yocto way.
<qschulz>
g-embed: if there's already a defconfig, I would just modify it without spending too much time for now on config fragments as I **think** config fragments and user-provided defconfig don't work well together (but that's just an uneducated geuss)
<RP>
g-embed: config fragments are the better way to do it but if it isn't using that, converting it will be a pain. You're therefore right to try and change the existing defconfig
<g-embed>
Thanks for that encouragement. As always "get something that works" is the first step. Still remaining is which "defconfig" is the actual one?
<g-embed>
Sorry, these are basic questions, but how does "defconfig" relate to .config in a kernel build?
<RP>
g-embed: there are two reasons we're struggling to help here. a) this is very device specific as it depends on the bootloader and kernel, both of which the vendor can and probably has changed. b) the vendor didn't use our best practises like config fragments :/
<g-embed>
I mean ultimately, I just want to provide ONE actual full config file, and have that be used.
<RP>
g-embed: if you provide a "file://defconfig" file in SRC_URI, it is possible that it will simply be copied to the .config. It does depend what the vendor did in the kernel recipe though
<g-embed>
RP, They are specifying a custom task to copy it to ${B}/.config
<qschulz>
g-embed: you could have your own defconfig in your own layer by making sure to have a bbappend with FILESEXTRAPATHS:prepend in there
<g-embed>
I just thought it was something standard in the class, because others also show the principle of including a defconfig (without a custom task)
<RP>
g-embed: so can you change the input file to that?
<qschulz>
and that the layer priorities and/or order for your layer makes Bitbake take your defconfig over your vendor's
<g-embed>
RP, I can, it didn't seem to stick, so I started getting confused whether that was actually being used. Specially considering that they go through the trouble of patching the kernel tree in /arch/arm64/configs to add <MACHINE_defconfig> in there
<qschulz>
g-embed: small tip 1) you can check the config used by Bitbake by running bitbake -c menuconfig virtual/kernel
<g-embed>
qschulz, good, haven't tried that
<qschulz>
g-embed: small tip 2) check the defconfig is actually copied from the layer to workdir to ${B}/.config, I remember some bad implementation in some 3rd layer that didn't handle this well
<g-embed>
yeah I've been playing with the layer priorities also. If my layer runs too early, it fails because it also adds a patch on top of vendor layer.
<RP>
g-embed: without knowing which make targets their recipe calls, it is hard for us to know either :(
<RP>
JPEW: FWIW you shouldn't need https://git.yoctoproject.org/poky-contrib/commit/?h=jpew/extra-siggen&id=24eef9888094ea7644d9dae8729ff17cd4ae15a7 since it combines all the parser thread profiles into a single processed log
<qschulz>
g-embed: kernel-yocto is actually the fancy one with config fragment support
<g-embed>
Ah right. So kernel.bbclass is older?
<qschulz>
g-embed: linux-yocto uses this fancy class, vendor recipes usually not so much
<qschulz>
g-embed: they are complimentary IIRC
<qschulz>
all kernel recipes should inherit kernel in some ways
<qschulz>
kernel-yocto class adds some more nice things to it
<qschulz>
linux-yocto vs linux-imx!
<qschulz>
s/vs/!=/
<g-embed>
Well, long way around back to the same place I think. It all suggests to me I just gotta get the config into ${B}/.config .
<g-embed>
The other stuff the vendor layer is doing, creating other named files, patching kernel tree with new configs... it just seems redundant. But that's the thing it's so hard when there are confusing details all around.
<qschulz>
g-embed: tbf, the kernel configuration is pretty hard
<RP>
g-embed: my suggestion would be to change ${B}/.config and see if that works and makes the change you need. Ignore the other bits unless that doesn't work in which case you'll have to investigate
<qschulz>
and that can be done via the menuconfig task. Once working, you can then run savedefconfig task and take the defconfig out of ${B}/defconfig and put it into your layer
<g-embed>
OK, so looking at some of my older attempts it doesn't seem like the copy works.
<g-embed>
so if I addtask in the same way they did in meta-VENDOR: "addtask copy_defconfig after do_unpack before do_merge_delta_config", would my copy run after or before theirs? Maybe it gets overwritten.
<g-embed>
My BBFILE_PRIORITY is higher, i.e. my append runs after vendor.
Guest1396 has quit [Ping timeout: 264 seconds]
<LetoThe2nd>
completely different thing, has anybody accidentially heard of a yocto-based build for esp32 freertos/baremetal?
seninha has quit [Ping timeout: 252 seconds]
<g-embed>
I've been resisting to fork and modify meta-VENDOR but maybe it's the only way to get control of this thing :(
xmn has quit [Quit: xmn]
sotaover1ide has joined #yocto
xmn has joined #yocto
kscherer has joined #yocto
g-embed has quit [Ping timeout: 264 seconds]
tor has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
dgriego has joined #yocto
nemik_ has quit [Ping timeout: 256 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 246 seconds]
nemik_ has joined #yocto
PascalBach[m] has quit [Quit: You have been kicked for being idle]
Guest23 has joined #yocto
malsyned has joined #yocto
prabhakarlad has joined #yocto
seninha has joined #yocto
malsyned has quit [Ping timeout: 256 seconds]
alessioigor has quit [Ping timeout: 260 seconds]
alessioigor has joined #yocto
GillesM has quit [Quit: Leaving]
malsyned has joined #yocto
florian_kc has quit [Ping timeout: 265 seconds]
florian has quit [Quit: Ex-Chat]
malsyned has quit [Ping timeout: 264 seconds]
alessioigor has quit [Quit: alessioigor]
rfuentess has quit [Remote host closed the connection]
vladest has quit [Read error: Connection reset by peer]
arielmrmx has quit [Remote host closed the connection]
grsandeep85 has joined #yocto
invalidopcode7 has quit [Remote host closed the connection]
invalidopcode7 has joined #yocto
grsandeep85 has quit [Quit: Client closed]
grsandeep85 has joined #yocto
amitk_ has quit [Ping timeout: 252 seconds]
xmn has quit [Quit: ZZZzzz…]
florian_kc has quit [Ping timeout: 246 seconds]
mckoan_ has quit [Read error: Connection reset by peer]
mckoan|away has joined #yocto
malsyned has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
malsyned has quit [Ping timeout: 256 seconds]
malsyned has joined #yocto
seninha has quit [Ping timeout: 260 seconds]
DvorkinDmitry has quit [Remote host closed the connection]
malsyned has quit [Ping timeout: 268 seconds]
seninha has joined #yocto
<kiwi_29_[m]>
reposting for some/any insight
<kiwi_29_[m]>
Hello... I upgraded GO compiler in my yocto dunfell from default 1.14 .....(available as part of standard poky meta/recipes-devtools/go) to 1.19 by copying go 1.19 recipes available in langdale to my customlayer . When I used to generate sdk using. bitbake -c populate_sdk DISTRO_NAME before go upgrade, it used to include go compiler version 1.14. After upgrading to go 1.19, I m not getting any go version inside sdk
<kiwi_29_[m]>
I m wondering how was this recipe included previously when I compiled toolchain using bitbake -c populate_sdk DISTRO_NAME
<kiwi_29_[m]>
I do see some code related to this in meta/recipes-core/meta/meta-go-toolchain.bb , but I am not sure how to use it to include go 1.19 in the sdk
GNUmoon has joined #yocto
xmn has joined #yocto
malsyned has joined #yocto
malsyned has quit [Ping timeout: 252 seconds]
manuel1985 has joined #yocto
nemik_ has quit [Ping timeout: 268 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 260 seconds]
nemik_ has joined #yocto
florian_kc has joined #yocto
GNUmoon has quit [Ping timeout: 255 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
malsyned has joined #yocto
malsyned has quit [Ping timeout: 256 seconds]
Minvera has quit [Remote host closed the connection]
grsandeep85 has quit [Quit: Client closed]
kscherer has quit [Quit: Konversation terminated!]
grsandeep8574 has joined #yocto
grsandeep8574 has quit [Client Quit]
sakoman has quit [Quit: Leaving.]
malsyned has joined #yocto
malsyned has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
<RP>
kiwi_29_[m]: In master the code looks like meta/classes-recipe/populate_sdk_base.bbclass: ${@bb.utils.contains('SDK_TOOLCHAIN_LANGS', 'go', 'packagegroup-go-cross-canadian-${MACHINE}', '', d)}
<RP>
kiwi_29_[m]: I don't remember dunfell, it was different but hopefully that gives a hint of where/what to look for