Thursday, 2020-08-20

*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:e115:61ea:ebe1:6d33> has joined #yocto00:00
*** vineela <vineela!~vtummala@134.134.139.76> has quit IRC00:15
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:e115:61ea:ebe1:6d33> has quit IRC00:45
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC01:13
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto01:17
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto01:30
*** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto01:40
*** vineela <vineela!~vtummala@134.134.137.77> has quit IRC01:50
*** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto01:51
*** vineela <vineela!~vtummala@134.134.137.77> has quit IRC02:03
*** hpsy1 <hpsy1!~hpsy@92.118.12.72> has joined #yocto02:19
*** hpsy <hpsy!~hpsy@92.118.12.72> has quit IRC02:21
*** maze-BUG1 <maze-BUG1!~Thunderbi@180.166.53.21> has joined #yocto02:32
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has quit IRC02:34
*** maze-BUG1 is now known as maze-BUG02:34
robbawebbakhem: Thanks for your help! I'll give that a shot.03:04
*** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has quit IRC03:06
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC03:23
*** gtristan <gtristan!~tristanva@175.211.69.194> has quit IRC03:29
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC03:40
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto03:40
*** gtristan <gtristan!~tristanva@110.11.238.91> has joined #yocto03:41
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto04:39
*** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has joined #yocto05:04
*** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has quit IRC05:06
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC05:15
*** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC05:19
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto05:19
*** otavio <otavio!~otavio@181.220.78.182> has joined #yocto05:22
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto05:22
*** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto05:31
maze-BUGAny suggestion about yocto with gcc 9.3 ;05:33
maze-BUGwhen I build something found that gcc didn't fetch sysroot/usr/include05:33
maze-BUGAnd I really found the define of sysroot in run.do_compile:05:45
maze-BUGexport CC="aarch64-oe-linux-gcc -march=armv8-a -mcpu=cortex-a57 -mtune=cortex-a57 --sysroot=/local/mnt/workspace/poky/build/tmp-glibc/work/oe-linux/display-tests/git-r1/recipe-sysroot"05:46
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-mapuhwomxjjduybn> has quit IRC05:55
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/session> has joined #yocto05:57
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/x-lfospbqadmtmbnaq> has quit IRC05:59
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/session> has joined #yocto05:59
*** peterp <peterp!8717f5a7@135-23-245-167.cpe.pppoe.ca> has quit IRC06:00
*** itseris <itseris!~itseris@23.16.138.134> has quit IRC06:02
*** itseris <itseris!~itseris@23.16.138.134> has joined #yocto06:03
*** frsc <frsc!~frsc@i59F4BE35.versanet.de> has joined #yocto06:04
*** LetoThe2nd <LetoThe2nd!uid453638@unaffiliated/letothe2nd> has joined #yocto06:05
*** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto06:05
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC06:11
*** otavio <otavio!~otavio@181.220.78.182> has joined #yocto06:11
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto06:11
*** King_In1 <King_In1!~King_InuY@47.19.105.250> has joined #yocto06:15
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC06:18
khemmaze-BUG: what suggestion do you need06:20
maze-BUGkhem: en, Any way could add  --sysroot to gcc build06:20
maze-BUGI have try to add CFLAGS  in my bbfile, but doesn't work when compiling.06:26
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC06:28
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto06:28
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zxycrabosvmsnwup> has quit IRC06:33
*** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto06:35
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto06:36
*** frsc <frsc!~frsc@i59F4BE35.versanet.de> has quit IRC06:37
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC06:38
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto06:38
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC06:38
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC06:40
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/session> has joined #yocto06:42
khemyou do not need that if you use CC variable its already added to it06:46
maze-BUGkhem: Yes, What you said is right.06:50
maze-BUGrun.do_compile:06:50
maze-BUGexport CC="aarch64-oe-linux-gcc -march=armv8-a -mcpu=cortex-a57 -mtune=cortex-a57 --sysroot=/local/mnt/workspace/poky/build/tmp-glibc/work/oe-linux/display-tests/git-r1/recipe-sysroot"06:50
maze-BUGbut log.do_compile:06:50
maze-BUG fatal error: sys/mman.h: No such fi    le or directory06:50
maze-BUG 10     6 | #include <sys/mman.h>06:50
khemare you using SDK ?06:51
khemor are you building using yocto build system  itself06:51
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto06:51
maze-BUGkhem: This building on yocto build system with gcc9.306:52
maze-BUGAnd with cmake06:52
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:52
maze-BUGyocto build system --->cmake --->gcc06:52
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto06:54
*** King_In1 <King_In1!~King_InuY@47.19.105.250> has quit IRC06:56
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has joined #yocto06:56
khemmaze-BUG: ok can you show your recipe? are you doing 'inherit cmake' in recipe ?06:58
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has quit IRC07:02
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has joined #yocto07:03
maze-BUGkhem: vpaste can't use on my computer07:04
maze-BUG"are you doing 'inherit cmake' in recipe ?" YES07:04
maze-BUGJust copy some command07:05
maze-BUGSRC_DIR = "${SRC_DIR_ROOT}/display/display-tests/"07:05
maze-BUGS = "${WORKDIR}/display/display-tests/"07:05
maze-BUGSRC_URI = "file://display/display-tests/"07:05
maze-BUGOECMAKE_SOURCEPATH = "${S}"07:05
maze-BUGOECMAKE_BUILDPATH = "${WORKDIR}/build"07:05
maze-BUGEXTRA_OECONF += " --with-sanitized-headers=${STAGING_KERNEL_BUILDDIR}/usr/include"07:05
maze-BUGCPPFLAGS += "-DTARGET_HEADLESS"07:05
maze-BUGCPPFLAGS += "-I${STAGING_INCDIR}/libdrm"07:05
maze-BUGEXTRA_OECMAKE = "\07:07
maze-BUG        -DSYSROOT_LIBDIR:STRING=${STAGING_LIBDIR} \07:07
maze-BUG        -DSYSROOT_INCLUDEDIR:STRING=${STAGING_INCDIR} \07:07
maze-BUG        -DCOMPONENTS_INCDIR:STRING=${COMPONENTS_DIR} \07:07
maze-BUG        -DKERNEL_BUILDDIR:STRING=${STAGING_KERNEL_BUILDDIR} \07:07
maze-BUG        -DWAYLANDBUFFERBACKEND_PATH=${STAGING_INCDIR} \07:07
maze-BUG        -DALIGNMENT=64 \07:07
maze-BUG"07:07
maze-BUGjust this07:07
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto07:08
erbomaze-BUG: in log.do_compile or run.do_compile, can you see the actual gcc command that it run?07:08
khemget rid of -DSYSROOT_LIBDIR and -DSYSROOT_INCLUDEDIR from EXTRA_OECMAKE07:10
maze-BUGkhem: OK. Let me try07:11
maze-BUGerbo: YES07:11
maze-BUGerbo: In log.do_compile , didn't have --sysroot07:12
maze-BUGerbo: In run.do_compile, cflag or cppflag have --sysroot07:12
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto07:13
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC07:14
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto07:14
maze-BUGkhem: remove -DSYSROOT_LIBDIR  -DSYSROOT_INCLUDEDIR, still error with no such file.07:17
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC07:21
*** gtristan <gtristan!~tristanva@110.11.238.91> has quit IRC07:21
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto07:26
*** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto07:28
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC07:31
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto07:34
fbreHi! And every day the groundhog says hello with the question is anybody here who knows about bundling an initramfs to the kernel via INITRAMFS_IMAGE_BUNDLE? Even after my upgrade to "zeus" it does not work. My description is here: https://community.nxp.com/message/1355297 X)07:35
fbreI think both images are bitbaked, but the initramfs image is not added to the kernel for any unknown reasons. Maybe it's just a little magic configuration entry which is still needed07:38
*** ndec|away <ndec|away!sid219321@linaro/ndec> has quit IRC07:40
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/x-jawqqxeyiojljezi> has quit IRC07:40
*** nohit <nohit!sid334887@gateway/web/irccloud.com/x-nnvpkugowkxncvqu> has quit IRC07:41
*** ndec|away <ndec|away!sid219321@linaro/ndec> has joined #yocto07:41
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has joined #yocto07:42
*** fancer <fancer!fancer@gateway/web/irccloud.com/x-vzruspgvihdpqtpx> has quit IRC07:44
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC07:46
*** Hanky <Hanky!b92ed46e@185.46.212.110> has joined #yocto07:46
khemmaze-BUG: I wonder if your CMakeLists.txt is doing something funky with setting CC/CXX vars07:47
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:47
*** fancer <fancer!fancer@gateway/web/irccloud.com/session> has joined #yocto07:49
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has quit IRC07:50
*** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto07:52
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has joined #yocto07:54
*** gtristan <gtristan!~tristanva@110.11.238.91> has joined #yocto07:55
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/session> has joined #yocto07:56
*** lucaceresoli <lucaceresoli!~lucaceres@185.56.157.72> has joined #yocto07:57
*** zand__ <zand__!~zandrey@193.8.40.110> has joined #yocto08:03
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto08:04
*** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC08:07
fbrepoky/scripts/lib/wic contains several plugins. Do you know how I can find out which one is used for me?08:08
HankyHey there, have a small simple mbedtls example file. CMakeLists created, built successfully via make. Added this project via devtool add XY, but when trying to bitbake the image the do_compile can't find the mbedtls/config.h located in /usr/include/mbedtls. Yocto beginner, sorry. ;)08:14
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has joined #yocto08:15
LetoThe2ndHanky: probably just missing a DEPENDS on mbedtls08:15
HankyGood point, checking that out. Thanks!08:16
*** zand__ <zand__!~zandrey@193.8.40.110> has quit IRC08:17
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has quit IRC08:19
*** hpsy1 <hpsy1!~hpsy@92.118.12.72> has quit IRC08:21
*** hpsy <hpsy!~hpsy@92.118.12.72> has joined #yocto08:21
khemfbre: what all kernel images do you see in deploydir08:23
LetoThe2ndkhem: i am very confused that you are in my timezone!08:24
khemLetoThe2nd: heh its too hot here these days08:25
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC08:25
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:26
LetoThe2ndkhem: so you're doing the nightlife thing?08:26
HankyLetoThe2nd DEPENDS = "mbedtls" in the .bb worked. Thank you! (y)08:27
LetoThe2ndHanky: \m/08:27
fbrekhem: you can see the content of my deploy dir here: https://www.dropbox.com/s/yj1rpqj4pmg5w8z/20200820_102534.jpg?dl=008:27
*** florian_kc is now known as florian08:28
HankyI wonder why devtool add doesn't look at CMakeLists properly. I added target_link_libraries(myclient mbedtls mbedx509 mbedcrypto) to it but when doing a devtool add XY it seems not to take care of these dependencies.08:29
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/session> has quit IRC08:30
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-hiuadvxndhmkjhkr> has joined #yocto08:30
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/session> has quit IRC08:30
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/x-piwsosqdhejmipqa> has joined #yocto08:30
*** LetoThe2nd <LetoThe2nd!uid453638@unaffiliated/letothe2nd> has quit IRC08:30
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-gbjfwokxwqzoiuux> has joined #yocto08:30
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/session> has quit IRC08:30
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto08:30
*** fancer <fancer!fancer@gateway/web/irccloud.com/session> has quit IRC08:30
*** fancer <fancer!fancer@gateway/web/irccloud.com/x-wfwgdbuvjhzkqlry> has joined #yocto08:30
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has quit IRC08:30
*** nohit <nohit!sid334887@gateway/web/irccloud.com/x-imlspjnvxpdnkpvc> has joined #yocto08:30
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/session> has quit IRC08:30
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/x-pfefwatbwrbrzqag> has joined #yocto08:30
khemfbre: Image-initramfs* is the kernel+initramfs image08:30
fbrekhem: According to the docs, I dd this one to SD card: core-image-minimal-imx8mmevk-[timestamp].rootfs.wic08:31
Hankykhem That's correct, I did the same thing with the imx8mnevk :)  But don't forget the uboot.08:32
fbrekhem: How can I find out if Image-initramfs is within that .wic file?08:33
fbrekhem: And what do you mean with "don't forget the uboot"?08:33
khemfbre: wic uses IMAGE_BOOT_FILES to populate files in boot partition08:33
LetoThe2ndHanky: i don't think devtool inspects the dependencies, its jsut up to you.08:33
HankyAh, ok08:34
LetoThe2ndHanky: there's just oo many ways one could define a form of dependency in autotools, cmake, meson, etc.08:35
fbrekhem: Do I have to change/adapt that variable IMAGE_BOOT_FILES?08:35
khemfbre: so perhaps add IMAGE_BOOT_FILES_append = " ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin" via local.conf or machine config file08:35
khemLetoThe2nd: devtool can inspect for deps but its best-effort approach08:36
LetoThe2ndkhem: ah. which translates to "you always have to check it"08:36
khemit reallty depends how components build system is written, it can grok some of them but not convoluted ones08:37
khemright08:37
LetoThe2nd:)08:37
fbrekhem: oh, sounds promising! And if that file is populated in the boot partition, does the kernel load it? Do I have to set root=/dev/ram0 in u-boot?08:37
khemfbre: that file is kernel image08:38
khemso you have to ensure that the bootloader params are set to load it08:38
fbrekhem: uh, I see. I think LetoThe2nd gave me the hint to setenv root=/dev/ram0  in u-boot to tell the Linux kernel to load that bundled initramfs.08:39
LetoThe2ndit wasn't me, but it sounds legit.08:40
fbrekhem: thanx! Now I'm heading over to tweak that IMAGE_BOOT_FILES_append.... I hope it will work ... D:08:41
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto08:41
*** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has quit IRC08:42
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto08:43
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC08:43
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC08:44
*** camus1 is now known as kaspter08:44
chris_berwith `bitbake linux-imx -c menuconfig` i selected the kernel module CP210x but it seems to be that the module isn't built. I see a lot of other kernel modules. Any ideas?08:44
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto08:44
*** gourve_l <gourve_l!~laurent@40.72.95.92.rev.sfr.net> has joined #yocto08:45
chris_beri also added in my local.conf: `CORE_IMAGE_EXTRA_INSTALL += " kernel-modules"`08:48
chris_berwhen i added `IMAGE_INSTALL_append += "kernel-module-cp210x" i got the message: No match for argument: kernel-module-cp210x08:51
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:57
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto08:59
khemchris_ber: the changes resulting from -c menuconfig should be made persistent, so did you regernate the defconfig or add a config fragment to add the option ? if not then this change will be lost on nextt kernel rebuild09:01
chris_beri just saved the changes exit the menuconfig09:02
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-kqitmrpzlonwtdqg> has joined #yocto09:04
khemthese changes perhaps got saved into kernel workdir not into yocto metadata or kernel source tree, yocto will wipe our workdir on rebuilds09:05
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC09:06
* khem ->sleep()09:07
erboanyone knows how to make npm use python2 instead of python3 when building node_modules (using yocto)?09:09
fbrekhem: The good news is the .wic files increased its size by about 50MB after I set IMAGE_BOOT_FILES_append. So I guess the initramfs is really bundled now to .wic :-)09:15
fbrekhem: The bad news is it still boots from /dev/mmcblk1p2 by default. And when I set root=/dev/ram0 rootwait rw  it just says "Waiting for root device /dev/ram0..."09:17
fbrekhem: When I set root=/dev/ram0 rw   it says kernel panic because of "VFS: Cannot open root device "ram0" or unknown-block.....09:18
fbrekhem: But the console still says the same old sizes as if I haven't managed to bundle the initramfs: 28021248 bytes read in 320 ms (83.5 MiB/s)   ....Booting from mmc... 44652 bytes read in 16 ms (2.7 MiB/s)09:22
fbrekhem: So I suppose it still reads the old size without initramfs from flash09:22
fbrekhem: is there a size setting to do somewhere?09:23
ak77hmm.09:24
ak77building a shared library by hand has exported functions, using recipe's do_compile ${CC} SAMEFLAGS ... does not have exported functions09:25
*** gaston53 <gaston53!669c3026@102.156.48.38> has joined #yocto09:26
gaston53I have added mariadb to my linux yocto image, I am using sumo yocto image, so I have build mariadb 5.5 version. How can I change the version to mariadb 10 ?09:28
gaston53you can see here : https://layers.openembedded.org/layerindex/recipe/82252/09:30
ak77I have copied command line, run compiler with all the flags and functions are exported from a .so, using bitbake they aren't, what could cause this?09:31
*** hpsy <hpsy!~hpsy@92.118.12.72> has quit IRC09:33
fbrekhem->wake() ;-)09:34
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC09:35
ak77ok. solved. stupid me. exports are of course missing if you don't specify any .c file... (TIL: you can create shared .so file without any source files)09:40
*** emrius <emrius!5840fa9b@dslb-088-064-250-155.088.064.pools.vodafone-ip.de> has joined #yocto09:45
*** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto09:45
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto09:46
gaston53IMAGE_INSTALL_append = " mariadb"09:47
gaston53PREFERRED_VERSION_mariadb = "10.4.12"09:47
gaston53poky SUMO09:47
gaston53I have added these variables in local.conf file09:47
gaston53but this build mariadb 5.5 version :/09:47
gaston53not 10.4.1209:47
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto09:47
gaston53how can I build another version ?09:47
fbreIs such construction like an if-statement?:   ${@bb.utils.contains('BLA', '${BLUB1}', '${BLUB2}', '', d)}09:48
Hankygaston53 Which Yocto Project version are you using? Seems to be outdated: https://layers.openembedded.org/layerindex/recipe/5974/09:50
gaston53Hanky sumo (Yocto Project 2.5)09:50
LetoThe2ndgaston53: instead of asking a thrid (or even fourth) time: either backport the recipes (complicated, probably), or update your yocto version (probably also complicated). and please do not go bitching here for sumo support. its not our fault that you're using outdated software.09:56
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto09:58
gaston53and it's not my fault that existing variables in the yocto manual docs like `preferred_version` don't work09:58
gaston53if it's not useful, I don't think that yocto will put such a variable in its docs09:59
fbrefbre: ah, this function returns third argument if the second argument is subset of the first argument else returns fourth argument09:59
LetoThe2ndgaston53: nope. seriously, you just do not understand how the variable works. its not a magic switch to use any version: its a selection amongst *available recipes*. so if no recipe provides the version you want, the variable "does not work".  do not claim the docs are misleading, they certainly are not: https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-PREFERRED_VERSION10:00
*** xtron <xtron!~xtron@110.93.212.98> has joined #yocto10:01
LetoThe2ndgaston53: and to prove my point, the same text is already stated in the sumo version of the manual: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-PREFERRED_VERSION10:01
mcfriskhi, meta-java has sadly download issues with for example https://bitbucket.org/cacaovm/cacao-staging/get/2d6f6c14daf9.zip which has been removed. Could some of the files be mirrored in yocto download mirror?10:16
fbreQuestion regarding wic: Is there an order in which all the files appended to IMAGE_BOOT_FILES have to appear? The first one is ${KERNEL_IMAGETYPE}, the second one is ${@make_dtb_boot_files(d)}. Where is the place where my ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin has to be?10:21
*** elfGamal <elfGamal!~elg@37.120.221.4> has quit IRC10:49
*** elGamal <elGamal!~elg@37.120.221.4> has joined #yocto10:49
*** gsalazar84 <gsalazar84!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto10:49
*** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has joined #yocto10:50
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto10:52
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC10:52
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC10:53
*** camus1 is now known as kaspter10:53
fbreIf an initramfs is bundled to the kernel, how does the kernel detect this bundled file? By address, by name, ...?11:06
*** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto11:07
fbreOr do I have to replace the ${KERNEL_IMAGETYPE} with my new image ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin ?11:07
fbreIf I don't get that initramfs to work, I'm gonna move to nuthouse tomorrow X) ;( :')11:09
*** gsalazar84 is now known as gsalazar11:10
zandreyfbre: i've written you yesterday about the IMAGE_BOOT_FILES and KERNEL_IMAGETYPE. order should not matter, as IMAGE_BOOT_FILES it treated as a list when wic uses it, and populates all files onto fat partition11:13
zandreyfbre: important is to tell the u-boot that you would like to load that kernel, and *not* Image11:14
*** gtristan <gtristan!~tristanva@110.11.238.91> has quit IRC11:16
zandreymarex: thanks again for hint regarding the "fdt_high" and "bootm_size". this was indeed a source if all inflate troubles. we'd make a patch to cover imx8m derivatives, and would send it to u-boot, NXP and append it in the meta-freescale layer.11:16
fbrezandrey: oh, I think yesterday I was not already so far to understand what you mean with IMAGE_BOOT_FILES, sorry. OK, I tried this but it leads to errors:  setenv mmcroot /dev/ram0 rw11:17
fbrezandrey: A kernel boots but it grumbles about missing a bootable thing in /dev/ram011:18
*** gaston53 <gaston53!669c3026@102.156.48.38> has left #yocto11:18
zandreyfbre: you should change the bootcmd's rootfs=/dev/ram0 param, and not the mmcroot... you still want to load your combined image from eMMC, right ;)11:19
zandreyfbre: pastebin your boot log, would be easier to figure out what's wrong11:19
fbrezandrey: aaaaaaah Okaaaaaaay.....11:19
zandreyand "env print", just like marex suggested to me yesterday11:20
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC11:23
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC11:24
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto11:25
marexzandrey: yeah, that fdt_high detail is particularly nasty11:26
marexzandrey: glad to hear it helped11:26
fbrezandrey: Do you mean I must set this one in u-boot?:     setenv rootfs /dev/ram011:27
marexfbre: really, pastebin the whole log from power on till failure AND pastebin output of 'env print' in U-Boot11:30
marexotherwise its all guessing and it is difficult to help11:30
*** hipr_c <hipr_c!~Thunderbi@89.187.182.106> has joined #yocto11:33
*** hipr_c <hipr_c!~Thunderbi@89.187.182.106> has joined #yocto11:33
*** hipr_c <hipr_c!~Thunderbi@89.187.182.106> has joined #yocto11:33
*** berton <berton!~berton@181.220.78.182> has joined #yocto11:35
fbrezandrey: here we go with the whole log: https://www.dropbox.com/s/u15bu3l0oinjnb8/log.txt?dl=0  Thanx in advance for helping me11:36
marexfbre: your machine seems to boot though, so whats the problem ?11:38
marexfbre: also, initrd_high and fdt_high is broken11:38
marexif set to -1 that is11:38
fbremarex: I bundled an initramfs to the kernel with INITRAMFS_IMAGE_BUNDLE = '1'. The kernel should load that RAM filesystem. I can't see it is doing that. Instead it11:40
fbre...boots the roofs from /dev/mmcblk1p211:41
fbremarex: I bundled this one: INITRAMFS_IMAGE = 'core-image-tiny-initramfs'11:42
marexfbre: you are not booting using fitImage, are you ?11:42
marexuh11:42
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto11:42
marexI havent used bundled initrd for a long time11:42
marexisn't there some noinitrd or somesuch kernel bootarg which controls what gets booted first ?11:42
marexwell, of course, check whetehr the kernel you are booting really has the initrd in it11:43
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC11:43
marexalso11:44
marex[    0.000000] Kernel command line: console=ttymxc1,115200 root=/dev/mmcblk1p2 rootwait rw11:44
marexyour kernel command line was never changed11:44
fbremarex: That's a good question. The docs actually say it's enough to set INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE. Now I found out I have to additionally add that new .wic file to the boot partition by appending it to IMAGE_BOOT_FILES11:44
fbremarex: yes, that is why I setenv mmcroot /dev/ram0 rootwait rw          because mmcroot changes that root cmdline parameter11:46
zandreyfbre: you should change this env variable => mmcargs=setenv bootargs ${jh_clk} console=${console} root=${mmcroot}11:46
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto11:47
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto11:47
zandrey=> setenv mmcargs 'setenv bootargs ${jh_clk} console=${console} root=/dev/ram0'11:47
zandreyand then boot11:47
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto11:49
zandreymarex: indeed, those fdt_high is problematic, but good that you've suggested the change to be done! :) this is definitely worth repairing for imx8m derivatives everywhere, since a lot of people might hit the same case11:49
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto11:49
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC11:50
*** camus1 is now known as kaspter11:50
zandreymarex: fbre does not use fit, his boot_fit is set to "no", so he's not (yet) :) affected by the fdh_high11:50
fbrezandrey|marex: This is what happens with root=/dev/ram0 : https://www.dropbox.com/s/pcez63qkhd3szgc/log2.txt?dl=011:52
*** jgb <jgb!c227da0a@http-v.fe.bosch.de> has joined #yocto11:52
fbrezandrey marex: It seems the kernel cannot find an initramfs11:52
marexfbre: zcat /proc/config.gz | grep INITR11:56
marexfbre: is it enabled ? and the matching compression method ?11:56
marexreboot the system and run that on it ^11:56
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-bhseyojlgvdeelvo> has joined #yocto11:57
fbrezandrey marex: I think, my .wic file contains 2 images:  ${KERNEL_IMAGETYPE} and ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin   because both ones are in the list of IMAGE_BOOT_FILES. How does u-boot know which one to boot?11:58
*** emrius <emrius!5840fa9b@dslb-088-064-250-155.088.064.pools.vodafone-ip.de> has quit IRC11:59
fbremarex: that zcat call outputs this stuff:    CONFIG_BLK_DEV_INITRD=y      CONFIG_INITRAMFS_SOURCE=""        CONFIG_ARCH_HAS_KEEPINITRD=y12:00
*** vicale <vicale!~vicale@dyn-13-cust157.netit.se> has quit IRC12:01
*** [Sno] <[Sno]!~sno@p5b25b03a.dip0.t-ipconnect.de> has quit IRC12:04
fbreI wonder if it's important why CONFIG_INITRAMFS_SOURCE is not set12:05
*** sno <sno!~sno@p5b25b03a.dip0.t-ipconnect.de> has joined #yocto12:06
*** luneff <luneff!~yury@80.72.17.178> has joined #yocto12:09
*** xtron <xtron!~xtron@110.93.212.98> has quit IRC12:14
fbreAre you still around?12:15
fbreIs there something I should/can do next to find out things and solve this problem?12:15
marexfbre: shouldn't CONFIG_INITRAMFS_SOURCE be set to the initramfs cpio archive if the archive is built in ?12:21
marexand then, check supported compression, e.g. if you build cpio.gz, make sure the kernel has GZ support in it12:21
fbremarex: CONFIG_INITRAMFS_SOURCE is mentioned here but I don't understand whether I must set it or not: https://www.yoctoproject.org/docs/2.4.1/dev-manual/dev-manual.html#building-an-initramfs-image12:24
fbremarex: See the content of my deploy dir here. Should I set CONFIG_INITRAMFS_SOURCE to any of those filesnames?: https://www.dropbox.com/s/yj1rpqj4pmg5w8z/20200820_102534.jpg?dl=012:25
fbremarex: I don't understand the docs here what I should really do with that variable CONFIG_INITRAMFS_SOURCE. I assumed it's handled automatically by the build system somehow12:26
fbremarex: all compression checkboxes are switched on in the menuconfig of the kernel: https://www.dropbox.com/s/woszsscp67q7koa/20200820_143013.jpg?dl=012:31
ant__fbre, the magic happens in kernel.bbclass, there are some comments as well about it12:40
marexalso docs for 2.4.y are obsolete, update to 3.y12:41
*** Hanky <Hanky!b92ed46e@185.46.212.110> has quit IRC12:42
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-147.hsi6.kabel-badenwuerttemberg.de> has joined #yocto12:44
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC12:47
*** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has joined #yocto12:56
fbreWhen I'm looking at the boot partition of the SD card via file browser I can see a file Image (27MB) and also Image-initramfs-imx8mmevk.bin (65MB). I suppose Image is the kernel which boots from u-boot on command 'boot'. But which magic tell that kernel to use Image-initramfs-imx8mmevk.bin as initial RAM filesystem? Or do I have a general12:57
fbremisunderstanding in the logic?12:57
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has joined #yocto12:59
fbreThe other possibility is to let u-boot use Image-initramfs-imx8mmevk.bin (65MB) as kernel which somehow have that initial RAM filesystem included. But how do I tell u-boot to use that one?12:59
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC12:59
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto13:00
fbreThe cmdline parameter root just tells what the root filesystem is _after_ that whole initial RAM filesystem thingy13:00
fbreSo far my understanding and questions :)13:01
*** tgamblin_ <tgamblin_!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto13:02
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC13:02
mihai-fbre: if you used IMAGE_INITRAMFS_BUNDLE, Image-initramfs-* should be the kernel + initramfs, you need to boot that13:03
mihai-or INITRAMFS_IMAGE_BUNDLE, whatever its name is13:03
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC13:05
*** tgamblin_ is now known as tgamblin13:05
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC13:06
fbremihai-: How do I tell u-boot which file to load as kernel? My boot partition contains two Image files (Image and Image-initramfs-imx8mmevk.bin, and some other stuff imx8mm_m4_TCP* and .dtb ...)13:07
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:12
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC13:12
mcfriskhi, does nativesdk-clang work from meta-clang? I managed to compile and install but it seems to have issues finding linkers and binaries, as if it's not configured correctly at all.13:15
fbreaaaaaaaaaah, in u-boot I have to call this command:     setenv image  Image-initramfs-imx8mmevk.bin           and now it boots that other kernel with the bundled initramfs =D13:20
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC13:21
fbreI think I'm a step further. Now proceeds until this logging:   [    4.166205] Run /init as init process         Starting version 243.2+      Waiting for removable media...13:22
mcfriskoops, nativesdk-clang seems to be a clang for SDK arch target? How is the real target compiler called?13:22
*** sh_ <sh_!~sh@ken.tnt.cx> has quit IRC13:24
*** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has quit IRC13:27
zandrey_fbre: this is already a good sign - it means your bundled image is operable. i guess next thing to do is to analyze what's missing in the initramdisk to boot into console13:28
fbrezandrey_: yeah! I'm quite happy already. Many thanx to you all for helping me. Without that I'd already given up :-)   It was so hard to find out I have 2 files in my boot partition and must tell u-boot the new (right) one. Tomorrow I'll look into that initramdisk.13:31
fbreMaybe I should also try core-image-minimal-initramfs   instead of core-image-tiny-initramfs   as bundle and see if that works better13:32
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto13:36
mihai-fbre: there should be a way to have setenv image done on packaging somehow, maybe through an uboot env file13:38
fbremihai-: yes, that's true. I even used that already before but can't remember right now. Not a problem right now for me.13:41
mihai-fbre: or you can just rename Image-initramfs to Image13:41
mihai-fbre: ok :)13:41
*** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has quit IRC13:43
*** xtron <xtron!~xtron@103.113.103.91> has joined #yocto13:43
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has quit IRC13:45
*** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto13:45
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto13:54
*** fbre <fbre!91fdde45@145.253.222.69> has quit IRC13:56
*** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has joined #yocto14:00
*** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto14:05
*** kaspter <kaspter!~Instantbi@112.65.52.50> has joined #yocto14:06
*** xtron <xtron!~xtron@103.113.103.91> has quit IRC14:08
*** rcw <rcw!~rcw@45.72.241.84> has joined #yocto14:32
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC14:33
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has quit IRC14:34
*** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has joined #yocto14:38
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has joined #yocto14:39
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has quit IRC14:40
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC14:51
*** jgb <jgb!c227da0a@http-v.fe.bosch.de> has quit IRC14:52
*** luneff <luneff!~yury@80.72.17.178> has quit IRC14:52
*** TundraMan is now known as marka14:56
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-147.hsi6.kabel-badenwuerttemberg.de> has quit IRC15:02
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto15:04
*** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto15:09
*** kaspter <kaspter!~Instantbi@112.65.52.50> has quit IRC15:17
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC15:23
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto15:27
*** sh_ <sh_!~sh@ken.tnt.cx> has joined #yocto15:27
*** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-nxuwieoqwobtnhze> has quit IRC15:29
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC15:35
JPEWfray: I left a small comment on your github change: https://github.com/mhatle/poky/commit/86fbd639261319de4c951708d9805abba6036510#r4162913715:36
frayok, I'll look at it in a bit.. reworking it based on RPs comments about delVar right now15:37
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC15:45
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto15:47
frayJPEW the chang to the BB_TASKHASH to BB_UNIHASH was on suggestion of RP yesterday when we were talking..  Without making the BB_UNIHASH change there, any future lookups of the PR service info would be using the task hash and not unihash..15:48
frayI assume this could happen if you were restoring from sstate-cache via a unihash for some reason15:48
RPfray: I'm torn on that one to be honest, I'm now not sure it is right :/15:49
RPit could mean a different PR value was returned in a later build15:49
RPyour changes probably make that semi irrelevant anyway15:49
fraythis is where I'm a bit naive on the order of operations..  BEFORE the task starts building, it looks up the task hash and converts to unihash if it's in the database right?15:49
frayso if we're in a situation where the hash is in the database, but the sstate-cache isn't available for the do_package task.  Then we'd want it right?15:50
frayshould be reproducible with cleansstate right?15:50
frayso my test case of modifying do_patch_append in glibc works now.  core-image-minimal build only 10 tasks ran15:51
kergoththinking about this hurts my head :) i'm glad i'm not the one neck deep in it15:51
kergothso thanks to you all for taking it on :)15:51
RPfray: I think of it this way. If the task reruns, we want it to be deterministic. The first time it runs, it will be with TASKHASH. I'm struggling to think of a case where it would match unihash and run with a new unihash, I guess that could happen if sstate was unavailable15:53
frayok.. I'll pull that line of change back out.. we can monitor it and add it back if needed later15:53
frayHmm..  ya, the one place it could affect.. no sstate-cache, but we have the unihash database..15:54
fraysince the PR used will be the NEW PR, even though the unihash will store the record..15:54
RPfray: its probably fine either way. Thinking about the above, BB_UNIHASH may avoid unwanted PR bumps that aren't needed15:54
frayYa, that as well15:54
frayand the UNIHASH is likely what is expoted by the PR server?  or might that be another bug we need to find/fix..15:54
RPfray: the PR server just expects some id string, it doesn't care what15:55
fraycase I'm thinking of is user has a PR database (or exported config), and has the unihash database as well.. but their connection to their sstaet-cache data breaks.. they need to be able to build and get a matching version out15:55
RPID changes, new PR15:55
fraybut the exported PR data only has the 'latest' (matching) hashes in it, not all know hashes.. (I think, maybe I'm remembering wrong)15:56
frayI'm still going to pull it out into a separate commit thoguh15:57
frayI don't want it to be confused with the rest of this change15:57
*** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC15:57
*** vineela <vineela!~vtummala@134.134.139.76> has quit IRC15:57
RPkergoth: I found the old variable dependency work you did on an old harddisk the other day before we managed to turn it into what we merged into bitbake. Quite a trip down memory lane!15:58
RPkergoth: hashequiv makes my head hurt too15:58
frayit's simple in principal.. it's the corner cases.. far far too many corner cases15:59
fray(I have a MUCH better understanding of it now then I did a week ago)15:59
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto16:01
*** kaspter <kaspter!~Instantbi@112.65.53.200> has joined #yocto16:01
*** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto16:05
JPEWfray: Ya, unfortunately missing sstate objects that the hashequiv server things should exist happens all the time. I was just explaining it to someone yesterday16:05
JPEWs/things/thinks16:05
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:06
kergothheh, simple in principle but a ton of corner cases, that sums up half the project, no? ;016:07
frayJPEW yes.. I'm working on a reproducer for the corner case now, to prove the BB_UNIHASH is needed16:08
frayJust an FYI, I pushed up the changes to that same github location.. (force push).  The second commit is what  I think will be a reprocuer case, but I've not yet validated that.. in progress now16:09
frayhttps://github.com/mhatle/poky/commits/mgh/hash-pr-equiv16:10
fraytop two commits are the important ones16:10
frayJPEW as I was mentioning to RP.  I used the suffix '.oe_nohash'.  I figued someone MIGHT call something .nohash, but nobody is going to use .oe_nohash in a regular filename unless they REALLY are trying to trigger this code16:11
*** lucaceresoli <lucaceresoli!~lucaceres@185.56.157.72> has quit IRC16:14
*** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC16:24
*** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC16:24
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto16:33
*** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto16:35
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has quit IRC16:38
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto16:41
*** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC16:43
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC16:48
*** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto16:50
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC16:51
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto16:55
*** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto16:56
RPkergoth: we don't have corner cases do we? :)17:12
RPperhaps features17:12
*** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has quit IRC17:15
*** kaspter <kaspter!~Instantbi@112.65.53.200> has quit IRC17:24
*** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto17:30
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto17:32
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC17:36
*** King_InuYasha is now known as Conan_Kudo17:38
*** Conan_Kudo is now known as King_InuYasha17:38
*** King_InuYasha is now known as Conan_Kudo17:43
*** Conan_Kudo is now known as King_InuYasha17:44
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto17:44
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC17:46
*** NiksDev <NiksDev!~NiksDev@192.91.75.12> has quit IRC17:46
*** NiksDev <NiksDev!~NiksDev@192.91.101.30> has joined #yocto17:46
roussinmfray: is the work you've done helps in anyway when sstate-object is not available on the remote server? Or it's not related at all?17:50
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-gbjfwokxwqzoiuux> has quit IRC17:52
khemRP: I see that you are still reverting the revert of reverting -fno-common defaults on master-next :)17:53
khemRP: I think all fixed need to default to -fno-common are in now17:54
frayroussinm only if unihash is involved, otherwise no17:54
frayJPEW / RP the second patch doesn't work in the documented test case.. what is interesting is that it actually create a NEW PR..  So in the unihash not the same as the initial task hash?17:55
JPEWfray: It should be the same17:56
JPEWfray: Or rather it will be the same unless the hash server knows otherwise17:57
frayoriginal build PRAUTO .0.  first change PRAUTO .1, hash equivalency of the first build...  remove sstate-cache and tmp.. third build (no changes to layer)  I got PRAUTO of .2, where I was expecting 017:58
frayI'm going to have to repeat the experiement and this time capture the hash changes from the log as I go17:58
frayFrom the PRSERV db:17:59
fraylinux-libc-headers-5.4-r0|cortexa57|2e9490caff2bc96a4b6e95da78710c8205fe30c7107496ae93747e813ef4f255|017:59
frayglibc-2.32-r0|cortexa57|41429b6dbf811d96d78d755d21e21684319402b0636e4fa5fc16a81d9afab8fe|117:59
frayglibc-2.32-r0|cortexa57|6d2c9e211c52ab3cb04240e9d683e09c9fed578ecc83ef6d2e5384723c89847d|217:59
fraythis is odd, where did 0 go.. is the BB_UNIHASH blank on the first pass?17:59
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto17:59
*** vineela <vineela!~vtummala@134.134.139.76> has quit IRC18:02
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC18:04
*** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC18:06
*** vineela <vineela!vtummala@nat/intel/x-rlfbbtkcktmijclm> has joined #yocto18:08
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-kqitmrpzlonwtdqg> has quit IRC18:09
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto18:13
*** gtristan <gtristan!~tristanva@175.211.69.194> has joined #yocto18:14
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC18:17
frayJPEW / RP : So the BB_UNIHASH did exactly what it should have.. However, the call to the PR service somehow erased the version '0', and replaced it with a version '2'?!18:46
fraylooking at the prserv database, and the three runs I get:18:47
frayrun1: glibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|018:47
frayrun2:18:47
frayglibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|018:47
frayglibc-2.32-r0|cortexa57|fce498b97366e298899d395546538252107acea07a5ac959401dbe243c664792|118:47
fray(both expected)18:47
frayrun3:18:47
frayglibc-2.32-r0|cortexa57|fce498b97366e298899d395546538252107acea07a5ac959401dbe243c664792|118:47
frayglibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|218:47
fraysomehow 0 was replaced by 2?!18:47
marexrollback protection ?18:52
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC18:52
frayya, I'm not really sure.. that's why I'm confused by this..  If it IS rollback protection, we need a way to detect that rollback is 'acceptable'?  or maybe a way to remove a PR when we decide the task hash isn't going to be used but unihash is..18:53
frayi.e. the |1 version really never 'existed'18:53
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto18:55
RPfray: it is rollback protection, the value must always increase :/19:03
RPJPEW: this looks like fun  package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts with /bin/sh provided by nativesdk-curl-7.71.1-r0.i686_nativesdk_mingw32 :/19:03
frayOk, so how do we deal with this situation then -- No sstate-cache, but I have a hash equip and pr service, but I'm not pointing to the latest PR.. do we need a way to "remove" the latest (taskhash) PR in a unihash environment?19:04
RPfray: does BB_TASKHASH work any better?19:04
frayI'm going to go back and double check, but I believe it returns '.1', so the .0 version is effectively gone unless you have the sstate-cache19:05
fray(build for the test takes abotu 15 minutes to bootstrap, then a few minutes each for the next two test passes before I can get an answer)19:09
JPEWRP: Well... that's weird. curl wasn't a valid shell last time I checked19:14
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC19:14
*** Timba <Timba!~Timba@161.97.215.98> has joined #yocto19:18
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC19:20
JPEWfray: I don't know much about the PR server, but it does seem like conflicting requirements: bump the PR automatically, but detect equivalencies with the hash server19:33
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto19:33
frayyes.. if an equivalency has been detected, we really need to tell the PR server.. so likely that is the next step19:34
fraythe real concern for me is that w/o the sstate-cache contents the results aren't deterministic (to the prior build)19:37
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC19:45
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto19:48
*** f0h <f0h!~f0h@farfarello.0xf0.eu> has joined #yocto19:54
frayRP verified -- using BB_TASKHASH (instead of UNIHASH) for the PR service.. the PR goes from .0 to .0 (as expected), clear the sstate-cache and it goes to .119:54
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has quit IRC19:56
RPfray: cool, we were right not to change it originally :)19:58
*** rcoote <rcoote!~rcoote@5.146.199.158> has joined #yocto19:58
JPEWfray: It would be better if the server was more aware of the sstate contents; I don't know the best way to do that though19:59
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto19:59
frayI am going to look at the server and see if I can trigger a removal of the current entry if the taskhash and unihash differ..19:59
frayso order of operation is..19:59
fraywe use BB_UNIHASH and request PR..  we do the packaging work.. we calculate the UNIHASH, IF it changes to task hash (no longer the same as what was originally requested) changes, then we remove the 'new' entry from the PR database20:00
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has joined #yocto20:01
RPfray: I'm not sure it matters20:02
frayit does, because now the build with the sstate-cache and without result in two different sets of packages..20:03
RPfray: that is the case for prserv anyway?20:03
fraylast/tmp/deploy/rpm/cortexa57/libc6-2.32-r0.0.cortexa57.rpm20:03
fraytmp/deploy/rpm/cortexa57/libc6-2.32-r0.1.cortexa57.rpm20:03
fraybut I have the prsev and unihash data.. "but for some reason" (rm -rf) I cant get to the sstate-cache..20:04
frayso between the last and current build, I had a change.. even though NOTHIGN in the layers or the prserv/unihash datbases changed20:04
fray(the for some reason in a more real-world situation is the network goes down)20:05
RPfray: Instead why don't we a) not expand EXTENDPRAUTO at all in the packagewrite code b) Move the PR serv query to the users of the data in the pkg data reads in the do_package_write*20:08
RPfray: this should hopefully simplify the code so the PR serv really only does bump when needed?20:09
fraywe'd end up using the taskhash of the do_package_write instead..  (which is fine), but in the sstate-cache case, it's still going to have to build it and would get the wrong value20:09
RPfray: no, its not fine, but you can lookup the hash of do_package there and get the resolved unihash20:10
RPsince by that point its made the comparison20:10
frayHow do you do that (look up the hash of do_packge in do_pacakge_write?20:10
RPfray: BB_TASKDEPDATA20:10
fraythat contains the revised unihash?20:10
RPIt has to be a dependency but this obviously is20:10
RPI think it should20:11
frayis it a dependency if do_package was in the sstate-cache, but do_package_write_* isn?t20:11
RPIts deterministic so sstate cache isn't relevant20:12
frayok20:12
RPfray: sorry to be slow in coming up with this but I think its probably simpler and will avoid a ton of complexity20:13
JPEWfray: The taskhash and the unihash should be in BB_TASKDEPDATA20:13
RPright, it should have both iirc20:13
frayis there an example of the data in BB_TASKDEPDATA?  Since what I need to do is find the UNIHASH result for do_package20:14
RPfray: the data is build in lib/bb/runqueue.py: taskdepdata[revdep] = [pn, taskname, fn, deps, provides, taskhash, unihash]20:17
*** xtron <xtron!~xtron@103.113.103.91> has joined #yocto20:17
fraythat's what I needed.. ok20:17
RPfray: example users are staging.bbclass, you want those last two fields in the array20:17
*** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has joined #yocto20:19
frayit looks like all of the package classes already call 'read_subpackage_metadata'.  So I should be able to add something there...20:19
fraythinking of moving package_get_auto_pr from package.bbclass to packagedata.bbclass20:20
*** rizzitello <rizzitello!~quassel@24.105.220.210> has joined #yocto20:21
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC20:33
*** Timba <Timba!~Timba@161.97.215.98> has quit IRC20:48
dl9pffray: RP: then why not integrate the prserv function with hashequiv-server if these are so related ...20:54
dl9pfkeep the old prserv for legacy, but if hashequiv is used, store the PR right there together with the equiv hashes ?20:55
dl9pfand on the plus side your prserv/hashequiv won't get out of sync.20:56
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has quit IRC20:57
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has left #yocto20:57
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto20:57
*** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto21:00
*** xtron <xtron!~xtron@103.113.103.91> has quit IRC21:00
*** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC21:02
*** xtron1 <xtron1!~xtron@103.113.103.91> has joined #yocto21:03
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has joined #yocto21:05
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC21:05
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC21:08
*** fbre <fbre!52cfeefc@muedsl-82-207-238-252.citykom.de> has joined #yocto21:09
*** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has joined #yocto21:09
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto21:10
JPEWdl9pf: It seems like it would be hard to make sure the versions didn't go backward; it's not clear to me how you would link the PR information to the hash equiv database21:11
JPEWBut again, I'm not familiar with the PR server21:11
dl9pfcan you show me a sample hashequiv db entry/line ?21:12
JPEWdl9pf: Here's the database schema http://git.openembedded.org/bitbake/tree/lib/hashserv/__init__.py#n2921:13
dl9pfprserv is e.g. glibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|221:14
dl9pfthat is ${PF} | ${PACKAGE_ARCH} | taskhash?? | 'pr'21:14
dl9pfyou already have the optional field of 'pr' in the schema I see21:14
JPEWdl9pf: True; thats optional and only sent by the client if debugging is enabled21:15
dl9pfso the only thing not in there is $PACKAGE_ARCH21:15
JPEWIt's more for tracking a unhelp hash back to the source :)21:15
dl9pfso all is more or less in there 'as well'21:16
JPEWHmm... I wonder what the query would be21:16
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC21:16
*** sajjad__ <sajjad__!~xtron@110.93.212.98> has joined #yocto21:17
dl9pfe.g. http://git.openembedded.org/bitbake/tree/lib/prserv/db.py#n71 ?21:19
*** sajjad__ <sajjad__!~xtron@110.93.212.98> has quit IRC21:19
dl9pfdata=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table, (version, pkgarch, checksum))21:20
*** xtron1 <xtron1!~xtron@103.113.103.91> has quit IRC21:20
fbrezandrey marex: the bundled initramfs works now :-)  I just have to tweak the recipes-core/initrdscripts/files/init-live.sh script a bit for not waiting for a plugging in a CD or stick. I wrote it all together in an answer in the NXP community forum. Thank you guys and free beer for all here. Party on! B-)  (y)21:20
*** sajjad__ <sajjad__!~xtron@103.113.103.91> has joined #yocto21:21
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto21:22
JPEWdl9pf: Right, that would get you the reported PR for a given entry, but its not clear to me how you get a monotonically incrementing value21:23
*** berton <berton!~berton@181.220.78.182> has quit IRC21:23
dl9pfhttp://git.openembedded.org/bitbake/tree/lib/prserv/db.py#n7921:24
dl9pffray: the prserv has a 'hist' and 'nohist' code branch21:25
dl9pfthat explains why it got replaced ...21:25
dl9pfnohist is self._execute("INSERT OR REPLACE INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));" % (self.table,self.table), (version, pkgarch, checksum, version, pkgarch))21:26
dl9pfhist is self._execute("INSERT INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));" % (self.table,self.table), (version,pkgarch, checksum,version, pkgarch))21:26
dl9pfnohist is set by default.21:27
*** fbre <fbre!52cfeefc@muedsl-82-207-238-252.citykom.de> has quit IRC21:28
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC21:31
*** sajjad__ <sajjad__!~xtron@103.113.103.91> has quit IRC21:31
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:38
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto21:42
RPkhem: was that curl change related to the mingw issue?21:43
RPdl9pf: I think hashequiv is problematic enough without putting the PR policy there as well21:44
RPdl9pf: I am broadly in favour of moving prser into the hashequiv server and having one set of server code but I think I'd still prefer separate data tables21:45
frayhow is nohist vs hist selected in pr server?21:46
dl9pffray: i saw no cmdline switch21:46
dl9pfPRData's __init__(self, filename, nohist=True):  and self.nohist=nohist21:47
RPdl9pf: there may be a variable21:47
dl9pfself.db = prserv.db.PRData(self.dbfile)21:48
dl9pfso nohist is default and hist never used21:48
RPdl9pf: I know I have used it but I probably just hacked the code21:49
frayI suspect it was defaulted to hist in the past, and must have changed to avoid rollbacks21:49
dl9pfprobably ...21:50
RPWe wrote the two policies, we obviously just exposed one21:51
dl9pfhttp://git.openembedded.org/bitbake/commit/lib/prserv?id=379567ee879dcdc09a51f7f1212bde1076147a6f21:54
dl9pfswitchover was to nohist when introduced21:55
RPdl9pf: That was a while ago, PRC Intel team.21:55
*** yocti <yocti!~supybot@mail.yoctoproject.org> has joined #yocto22:01
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto22:19
khemRP: actually, I was looking for a CVE fix which was fixed 3 days ago.22:21
RPkhem: ok, so the mystery probably remains on that failure :/22:23
RPkhem: thought I'd ask! :)22:23
*** andrew <andrew!6a3368f6@106.51.104.246> has joined #yocto22:28
*** andrew <andrew!6a3368f6@106.51.104.246> has quit IRC22:30
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC22:32
*** rizzitello <rizzitello!~quassel@24.105.220.210> has quit IRC22:40
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC22:48
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto22:52
dl9pfcccccckulcfnlknguunnifveujdutjnfvgeuejhhevhn22:57
*** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC23:02
RPlog.do_package_write_rpm:Provides: /bin/sh nativesdk-curl = 7.72.0-r023:07
RPwhy does rpmdeps think a windows binary provides /bin/sh ? :/23:07
*** risca <risca!~quassel@212.85.71.156> has quit IRC23:08
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC23:08
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto23:08
*** risca <risca!~quassel@212.85.71.156> has joined #yocto23:08
khemzeddii: I am seeing a warning with 5.8 kernel on qemumips https://pastebin.com/J4nytSCG23:12
khemRP: yeah currently trying to reduce CVE backlog on dunfell a little23:12
RP    print_deps(srcrprovides + (" /bin/sh" if srcname.startswith("nativesdk-") else ""), "Provides", spec_preamble_top, d)23:16
RPfray: any recollection why package_rpm does that?23:16
RPhttp://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package_rpm.bbclass?h=master-next&id=1cf9dd6492e2e234a3b41419d84e94ca1520954c23:17
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC23:21
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto23:29
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC23:31
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto23:33
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC23:35
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC23:53
robbawebbaHi, I have a question regarding dynamically linked binaries produced by native recipes. I would like to ditribute a single native binary for use on other host systems, not necessarily the build host. The only issue I'm sitll experiencing is the exact linker being available on other hosts. It it possible to compile the native package such that it supports using other interpreters such as23:55
robbawebba/lib64/ld-linux-x86_64.so.2? Thanks in advance. I'm not all that familiar with linking so any feedback is appreciated.23:55
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has quit IRC23:55
*** smurray <smurray!sid98062@gateway/web/irccloud.com/x-cskoehwvzqbtjyel> has quit IRC23:56
*** ernstp <ernstp!sid168075@gateway/web/irccloud.com/x-wdvugbvbprcllhzt> has quit IRC23:56
*** paulbarker <paulbarker!sid269702@gateway/web/irccloud.com/x-rfqnabdlglmamems> has quit IRC23:58
*** ernstp <ernstp!sid168075@gateway/web/irccloud.com/x-gehttxdsavgjhgiq> has joined #yocto23:58
*** smurray <smurray!sid98062@gateway/web/irccloud.com/x-feqciffpxtxvegyl> has joined #yocto23:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!