kscherer has quit [Quit: Konversation terminated!]
<moto-timo>
I'm trying to build `classpath` from `meta-java` (`kirkstone`) and it seems like `inherit pkgconfig` is not actually populating `pkg-config-native` nor the `pkg.m4` macros. Does anyone remember issues where the order of the `inherit` affected this?
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
Thorn has joined #yocto
<PhoenixMage>
tlwoerner: Hey Travis, is there any reason that the rockchip.wks creates partitions for the loaders and reserved space, etc rather then using --no-table? Or is it left over when such an option wasnt available or something?
Thorn has quit [Ping timeout: 250 seconds]
vladest1 has joined #yocto
vladest has quit [Remote host closed the connection]
vladest1 is now known as vladest
Thorn has joined #yocto
sakoman has quit [Quit: Leaving.]
florian__ has joined #yocto
Guest60 has joined #yocto
rfuentess has joined #yocto
<Entei[m]>
How do I make all dev packages to be included in the rootfs?
florian__ has quit [Ping timeout: 256 seconds]
florian has joined #yocto
florian__ has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
leon-anavi has joined #yocto
xmn has quit [Ping timeout: 248 seconds]
rfuentess has quit [Remote host closed the connection]
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
Guest46 has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
yannd has joined #yocto
<abelloni>
Entei[m]: you can add dev-pkgs to IMAGE_FEATURES
<tomzy_0[m]>
ERROR: deepview-rt-2.4.46-aarch64-r0 do_package_qa: QA Issue: /usr/lib/python3.10/site-packages/bin/deepview-modelclient contained in package deepview-rt requires /work/build-wayland/tmp/work/armv8a-poky-linux/deepview-rt/2.4.46-aarch64-r0/recipe-sysroot-native/usr/bin/nativepython3, but no providers found in RDEPENDS:deepview-rt? [file-rdeps]
<tomzy_0[m]>
is it possible that package needs something natvie?
<tomzy_0[m]>
s/natvie?/`native`?/
<mcfrisk>
tomzy_0[m]: the package installs a python script but doesn't declare runtime dependency to python?
<tomzy_0[m]>
mcfrisk: setting python3 to RDEPENDS does not help, I wonder why it requires `recipe-sysroot-native/usr/bin/nativepython3`
<tomzy_0[m]>
I can always set INSANE_SKIP but that does not resolve the real issue
<mcfrisk>
tomzy_0[m]: don't build or install the python bits if they are not needed and which cause this dependency. And they may be hard coding the shebang #! or other paths to the native tool sysroot which is wrong.
Thorn has quit [Ping timeout: 240 seconds]
Guest7 has quit [Quit: Client closed]
jpgl82 has joined #yocto
vladest1 has joined #yocto
vladest has quit [Ping timeout: 250 seconds]
vladest1 is now known as vladest
<tomzy_0[m]>
if that going to be installed in the target, should not be there something like #!/usr/bin/python3 ?
<IgorKha>
Colleagues, I'm trying to build Yocto through GitLab Runner and I encountered an issue where the kernel repository is being fetched from the recipe, and in the log, I see this: https://pastebin.pl/view/200668a7 Interestingly, when I pull this repository with the runner separately, it works fine, but not during the build process. I haven't been able
<IgorKha>
to find any helpful information through online search either. Any ideas?
gsalazar has joined #yocto
jpgl82 has joined #yocto
bryanb has quit [Remote host closed the connection]
tleb has quit [Remote host closed the connection]
dmoseley has quit [Ping timeout: 250 seconds]
IgorKha91 has joined #yocto
bryanb has joined #yocto
tleb has joined #yocto
IgorKha has quit [Ping timeout: 245 seconds]
IgorKha91 has quit [Ping timeout: 245 seconds]
jpgl82 has quit [Quit: Client closed]
IgorKha has joined #yocto
igor has joined #yocto
bps2 has quit [Ping timeout: 240 seconds]
igor has quit [Quit: Konversation terminated!]
igor has joined #yocto
igor has quit [Client Quit]
IgorKha has quit [Ping timeout: 245 seconds]
IgorKha has joined #yocto
<mcfrisk>
IgorKha: kernel git repository is huge, if gitlab runner is a spawned container without persistent download cache and with throttlet networking, then builds will be tricky to get running. I would upload download and sstate caches from a local build to a persisten storage used by gitlab runner to bootstrap the builds there.
<IgorKha>
The kernel repository has been cleaned and occupies 1.6GB of space. The runner successfully pulls it as a separate task without any issues. However, the problem arises when the repository is pulled during the build process through the recipe.
amitk has quit [Ping timeout: 246 seconds]
<mcfrisk>
IgorKha: Do you have bitbake download cache set as persistent across build? If not, then every build will download from scratch and will likely time out. Also networking may be limited
<mcfrisk>
IgorKha: it's not thet kernel recipe with problems, it's the SSTATE_DIR and DL_DIR variables in local.conf. If those directories are not persistent across builds, then each build will download from scratch, from your kernel SRC_URI locations and all other recipes locations as well.
IgorKha has quit [Ping timeout: 250 seconds]
IgorKha23 has joined #yocto
<mcfrisk>
and if your custom server is slow with your custom gitlab runner, then you need to investigate why. From a local bitbake build you can take the build/downloads and build/sstate-cache directories and populate the inital gitlab runner side builds so that only delta needs to recompiled and downloaded
Guest60 has quit [Quit: Client closed]
<IgorKha23>
I understand the concept of caching, but it is not yet implemented and will be addressed in the future. At this stage, I want to understand the root cause of the problem so that I can know how to fix it in the future. I believe that providing a workaround solution is not entirely appropriate in my opinion.
<IgorKha23>
The local server is powerful enough, with an i7-13700K processor and a 10-gigabit link to the repository. There shouldn't be any issues with that setup.
<mcfrisk>
IgorKha23: then you should investigate the download path from gitlab runner to your custom download server
amitk has joined #yocto
<sudip>
IgorKha23: just something I faced before, you are using "protocol=ssh", do you need to provide any ssh key?
IgorKha23 has quit [Ping timeout: 250 seconds]
IgorKha has joined #yocto
bps2 has joined #yocto
IgorKha has quit [Ping timeout: 240 seconds]
seninha has quit [Quit: Leaving]
IgorKha23 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
IgorKha23 has quit [Client Quit]
<kayterina[m]>
Hello, if a recipe installs a file in do_install, and the recipe is used only as a DEPEND (no rdepend) is it logical that the file will not end in the running system?
<kayterina[m]>
*the file is in SRC_URI
bps3 has joined #yocto
bps2 has quit [Ping timeout: 246 seconds]
<mcfrisk>
kayterina[m]: yes, the DEPENDS means a build dependency and the recipe will be compiled and output made available to recipes which need it, and in output package repository. An RDEPENDS runtime dependency from something already installed to image(s) or direct IMAGE_INSTALL is needed to actually install to image(s).
<jclsn>
How can I find out if u-boot is compiling with the right defconfig? I checked it out with devtool and changed the defconfig in the configs folder. u-boot recompiles, but the change is not there after flashing it
otavio has joined #yocto
jhfjhfhgcfghfhg has quit [Ping timeout: 246 seconds]
IgorKha has joined #yocto
<JPEW>
RP: Hmm, that seems like a missing dependency problem, but we have this: `do_rootfs[recrdeptask] += "do_create_spdx do_create_runtime_spdx"` so I'm not sure the problem
<JPEW>
Or the provider changed?
IgorKha has quit [Ping timeout: 240 seconds]
<RP>
JPEW: I think the provider changed linux-yocto -> linux-yocto-rt
<RP>
JPEW: I just mailed out the patch series so far. I think this set of it is probably ok to merge?
<mcfrisk>
jclsn: I would "bitbake -c install u-boot" and check the used config in "bitbake -c devshell u-boot". If it's not clear what is setting UBOOT_MACHINE variable, then use "bitbake -e u-boot"
<Chocobo>
This is a stupid question... but if I delete the files in my images directory, is there a way to get yocto to put them back without rebuilding everything?
<RP>
Chocobo: or delete the do_deploy stamps in tmp/stamps and then build your target again
<RP>
JPEW: I left the packagegroup patch for now, not 100% sure on that as you were concerned about it?
<Chocobo>
Hrm, it is more than just the rootfs. It is also things like u-boot missing.
<RP>
Chocobo: so clean those recipes or remove all the do_deploy stamps
<Chocobo>
RP will do - bummer, I was hoping there was a way to deploy everything. Not a huge deal
<Chocobo>
The problem is, I don't know the recipe associated with some of the files (boot.scr) for example
<RP>
Chocobo: "find -name *do_deploy*" ?
<RP>
in tmp/stamps
sakoman has joined #yocto
Xagen has joined #yocto
<Chocobo>
yeah, it isn't in there. dang.
<Chocobo>
Well I won't do this again.
<Chocobo>
huh, it is in here: build/tmp/deploy/images/zynq-generic/boot.scr which makes me think that cleaning and deploying the image I am using should copy it over.
<Chocobo>
I wonder if it would be a bad idea to remove all do_deploy stamps
<Chocobo>
oh... distclean, followed by a build did it.
xmn has joined #yocto
<Chocobo>
Alright, I have another question but this one might be specific to petalinx - building the disk image (petalinux-image-minimal) builds u-boot, the kernel, the FSBL, etc. But it doesn't generate the BOOT.BIN that goes into QSPI. That requires another command (petalinux-package). I would love to have the BOOT.BIN in my rootfs though. Is this something I will likely need to do manually, outside of the
<Chocobo>
build?
<RP>
Chocobo: I have no idea about petalinux. "distclean" isn't even a thing in a standard build :/
<zeddii>
fray ^^^
<fray>
Chocobo Follow Yocto Project workflows and don't use the PetaLinux wrappers if you want that behavior. langdale-next branch is up to date with 2023.1, also has support for 2022.2 and 2022.1. It generates all of the build artfiacts in the tmp/deploy/ directory structure
<fray>
any commends that involve petalinux-config or petalinux-build are petalinux specific
<fray>
petalinux-build builds all of the boot artifacts outside of the YP build system
<Chocobo>
I hate that we use petalinux, but unfortunately I don't think I have much say in this partiticular situation. I will hit up the forums and ask them. Thanks for the help.
<fray>
petalinux is designed for quick start and development.. it is NOT appropriate for production
<fray>
there is no long-term support with petalinux, thus not appropriate for production on anything connected to a network
<JPEW>
RP: Ah, I missed that it was modifying packagegroup.bbclass
<JPEW>
RP: Yes that patch is fine, sorry
<Chocobo>
I wonder how much of a challenge it would be to convert a petalinux project over to stock yocto.
mborzecki has joined #yocto
<RP>
JPEW: ok with the other patches going in?
<JPEW>
yep
<JPEW>
RP: We might have to completely move runtime dependency calculations into image creation to fix the providers problem
<JPEW>
Otherwise packages are always going to refer to the specific runtime provider at build time, instead of image creation time
<RP>
JPEW: that might be fine, I was wondering about that
<JPEW>
Unfortunately I have a bit of a fire to put out today, but I can look next week
<RP>
JPEW: in theory if these change, things should rebuild but there are "special" dependencies which don't do that and assume ABI/API are safe
<JPEW>
Right
<RP>
JPEW: no problem, you've already spent a lot of time on this
<JPEW>
The same problem _might_ exist at build time too, but I don't know what we can do about that exactly
<RP>
We should only be assuming runtime, buildtime I think would trigger rebuilds
<JPEW>
But we can fix the runtime one and then figure out where to go from there
<JPEW>
Cool
<RP>
I did wonder about just disabling create_spdx for that test for now
<RP>
Not quite the right thing to do, but...
<JPEW>
I wouldn't; that is a real-world problem that users will encounter and complain about
<RP>
JPEW: are you saying we should wait to fix that issue before merging the current patches?
<JPEW>
No, just before enabling by default
<JPEW>
The current patch set is in a much better spot than before
<RP>
Right, I wasn't going to push that until we resolve the test issues
<RP>
Yes, the current patchset helps massively
<RP>
I am a bit worried about what we do for the stable releases and this :/
<RP>
sakoman will no doubt ask us this
<JPEW>
I think the "safest" thing to do would be to not merge the sstatesig patch as that will keep it all together for current users
<JPEW>
Keep it working, but also make the improvements
<JPEW>
Once we have all the actual signature problems sorted out, then the sstatesig patch will be OK
<RP>
JPEW: Given the sstate sig test failures, I suspect people would struggle to use this in production properly with sstate
<JPEW>
mmm, ya good point
<RP>
I can merge without that change for now though
amitk has quit [Ping timeout: 256 seconds]
seninha has quit [Read error: Connection reset by peer]
seninha has joined #yocto
* sakoman
hasn't been following the discussion, so he wouldn't even know what to ask about!
seninha has quit [Client Quit]
seninha has joined #yocto
florian has quit [Quit: Ex-Chat]
<RP>
sakoman: create-spdx has bugs. I've just merged a load of patches fixing them. The bugs are present in older releases. The patches are invasive/tricky
<sakoman>
RP: Thanks for the explanation!
florian__ has quit [Ping timeout: 240 seconds]
seninha has quit [Quit: Leaving]
TundraMan is now known as marka
ptsneves has quit [Ping timeout: 240 seconds]
olani- has quit [Ping timeout: 240 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
florian__ has joined #yocto
bps3 has quit [Ping timeout: 240 seconds]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
adrian__ has quit [Ping timeout: 265 seconds]
florian__ has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
<kayterina[m]>
is it bad practice to cd in a subdirectory in a do_configure task? like "cd ${S}/deep/deeper/" ./configure . "configure" does not run directly from ${S}
<JPEW>
kayterina[m]: I think it's OK, but you want to make sure you don't leave the CWD in an unexpected spot, so `(cd ${S}/deep/deeper && ./configure .)` to run it in a subshell is probably better
<moto-timo>
seems like if a native recipe DEPENDS on ca-certificates-native, we should be able to tell curl-native to use those from recipe-sysroot-native?