**** BEGIN LOGGING AT Fri Jan 29 03:02:12 2021
Jan 29 08:16:57 <wyre> abelloni, well, I was actually looking for info about creating recipes for python modules that are not shipped in openembedded or yocto repositories
Jan 29 08:18:35 <wyre> and also how to handle gpio signals and pwms in the i.MX6
Jan 29 08:41:31 <LetoThe2nd> yo dudX
Jan 29 08:46:29 <mckoan> good morning LetoThe2nd, everybody
Jan 29 09:20:01 <malinus> I'm a bit confused. I can see my linux[...].bb, gets linux 4.14 as expected. I can also see that I end up with linux 4.14 on my machine. When I look in the downloads directory I can't however find linux 4.14, all there is, is linux 5.0?
Jan 29 09:20:38 <malinus> I thought all sources ended up in the download directory?
Jan 29 09:22:54 <RP> malinus: they definitely should
Jan 29 09:23:15 <RP> malinus: is it a git checkout instead of a tarball in the git2 subdir?
Jan 29 09:25:11 <malinus> RP: yes oh yeah, it's a git checkout. I guess that's why?
Jan 29 09:25:34 <qschulz> mornin everybody
Jan 29 09:29:01 <malinus> RP: yeah it all ends in tmp/work-shared. Thanks!
Jan 29 09:29:36 <LetoThe2nd> malinus: theres a downloads/git directory AFAIK
Jan 29 09:33:27 <malinus> LetoThe2nd: that seems to just be the .git for that particular directory. The repo itsef seems to be placed in tmp/work-shared.
Jan 29 09:33:43 <malinus> this is warrior though, so stuff might have been changed since
Jan 29 09:36:52 <LetoThe2nd> malinus: nah that doesn't sound right. have you looked through downloads/git2 ? unless something was already in sstate, it should have been cloned there. thats at least my understanding of the git fetcher.
Jan 29 09:39:31 <RP> LetoThe2nd: that matches my understanding of it too :)
Jan 29 09:39:52 <LetoThe2nd> RP: hrhrhr
Jan 29 09:49:31 <LetoThe2nd> RP: its starting to be scary how often i try to explain something which you even confirm then!
Jan 29 09:49:51 <LetoThe2nd> i'm starting to doubt my qualities of leading people astray.
Jan 29 09:52:26 <malinus> nope, I'm not seeing the kernel as a downloads/git2.[...]
Jan 29 09:54:57 <RP> malinus: its either there or as a mirror tarball in downloads/
Jan 29 09:55:45 <malinus> RP: all I can find is the linux-5.0.tar.xz in the download directory
Jan 29 09:56:22 <malinus> all I can find, when I look for files with linux in the name, mind
Jan 29 09:56:32 <RP> malinus: are you only looking at linux* or *linux* ?
Jan 29 09:56:47 <RP> malinus: which kernel recipe are you using?
Jan 29 09:57:25 <RP> Saur: Is Ross still maintaining meta-gplv2 with you?
Jan 29 09:58:36 <malinus> RP: link to line https://github.com/elk-audio/meta-raspberrypi-elk/blob/warrior/recipes-kernel/linux/linux-raspberrypi-ipipe_4.14.bb#L11
Jan 29 10:00:38 <RP> malinus: so there should be a directory in git2/ and/or a mirror tarball in downloads/ . They will have "git2", "github" and other bits of the url in the name
Jan 29 10:07:52 <mccc> Hi, I'm having trouble building mariadb from meta-oe in dunfell with "pam" in DISTRO_FEATURES after it had an update earlier this month to bump mariadb from 10.4.12 to 10.4.17 for cve fixes.  On master, the commit that updates 10.4.12 to 10.5.4 includes an extra change in its do_install that fixes this for me in dunfell when I patch it in locally.  May I ask where to report this?
Jan 29 10:10:59 <RP> mccc: the oe-devel mailing list, perhaps sending a patch tagged for dunfell in the subject line
Jan 29 10:12:37 <mccc> Okay, thanks RP.
Jan 29 11:02:50 <RP> mcfrisk: looking at the performance numbers from master, it may not be those patches having the majority of the performance change :/
Jan 29 11:03:04 <RP> mcfrisk: its looking like it may be something else in master-next
Jan 29 11:03:26 <RP> I don't quite understand what though as autoconf 2.70 wasn't there in the test
Jan 29 11:24:23 <intera91> good morning
Jan 29 11:24:41 <intera91> facing a stupid problem with a library at the mo and it has been an 4 days exercise in frustration so far
Jan 29 11:25:06 <intera91> ok here goes: I have a project (cmake based) which produces an executable in build/bin dir and a library in build/lib, lib is versioned and linked now the executable gets in package, package split and so on but nothing in the build/lib directory is taken there the cmake(s) are doing their job and build succeeds either in yocto or outside of it
Jan 29 11:25:14 <intera91> I guess what I would like to know is why the content of the lib dir (against which my executable is linked) gets completely ignored
Jan 29 11:27:14 <qschulz> intera91: ok, found it
Jan 29 11:27:27 <intera91> yes?
Jan 29 11:28:19 <qschulz> ah no :(
Jan 29 11:28:28 <intera91> blast
Jan 29 11:28:30 <qschulz> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cmake.bbclass?h=thud#n109 seems to be correct
Jan 29 11:29:05 <qschulz> try to dump this variable from your Cmake to see if it is correctly set/passed/not overridden
Jan 29 11:31:07 <qschulz> your symlink is also in /lib right?
Jan 29 11:31:31 <intera91> yes
Jan 29 11:33:02 <qschulz> intera91: have you already said which version of yocto you're using?
Jan 29 11:33:32 <intera91> which means in ~/workspace/poke/build-toaster-2/tmp/work/corei7-64-poky-linux/myprogram/build/lib/
Jan 29 11:34:03 <intera91> whereas exec is in ~/workspace/poky/build-toaster-2/tmp/work/corei7-64-poky-linux/rinicom/1.0-r0/build/bin
Jan 29 11:34:23 <intera91> sorry forgot the 1.0-r0 in previous line
Jan 29 11:34:53 <intera91> On branch gatesgarth
Jan 29 11:34:53 <intera91> Your branch is up-to-date with 'origin/gatesgarth'.
Jan 29 11:35:55 <qschulz> intera91: have you dumped the content of CMAKE_LIBRARY_PATH from your cmakelists.txt?
Jan 29 11:36:19 <intera91> doing that now
Jan 29 11:36:38 <intera91> repacking source tree and rebuilding recipe
Jan 29 11:37:16 <intera91> added this line: message("Value of CMAKE_LIBRARY_PATH: ${CMAKE_LIBRARY_PATH}")
Jan 29 11:40:22 <stuom1> how can I conditionally add package to image from the package's recipe? Something like IMAGE_INSTALL += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}" in package recipe does not seem to work
Jan 29 11:40:43 <LetoThe2nd> stuom1: cue yocto chant #1 please.
Jan 29 11:43:02 <stuom1> so only way is to add mypackage1-ptest mypackage2-ptest times N to image recipe?
Jan 29 11:44:05 <stuom1> that works but I just wanted to do something clever :P
Jan 29 11:44:05 <qschulz> stuom1: why not put it into the IMAGE_INSTALL directly?
Jan 29 11:44:41 <qschulz> stuom1: you could always have a RRECOMMENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}"
Jan 29 11:44:59 <qschulz> this works only for DISTRO_FEATURES and MACHINE_FEATURES
Jan 29 11:45:07 <qschulz> or an RDEPENDS, whatever
Jan 29 11:45:08 <LetoThe2nd> stuom1: well *TECHNICALLY* you could do some RDEPENDS_${PN}_append upon the distro feature. but, hard to grasp for others.
Jan 29 11:45:14 <LetoThe2nd> qschulz: meh.
Jan 29 11:45:17 <qschulz> LetoThe2nd: too slow
Jan 29 11:45:39 <LetoThe2nd> yeah.
Jan 29 11:45:58 <intera91> qschulz: log.do_configure: value of CMAKE_LIBRARY_PATH: /usr/lib;/lib
Jan 29 11:47:58 <qschulz> intera91: I'm out of ideas
Jan 29 11:48:27 <qschulz> LetoThe2nd: maybe an idea about this cmake thingy of intera91 by any chance? might be related to the CMakeLists, we haven't checked that yet
Jan 29 11:48:43 <qschulz> intera91: your lib is in the recipe-sysroot of the recipe that depends on it right?
Jan 29 11:49:05 <intera91> one sec
Jan 29 11:49:09 <intera91> checking
Jan 29 11:49:13 <LetoThe2nd> i've followed the problem loosely, but no obvious idea.
Jan 29 11:49:39 <LetoThe2nd> proper debugging assistance probably needs source access + a paycheck ;-)
Jan 29 11:50:33 <LetoThe2nd> almost certainly something in the cmakelists is off but what - no imminent idea.
Jan 29 11:51:23 <intera91> @qsc
Jan 29 11:52:02 <intera91> qschulz: the library is neither in the recipe-sysroot nor the recipe-sysroot-native
Jan 29 11:52:19 <intera91> should it be? as the project builds it\
Jan 29 11:55:07 <olani[m]> intera91: Wasn't both lib and app built in the same package and recipe?
Jan 29 11:57:02 <olani[m]> intera91: You keep saying that the exe is in build/bin and the lib in build/lib. That is fine, and the linking obviously works as the compile task completes.
Jan 29 11:57:06 <intera91> olani[m]: yes
Jan 29 11:57:33 <intera91> olani[m]: correct
Jan 29 11:57:39 <olani[m]> But are both installed?  Can you find the exe in image/bin and the lib in image/lib?
Jan 29 11:57:56 <olani[m]> intera91: If you do not, then your install is still broken.
Jan 29 11:58:11 <intera91> and the library is versioned and symbolicaly linked
Jan 29 11:58:30 <olani[m]> intera91: And I'm still speaking of the image dir in your workdir, not about any generated rootfs.
Jan 29 11:58:44 <intera91> @olani
Jan 29 11:59:04 <intera91> olani[m]: yes we are on the same wavelength
Jan 29 11:59:35 <intera91> olani[m]: the image directory only contains the bin directory
Jan 29 12:02:16 <olani[m]> Then that is the first thing you have to solve.  Either in your cmake files or with a doinstallappend.
Jan 29 12:02:50 <intera91> well the cmake puts it in build/lib so maybe a doinstallappend
Jan 29 12:04:11 <olani[m]> intera91: I don't think it is the install step that puts it in build/lib, its just the compile step.  The cmake install step is what puts the exe in image/bin.
Jan 29 12:04:52 <intera91> oh you mean in terms of yocto scripts : yes
Jan 29 12:04:52 <olani[m]> intera91: I suspect that the cmake class is set up to use separate source and build directories, which means that the build dir should also contain any .o files.
Jan 29 12:05:11 <intera91> oh ok
Jan 29 12:05:37 <olani[m]> intera91: Also in cmake steps. bitbake docompile calls cmake build (or whatever) and bitbake doinstall calls cmake install (or whatever)
Jan 29 12:06:12 <olani[m]> intera91: Later, the packaging steps will only look in the image dir.
Jan 29 12:06:48 <qschulz> intera91: are you using CMAKE_INSTALL_LIBDIR for installing the libs?
Jan 29 12:06:58 <intera91> no
Jan 29 12:07:09 <qschulz> also it'll need to be changed as it is set to libdir and not base_libdir as you want
Jan 29 12:07:46 <qschulz> and use DESTDIR too in your cmake
Jan 29 12:08:13 <qschulz> honestly, you could probably go faster by reading the content of cmake.bbclass because I definitely don't know more than you on cmake
Jan 29 12:08:29 <qschulz> i'll stop here and let others help with your cmake issues :)
Jan 29 12:09:08 <qschulz> first step is to get cmake to install your files in image/ directory in your recipe WORKDIR, once that's done, then if there's still an issue, I can chime in again :)
Jan 29 12:20:32 <stuom1> qschulz LetoThe2nd: I tried both RRECOMMENDS and RDEPENDS, but ptest package is not in the image. Maybe it conflicts with ptest bbclass somehow
Jan 29 12:20:54 <LetoThe2nd> stuom1: very well possible, yes.
Jan 29 12:38:22 <hmw1> hi, i made some changes the default kernel config i used pushed it to my local git server and if i try to rebuild the kernel it hangs on do_configure  ( +30min)
Jan 29 12:48:34 <RP> hmw1: have a look at the logs for the task, they should probably give some clue as to what its doing
Jan 29 12:54:49 <pankaj347> Hi all i am trying to build an image on riscv with oe-core but i am getting error
Jan 29 12:55:04 <pankaj347> Pankaj/openembedded/Build_dir$ bitbake core-image-base
Jan 29 12:55:05 <pankaj347> Loading cache: 100% |########################################################################################################################################################################| Time: 0:00:00
Jan 29 12:55:05 <pankaj347> Loaded 2409 entries from dependency cache.
Jan 29 12:55:06 <pankaj347> NOTE: Resolving any missing task queue dependencies
Jan 29 12:55:06 <pankaj347> WARNING: preferred version 5.10.11 of linux-mainline not available (for item virtual/kernel)
Jan 29 12:55:07 <pankaj347> WARNING: versions of linux-mainline available: 5.10.x+gitAUTOINC+b97134d151 5.5.x+gitAUTOINC+d542c06f76
Jan 29 12:55:07 <pankaj347> WARNING: preferred version 5.10.11 of linux-mainline not available (for item kernel-modules)
Jan 29 12:55:08 <pankaj347> WARNING: versions of linux-mainline available: 5.10.x+gitAUTOINC+b97134d151 5.5.x+gitAUTOINC+d542c06f76
Jan 29 12:55:08 <pankaj347> WARNING: preferred version 9.% of libgcc not available (for item libgcc)
Jan 29 12:55:09 <pankaj347> WARNING: versions of libgcc available: 8.3.0
Jan 29 12:55:09 <pankaj347> WARNING: preferred version 9.% of gcc not available (for item gcc)
Jan 29 12:55:10 <pankaj347> WARNING: versions of gcc available: 8.3.0
Jan 29 12:55:10 <pankaj347> WARNING: preferred version 5.10.11 of linux-mainline not available (for item kernel-image)
Jan 29 12:55:11 <pankaj347> WARNING: versions of linux-mainline available: 5.10.x+gitAUTOINC+b97134d151 5.5.x+gitAUTOINC+d542c06f76
Jan 29 12:55:11 <pankaj347> WARNING: preferred version 5.10.11 of linux-mainline not available (for item kernel-base)
Jan 29 12:55:12 <pankaj347> WARNING: versions of linux-mainline available: 5.10.x+gitAUTOINC+b97134d151 5.5.x+gitAUTOINC+d542c06f76
Jan 29 12:55:12 <pankaj347> WARNING: preferred version 5.10.11 of linux-mainline not available (for item kernel-image-fitimage)
Jan 29 12:55:13 <pankaj347> WARNING: versions of linux-mainline available: 5.10.x+gitAUTOINC+b97134d151 5.5.x+gitAUTOINC+d542c06f76
Jan 29 12:55:24 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libg2c-dev)
Jan 29 12:55:25 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:25 <pankaj347> WARNING: preferred version 9.% of gcc not available (for item cpp)
Jan 29 12:55:26 <pankaj347> WARNING: versions of gcc available: 8.3.0
Jan 29 12:55:26 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libquadmath)
Jan 29 12:55:27 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:27 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libquadmath-dev)
Jan 29 12:55:28 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:28 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libg2c)
Jan 29 12:55:29 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:29 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libssp-dev)
Jan 29 12:55:30 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:30 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libgomp)
Jan 29 12:55:31 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:31 <pankaj347> WARNING: preferred version 9.% of gcc-runtime not available (for item libgomp-dev)
Jan 29 12:55:32 <pankaj347> WARNING: versions of gcc-runtime available: 8.3.0
Jan 29 12:55:32 <pankaj347> WARNING: preferred version 9.% of gcc-cross-canadian-riscv64 not available (for item gcc-cross-canadian-riscv64)
Jan 29 12:55:33 <pankaj347> WARNING: versions of gcc-cross-canadian-riscv64 available: 8.3.0
Jan 29 12:55:44 <pankaj347> WARNING: preferred version 9.% of gcc not available (for item gcc-symlinks)
Jan 29 12:55:45 <pankaj347> WARNING: versions of gcc available: 8.3.0
Jan 29 12:55:45 <pankaj347> WARNING: preferred version 9.% of gcc not available (for item cpp-symlinks)
Jan 29 12:55:46 <pankaj347> WARNING: versions of gcc available: 8.3.0
Jan 29 12:55:46 <pankaj347> WARNING: preferred version 9.% of gcc not available (for item g++-symlinks)
Jan 29 12:55:47 <pankaj347> WARNING: versions of gcc available: 8.3.0
Jan 29 12:55:47 <pankaj347> WARNING: preferred version 9.% of gcc not available (for item g++)
Jan 29 12:55:48 <pankaj347> WARNING: versions of gcc available: 8.3.0
Jan 29 12:55:48 <pankaj347> WARNING: preferred version 9.% of nativesdk-libgcc not available (for item nativesdk-libgcc)
Jan 29 12:55:49 <pankaj347> WARNING: versions of nativesdk-libgcc available: 8.3.0
Jan 29 12:55:49 <pankaj347> Build Configuration:
Jan 29 12:55:50 <pankaj347> BB_VERSION           = "1.49.0"
Jan 29 12:55:50 <pankaj347> BUILD_SYS            = "x86_64-linux"
Jan 29 12:55:51 <pankaj347> NATIVELSBSTRING      = "ubuntu-18.04"
Jan 29 12:55:51 <pankaj347> TARGET_SYS           = "riscv64-oe-linux"
Jan 29 12:55:52 <pankaj347> MACHINE              = "pankajsemi"
Jan 29 12:55:52 <pankaj347> DISTRO               = "pankaj-riscv-linux"
Jan 29 12:55:53 <pankaj347> DISTRO_VERSION       = "pankaj-r2.6.0"
Jan 29 12:56:04 <pankaj347>   LD      vmlinux.o
Jan 29 12:56:05 <pankaj347>   MODPOST vmlinux.symvers
Jan 29 12:56:05 <pankaj347>   MODINFO modules.builtin.modinfo
Jan 29 12:56:06 <pankaj347>   GEN     modules.builtin
Jan 29 12:56:06 <pankaj347>   LD      .tmp_vmlinux.kallsyms1
Jan 29 12:56:07 <pankaj347>   KSYMS   .tmp_vmlinux.kallsyms1.S
Jan 29 12:56:07 <pankaj347>   AS      .tmp_vmlinux.kallsyms1.S
Jan 29 12:56:08 <pankaj347>   LD      .tmp_vmlinux.kallsyms2
Jan 29 12:56:08 <pankaj347>   KSYMS   .tmp_vmlinux.kallsyms2.S
Jan 29 12:56:09 <pankaj347>   AS      .tmp_vmlinux.kallsyms2.S
Jan 29 12:56:09 <pankaj347>   LD      vmlinux
Jan 29 12:56:10 <pankaj347>   SYSMAP  System.map
Jan 29 12:56:10 <pankaj347>   OBJCOPY arch/riscv/boot/Image
Jan 29 12:56:11 <pankaj347>   Kernel: arch/riscv/boot/Image is ready
Jan 29 12:56:11 <pankaj347>   SYNC    include/config/auto.conf.cmd
Jan 29 12:56:12 <pankaj347>   GEN     Makefile
Jan 29 12:56:12 <pankaj347> make[2]: *** No rule to make target 'arch/riscv/boot/dts/sifive/hifive-unleashed-a00-microsemi.dtb'.  Stop.
Jan 29 12:56:13 <pankaj347> make[1]: *** [sifive/hifive-unleashed-a00-microsemi.dtb] Error 2
Jan 29 12:56:14 <pankaj347> make: *** [__sub-make] Error 2
Jan 29 12:56:15 <pankaj347> WARNING: exit code 1 from a shell command.
Jan 29 12:56:26 <pankaj347> |   AS      arch/riscv/kernel/vdso/vdso-syms.o
Jan 29 12:56:27 <pankaj347> |   AR      arch/riscv/kernel/vdso/built-in.a
Jan 29 12:56:27 <pankaj347> |   AR      arch/riscv/kernel/built-in.a
Jan 29 12:56:28 <pankaj347> |   AR      arch/riscv/built-in.a
Jan 29 12:56:28 <pankaj347> |   GEN     .version
Jan 29 12:56:29 <pankaj347> |   CHK     include/generated/compile.h
Jan 29 12:56:29 <pankaj347> |   LD      vmlinux.o
Jan 29 12:56:30 <pankaj347> |   MODPOST vmlinux.symvers
Jan 29 12:56:30 <pankaj347> |   MODINFO modules.builtin.modinfo
Jan 29 12:56:31 <pankaj347> |   GEN     modules.builtin
Jan 29 12:56:31 <pankaj347> |   LD      .tmp_vmlinux.kallsyms1
Jan 29 12:56:32 <pankaj347> |   KSYMS   .tmp_vmlinux.kallsyms1.S
Jan 29 12:56:32 <pankaj347> |   AS      .tmp_vmlinux.kallsyms1.S
Jan 29 12:56:33 <pankaj347> |   LD      .tmp_vmlinux.kallsyms2
Jan 29 12:56:33 <pankaj347> |   KSYMS   .tmp_vmlinux.kallsyms2.S
Jan 29 12:56:34 <pankaj347> |   AS      .tmp_vmlinux.kallsyms2.S
Jan 29 12:56:34 <pankaj347> |   LD      vmlinux
Jan 29 12:56:35 <pankaj347> |   SYSMAP  System.map
Jan 29 12:56:46 <pankaj347> |   CALL    /home/khan/Pankaj/openembedded/Build_dir/tmp-glibc/work-shared/pankajsemi/kernel-source/scripts/atomic/check-atomics.sh
Jan 29 12:56:47 <pankaj347> | sha1sum not available, skipping atomic header checks.
Jan 29 12:56:47 <pankaj347> |   CALL    /home/khan/Pankaj/openembedded/Build_dir/tmp-glibc/work-shared/pankajsemi/kernel-source/scripts/checksyscalls.sh
Jan 29 12:56:48 <pankaj347> |   CHK     include/generated/compile.h
Jan 29 12:56:48 <pankaj347> |   SO2S    arch/riscv/kernel/vdso/vdso-syms.S
Jan 29 12:56:49 <pankaj347> |   AS      arch/riscv/kernel/vdso/vdso-syms.o
Jan 29 12:56:49 <pankaj347> |   AR      arch/riscv/kernel/vdso/built-in.a
Jan 29 12:56:50 <pankaj347> |   AR      arch/riscv/kernel/built-in.a
Jan 29 12:56:50 <pankaj347> |   AR      arch/riscv/built-in.a
Jan 29 12:56:51 <pankaj347> |   GEN     .version
Jan 29 12:56:51 <pankaj347> |   CHK     include/generated/compile.h
Jan 29 12:56:52 <pankaj347> |   LD      vmlinux.o
Jan 29 12:56:52 <pankaj347> |   MODPOST vmlinux.symvers
Jan 29 12:56:53 <pankaj347> |   MODINFO modules.builtin.modinfo
Jan 29 12:56:53 <pankaj347> |   GEN     modules.builtin
Jan 29 12:56:54 <pankaj347> |   LD      .tmp_vmlinux.kallsyms1
Jan 29 12:56:54 <pankaj347> |   KSYMS   .tmp_vmlinux.kallsyms1.S
Jan 29 12:56:55 <pankaj347> |   AS      .tmp_vmlinux.kallsyms1.S
Jan 29 12:57:10 <pankaj347> can someone help me why this could be ?
Jan 29 12:57:49 <RP> pankaj347: please don't paste logs here, use a pastebin and provide a link
Jan 29 12:58:15 <malinus> holy macaroni
Jan 29 13:15:01 <LetoThe2nd> I'm gonna drop this in here too: https://twitter.com/TheYoctoJester/status/1355134996403650561
Jan 29 13:17:43 <qschulz> pankaj347: The error log is pretty self-explanatory? There is no make target to build the device tree you asked it to build. This has a high chance of having nothing to do with Yocto but your kernel.
Jan 29 13:34:31 <jacksparrow90123> LetoThe2nd both!
Jan 29 13:34:33 <jacksparrow90123> :)
Jan 29 13:34:42 <jacksparrow90123> (first two)
Jan 29 13:35:00 <jacksparrow90123> third  = replace with lemonade for the kids
Jan 29 13:36:02 <LetoThe2nd> jacksparrow90123: my sessions are explicitly labeled as adult entertainment!
Jan 29 13:36:17 <jacksparrow90123> XD
Jan 29 13:56:26 <JPEW> halstead: Here's the page I made: http://wattissoftware.com/yocto-r13y/
Jan 29 13:57:26 <JPEW> Note that you can't view it directly from my domain because the Cross-Origin policy on git.yoctoproject.org won't allow loading the JSON... I don't know if that will be a problem if it's hosted on yoctoproject.org
Jan 29 13:57:38 <jacksparrow90123> LetoThe2nd ps: I prefer to watch you live coding at 10x speed X-P
Jan 29 13:58:24 <halstead> Thanks JPEW I'm on vacation today but I'll get on this Monday.
Jan 29 13:58:27 <LetoThe2nd> jacksparrow90123: yeah of course, doing things live and waiting is always way slower than a presentation would be
Jan 29 13:58:53 <jacksparrow90123> true
Jan 29 13:59:49 <JPEW> halstead: OK, no problem. Thanks!
Jan 29 14:07:15 <pankaj347> @RP ok
Jan 29 15:17:53 <Sponge5> is there a way to view/explore .wic image filesystem without having to flash it onto target?
Jan 29 15:19:46 <qschulz> Sponge5: maybe a loop mount?
Jan 29 15:20:35 <Sponge5> qschulz: even if the image is for different architecture than host?
Jan 29 15:20:52 <Sponge5> s/than/from
Jan 29 15:21:15 <zeddii> unless you are running the binaries, won't be an issue
Jan 29 15:22:31 <Sponge5> now that I think about it, that makes sense, thanks a lot :)
Jan 29 15:51:44 <courchea> Hi all, what is the proper way to customize the install script (meta/recipes-core/initrdscripts/files/init-install.sh) when building my image ?
Jan 29 15:55:08 <Sponge5> apply a patch from inside your own layer, that's how I'd do it
Jan 29 15:57:22 <courchea> Sponge5: Thanks I'll investigate that
Jan 29 16:07:47 <vdl> hi all -- so meta-ti-staging is a bit dumb, for kernel config fragments, it requires a fragment to be specified *both* in SRC_URI and as *full path* in KERNEL_CONFIG_FRAGMENTS ...
Jan 29 17:21:09 <denix> vdl: if you don't understand something, it doesn't mean it's dumb. for kernel config fragments linux-ti-staging is more flexible than a simple use case you described
Jan 29 17:23:11 <denix> vdl: it can accept fragments from different locations, hence KERNEL_CONFIG_FRAGMENTS requires full path. it doesn't require fragments to be listed in SRC_URI, if they are not part of metadata. e.g. bunch of specific fragments are already in the kernel tree
Jan 29 17:28:00 <denix> vdl: for example, KERNEL_CONFIG_FRAGMENTS="${S}/ti_config_fragments/systemd.cfg" is all you need to enable all required systemd settings
Jan 29 17:37:19 <qschulz> denix: we could probably extend find_scss in kernel-yocto to support this usecase?
Jan 29 17:38:56 <qschulz> sccs*
Jan 29 18:18:37 <vdl> denix: in my case I had to specify both SRC_URI and KERNEL_CONFIG_FRAGMENTS. I think that's because S is set to ${WORKDIR}/git or something. So I stand by my point: having to specify the _absolute_ path of a fragment that is added in SRC_URI is dumb :)
Jan 29 18:21:26 <vdl> it should be either KERNEL_CONFIG_FRAGMENTS only with full path; or SRC_URI + KERNEL_CONFIG_FRAGMENTS with relative path (using file:// scheme)
Jan 29 18:37:07 <denix> vdl: it is an open source project and community - if you don't like something, you are welcome to make changes and send patches. and try doing it w/o offending anyone - https://www.yoctoproject.org/community/code-of-conduct/
Jan 29 18:38:29 <vdl> denix: I know a little bit about open-source, thank you. I am sorry that I offended you, I didn't mean to do that.
Jan 29 18:44:51 <denix> qschulz: doesn't find_sccs solely rely on SRC_URI? this use case is completely opposite...
Jan 29 21:52:13 <derRichard> is there really no datastore variable which contains the hostname?
Jan 29 21:53:00 <RP> derRichard: That would be a really bad idea for reproducibility!
Jan 29 21:54:26 <derRichard> RP: depends. in my case i'd like to create a build info file where i can see the builder hostname. e.g. was it the release build server or some developer dude's workstation?
Jan 29 21:55:11 <kergoth> add a recipe that grabs it and shoves it into a file in the target rootfs and add it to your image?
Jan 29 21:56:02 <derRichard> kergoth: i fear i'll end up with something like this, yes. so far i'm using image-buildinfo.bbclass and set IMAGE_BUILDINFO_VARS
Jan 29 21:58:04 <RP> derRichard: you can obviously do that, I'm just saying why we try and avoid it in general
Jan 29 21:59:01 <RP> kergoth: did you see that function named python_xxx bug? I've not dared look into it
Jan 29 21:59:05 <derRichard> RP: i fully understand. reproducibility is nice. but sometimes a little build context is super useful to deal with odd situations. think of developer teams without a perfect workflow
Jan 29 22:03:19 <RP> derRichard: I understand, I've had times when I wish I knew which autobuilder worker generated which piece of sstate...
Jan 29 22:06:29 <derRichard> RP: :-)
Jan 29 22:07:12 <RP> derRichard: I'd suspect its trivial to add a variable which obtains the hostname ;-)
Jan 29 22:07:34 <RP> what that will do to your builds and sstate hashes, less sure ;-)
Jan 29 22:07:51 <derRichard> sure sure, but before i hack something into a bbclass i ask here
Jan 29 22:11:44 <dl9pf> derRichard: not saying this is a good example, but https://git.automotivelinux.org/AGL/meta-agl-demo/tree/recipes-core/distro-build-manifest/distro-build-manifest.bb
Jan 29 22:13:10 <dl9pf> derRichard: plus https://git.automotivelinux.org/AGL/meta-agl/tree/scripts/distro-manifest-generator.sh
Jan 29 22:38:17 <derRichard> dl9pf: thx
**** ENDING LOGGING AT Sat Jan 30 02:59:57 2021