*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:e115:61ea:ebe1:6d33> has joined #yocto | 00:00 | |
*** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 00:15 | |
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:e115:61ea:ebe1:6d33> has quit IRC | 00:45 | |
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 01:13 | |
*** lexano <lexano!~lexano@CPEb03956d8c2f4-CM98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 01:17 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:30 | |
*** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 01:40 | |
*** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 01:50 | |
*** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 01:51 | |
*** vineela <vineela!~vtummala@134.134.137.77> has quit IRC | 02:03 | |
*** hpsy1 <hpsy1!~hpsy@92.118.12.72> has joined #yocto | 02:19 | |
*** hpsy <hpsy!~hpsy@92.118.12.72> has quit IRC | 02:21 | |
*** maze-BUG1 <maze-BUG1!~Thunderbi@180.166.53.21> has joined #yocto | 02:32 | |
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has quit IRC | 02:34 | |
*** maze-BUG1 is now known as maze-BUG | 02:34 | |
robbawebba | khem: Thanks for your help! I'll give that a shot. | 03:04 |
---|---|---|
*** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has quit IRC | 03:06 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:23 | |
*** gtristan <gtristan!~tristanva@175.211.69.194> has quit IRC | 03:29 | |
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 03:40 | |
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 03:40 | |
*** gtristan <gtristan!~tristanva@110.11.238.91> has joined #yocto | 03:41 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 04:39 | |
*** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has joined #yocto | 05:04 | |
*** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has quit IRC | 05:06 | |
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 05:15 | |
*** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has quit IRC | 05:19 | |
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has joined #yocto | 05:19 | |
*** otavio <otavio!~otavio@181.220.78.182> has joined #yocto | 05:22 | |
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 05:22 | |
*** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 05:31 | |
maze-BUG | Any suggestion about yocto with gcc 9.3 ; | 05:33 |
maze-BUG | when I build something found that gcc didn't fetch sysroot/usr/include | 05:33 |
maze-BUG | And I really found the define of sysroot in run.do_compile: | 05:45 |
maze-BUG | export 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 IRC | 05:55 | |
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/session> has joined #yocto | 05:57 | |
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/x-lfospbqadmtmbnaq> has quit IRC | 05:59 | |
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/session> has joined #yocto | 05:59 | |
*** peterp <peterp!8717f5a7@135-23-245-167.cpe.pppoe.ca> has quit IRC | 06:00 | |
*** itseris <itseris!~itseris@23.16.138.134> has quit IRC | 06:02 | |
*** itseris <itseris!~itseris@23.16.138.134> has joined #yocto | 06:03 | |
*** frsc <frsc!~frsc@i59F4BE35.versanet.de> has joined #yocto | 06:04 | |
*** LetoThe2nd <LetoThe2nd!uid453638@unaffiliated/letothe2nd> has joined #yocto | 06:05 | |
*** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 06:05 | |
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 06:11 | |
*** otavio <otavio!~otavio@181.220.78.182> has joined #yocto | 06:11 | |
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 06:11 | |
*** King_In1 <King_In1!~King_InuY@47.19.105.250> has joined #yocto | 06:15 | |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC | 06:18 | |
khem | maze-BUG: what suggestion do you need | 06:20 |
maze-BUG | khem: en, Any way could add --sysroot to gcc build | 06:20 |
maze-BUG | I 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 IRC | 06:28 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 06:28 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zxycrabosvmsnwup> has quit IRC | 06:33 | |
*** zandrey_ <zandrey_!~zandrey@193.8.40.126> has joined #yocto | 06:35 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 06:36 | |
*** frsc <frsc!~frsc@i59F4BE35.versanet.de> has quit IRC | 06:37 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 06:38 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 06:38 | |
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 06:38 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 06:40 | |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/session> has joined #yocto | 06:42 | |
khem | you do not need that if you use CC variable its already added to it | 06:46 |
maze-BUG | khem: Yes, What you said is right. | 06:50 |
maze-BUG | run.do_compile: | 06:50 |
maze-BUG | export 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-BUG | but log.do_compile: | 06:50 |
maze-BUG | fatal error: sys/mman.h: No such fi le or directory | 06:50 |
maze-BUG | 10 6 | #include <sys/mman.h> | 06:50 |
khem | are you using SDK ? | 06:51 |
khem | or are you building using yocto build system itself | 06:51 |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 06:51 | |
maze-BUG | khem: This building on yocto build system with gcc9.3 | 06:52 |
maze-BUG | And with cmake | 06:52 |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:52 | |
maze-BUG | yocto build system --->cmake --->gcc | 06:52 |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 06:54 | |
*** King_In1 <King_In1!~King_InuY@47.19.105.250> has quit IRC | 06:56 | |
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has joined #yocto | 06:56 | |
khem | maze-BUG: ok can you show your recipe? are you doing 'inherit cmake' in recipe ? | 06:58 |
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has quit IRC | 07:02 | |
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has joined #yocto | 07:03 | |
maze-BUG | khem: vpaste can't use on my computer | 07:04 |
maze-BUG | "are you doing 'inherit cmake' in recipe ?" YES | 07:04 |
maze-BUG | Just copy some command | 07:05 |
maze-BUG | SRC_DIR = "${SRC_DIR_ROOT}/display/display-tests/" | 07:05 |
maze-BUG | S = "${WORKDIR}/display/display-tests/" | 07:05 |
maze-BUG | SRC_URI = "file://display/display-tests/" | 07:05 |
maze-BUG | OECMAKE_SOURCEPATH = "${S}" | 07:05 |
maze-BUG | OECMAKE_BUILDPATH = "${WORKDIR}/build" | 07:05 |
maze-BUG | EXTRA_OECONF += " --with-sanitized-headers=${STAGING_KERNEL_BUILDDIR}/usr/include" | 07:05 |
maze-BUG | CPPFLAGS += "-DTARGET_HEADLESS" | 07:05 |
maze-BUG | CPPFLAGS += "-I${STAGING_INCDIR}/libdrm" | 07:05 |
maze-BUG | EXTRA_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-BUG | just this | 07:07 |
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 07:08 | |
erbo | maze-BUG: in log.do_compile or run.do_compile, can you see the actual gcc command that it run? | 07:08 |
khem | get rid of -DSYSROOT_LIBDIR and -DSYSROOT_INCLUDEDIR from EXTRA_OECMAKE | 07:10 |
maze-BUG | khem: OK. Let me try | 07:11 |
maze-BUG | erbo: YES | 07:11 |
maze-BUG | erbo: In log.do_compile , didn't have --sysroot | 07:12 |
maze-BUG | erbo: In run.do_compile, cflag or cppflag have --sysroot | 07:12 |
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 07:13 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 07:14 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:14 | |
maze-BUG | khem: remove -DSYSROOT_LIBDIR -DSYSROOT_INCLUDEDIR, still error with no such file. | 07:17 |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 07:21 | |
*** gtristan <gtristan!~tristanva@110.11.238.91> has quit IRC | 07:21 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 07:26 | |
*** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 07:28 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 07:31 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 07:34 | |
fbre | Hi! 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 |
fbre | I 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 needed | 07:38 |
*** ndec|away <ndec|away!sid219321@linaro/ndec> has quit IRC | 07:40 | |
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/x-jawqqxeyiojljezi> has quit IRC | 07:40 | |
*** nohit <nohit!sid334887@gateway/web/irccloud.com/x-nnvpkugowkxncvqu> has quit IRC | 07:41 | |
*** ndec|away <ndec|away!sid219321@linaro/ndec> has joined #yocto | 07:41 | |
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has joined #yocto | 07:42 | |
*** fancer <fancer!fancer@gateway/web/irccloud.com/x-vzruspgvihdpqtpx> has quit IRC | 07:44 | |
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 07:46 | |
*** Hanky <Hanky!b92ed46e@185.46.212.110> has joined #yocto | 07:46 | |
khem | maze-BUG: I wonder if your CMakeLists.txt is doing something funky with setting CC/CXX vars | 07:47 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:47 | |
*** fancer <fancer!fancer@gateway/web/irccloud.com/session> has joined #yocto | 07:49 | |
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has quit IRC | 07:50 | |
*** chris_ber <chris_ber!~quassel@213.138.44.181> has joined #yocto | 07:52 | |
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has joined #yocto | 07:54 | |
*** gtristan <gtristan!~tristanva@110.11.238.91> has joined #yocto | 07:55 | |
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/session> has joined #yocto | 07:56 | |
*** lucaceresoli <lucaceresoli!~lucaceres@185.56.157.72> has joined #yocto | 07:57 | |
*** zand__ <zand__!~zandrey@193.8.40.110> has joined #yocto | 08:03 | |
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto | 08:04 | |
*** zandrey_ <zandrey_!~zandrey@193.8.40.126> has quit IRC | 08:07 | |
fbre | poky/scripts/lib/wic contains several plugins. Do you know how I can find out which one is used for me? | 08:08 |
Hanky | Hey 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 #yocto | 08:15 | |
LetoThe2nd | Hanky: probably just missing a DEPENDS on mbedtls | 08:15 |
Hanky | Good point, checking that out. Thanks! | 08:16 |
*** zand__ <zand__!~zandrey@193.8.40.110> has quit IRC | 08:17 | |
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has quit IRC | 08:19 | |
*** hpsy1 <hpsy1!~hpsy@92.118.12.72> has quit IRC | 08:21 | |
*** hpsy <hpsy!~hpsy@92.118.12.72> has joined #yocto | 08:21 | |
khem | fbre: what all kernel images do you see in deploydir | 08:23 |
LetoThe2nd | khem: i am very confused that you are in my timezone! | 08:24 |
khem | LetoThe2nd: heh its too hot here these days | 08:25 |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 08:25 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:26 | |
LetoThe2nd | khem: so you're doing the nightlife thing? | 08:26 |
Hanky | LetoThe2nd DEPENDS = "mbedtls" in the .bb worked. Thank you! (y) | 08:27 |
LetoThe2nd | Hanky: \m/ | 08:27 |
fbre | khem: you can see the content of my deploy dir here: https://www.dropbox.com/s/yj1rpqj4pmg5w8z/20200820_102534.jpg?dl=0 | 08:27 |
*** florian_kc is now known as florian | 08:28 | |
Hanky | I 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 IRC | 08:30 | |
*** Tartarus <Tartarus!sid72705@gateway/web/irccloud.com/x-hiuadvxndhmkjhkr> has joined #yocto | 08:30 | |
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/session> has quit IRC | 08:30 | |
*** tardyp <tardyp!sid45259@gateway/web/irccloud.com/x-piwsosqdhejmipqa> has joined #yocto | 08:30 | |
*** LetoThe2nd <LetoThe2nd!uid453638@unaffiliated/letothe2nd> has quit IRC | 08:30 | |
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-gbjfwokxwqzoiuux> has joined #yocto | 08:30 | |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/session> has quit IRC | 08:30 | |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 08:30 | |
*** fancer <fancer!fancer@gateway/web/irccloud.com/session> has quit IRC | 08:30 | |
*** fancer <fancer!fancer@gateway/web/irccloud.com/x-wfwgdbuvjhzkqlry> has joined #yocto | 08:30 | |
*** nohit <nohit!sid334887@gateway/web/irccloud.com/session> has quit IRC | 08:30 | |
*** nohit <nohit!sid334887@gateway/web/irccloud.com/x-imlspjnvxpdnkpvc> has joined #yocto | 08:30 | |
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/session> has quit IRC | 08:30 | |
*** rhadye <rhadye!sid217449@gateway/web/irccloud.com/x-pfefwatbwrbrzqag> has joined #yocto | 08:30 | |
khem | fbre: Image-initramfs* is the kernel+initramfs image | 08:30 |
fbre | khem: According to the docs, I dd this one to SD card: core-image-minimal-imx8mmevk-[timestamp].rootfs.wic | 08:31 |
Hanky | khem That's correct, I did the same thing with the imx8mnevk :) But don't forget the uboot. | 08:32 |
fbre | khem: How can I find out if Image-initramfs is within that .wic file? | 08:33 |
fbre | khem: And what do you mean with "don't forget the uboot"? | 08:33 |
khem | fbre: wic uses IMAGE_BOOT_FILES to populate files in boot partition | 08:33 |
LetoThe2nd | Hanky: i don't think devtool inspects the dependencies, its jsut up to you. | 08:33 |
Hanky | Ah, ok | 08:34 |
LetoThe2nd | Hanky: there's just oo many ways one could define a form of dependency in autotools, cmake, meson, etc. | 08:35 |
fbre | khem: Do I have to change/adapt that variable IMAGE_BOOT_FILES? | 08:35 |
khem | fbre: so perhaps add IMAGE_BOOT_FILES_append = " ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin" via local.conf or machine config file | 08:35 |
khem | LetoThe2nd: devtool can inspect for deps but its best-effort approach | 08:36 |
LetoThe2nd | khem: ah. which translates to "you always have to check it" | 08:36 |
khem | it reallty depends how components build system is written, it can grok some of them but not convoluted ones | 08:37 |
khem | right | 08:37 |
LetoThe2nd | :) | 08:37 |
fbre | khem: 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 |
khem | fbre: that file is kernel image | 08:38 |
khem | so you have to ensure that the bootloader params are set to load it | 08:38 |
fbre | khem: 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 |
LetoThe2nd | it wasn't me, but it sounds legit. | 08:40 |
fbre | khem: 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 #yocto | 08:41 | |
*** codusnocturnus <codusnocturnus!~codusnoct@ip68-98-225-84.ph.ph.cox.net> has quit IRC | 08:42 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 08:43 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 08:43 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 08:44 | |
*** camus1 is now known as kaspter | 08:44 | |
chris_ber | with `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 #yocto | 08:44 | |
*** gourve_l <gourve_l!~laurent@40.72.95.92.rev.sfr.net> has joined #yocto | 08:45 | |
chris_ber | i also added in my local.conf: `CORE_IMAGE_EXTRA_INSTALL += " kernel-modules"` | 08:48 |
chris_ber | when i added `IMAGE_INSTALL_append += "kernel-module-cp210x" i got the message: No match for argument: kernel-module-cp210x | 08:51 |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:57 | |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 08:59 | |
khem | chris_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 rebuild | 09:01 |
chris_ber | i just saved the changes exit the menuconfig | 09:02 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-kqitmrpzlonwtdqg> has joined #yocto | 09:04 | |
khem | these changes perhaps got saved into kernel workdir not into yocto metadata or kernel source tree, yocto will wipe our workdir on rebuilds | 09:05 |
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has quit IRC | 09:06 | |
* khem ->sleep() | 09:07 | |
erbo | anyone knows how to make npm use python2 instead of python3 when building node_modules (using yocto)? | 09:09 |
fbre | khem: 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 |
fbre | khem: 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 |
fbre | khem: When I set root=/dev/ram0 rw it says kernel panic because of "VFS: Cannot open root device "ram0" or unknown-block..... | 09:18 |
fbre | khem: 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 |
fbre | khem: So I suppose it still reads the old size without initramfs from flash | 09:22 |
fbre | khem: is there a size setting to do somewhere? | 09:23 |
ak77 | hmm. | 09:24 |
ak77 | building a shared library by hand has exported functions, using recipe's do_compile ${CC} SAMEFLAGS ... does not have exported functions | 09:25 |
*** gaston53 <gaston53!669c3026@102.156.48.38> has joined #yocto | 09:26 | |
gaston53 | I 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 |
gaston53 | you can see here : https://layers.openembedded.org/layerindex/recipe/82252/ | 09:30 |
ak77 | I 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 IRC | 09:33 | |
fbre | khem->wake() ;-) | 09:34 |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 09:35 | |
ak77 | ok. 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 #yocto | 09:45 | |
*** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto | 09:45 | |
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 09:46 | |
gaston53 | IMAGE_INSTALL_append = " mariadb" | 09:47 |
gaston53 | PREFERRED_VERSION_mariadb = "10.4.12" | 09:47 |
gaston53 | poky SUMO | 09:47 |
gaston53 | I have added these variables in local.conf file | 09:47 |
gaston53 | but this build mariadb 5.5 version :/ | 09:47 |
gaston53 | not 10.4.12 | 09:47 |
*** dexterlb <dexterlb!~dexterlb@2a01:9e40:2:2::2> has joined #yocto | 09:47 | |
gaston53 | how can I build another version ? | 09:47 |
fbre | Is such construction like an if-statement?: ${@bb.utils.contains('BLA', '${BLUB1}', '${BLUB2}', '', d)} | 09:48 |
Hanky | gaston53 Which Yocto Project version are you using? Seems to be outdated: https://layers.openembedded.org/layerindex/recipe/5974/ | 09:50 |
gaston53 | Hanky sumo (Yocto Project 2.5) | 09:50 |
LetoThe2nd | gaston53: 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 #yocto | 09:58 | |
gaston53 | and it's not my fault that existing variables in the yocto manual docs like `preferred_version` don't work | 09:58 |
gaston53 | if it's not useful, I don't think that yocto will put such a variable in its docs | 09:59 |
fbre | fbre: ah, this function returns third argument if the second argument is subset of the first argument else returns fourth argument | 09:59 |
LetoThe2nd | gaston53: 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_VERSION | 10:00 |
*** xtron <xtron!~xtron@110.93.212.98> has joined #yocto | 10:01 | |
LetoThe2nd | gaston53: 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_VERSION | 10:01 |
mcfrisk | hi, 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 |
fbre | Question 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 IRC | 10:49 | |
*** elGamal <elGamal!~elg@37.120.221.4> has joined #yocto | 10:49 | |
*** gsalazar84 <gsalazar84!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has joined #yocto | 10:49 | |
*** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has joined #yocto | 10:50 | |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:52 | |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 10:52 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 10:53 | |
*** camus1 is now known as kaspter | 10:53 | |
fbre | If 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 #yocto | 11:07 | |
fbre | Or do I have to replace the ${KERNEL_IMAGETYPE} with my new image ${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin ? | 11:07 |
fbre | If I don't get that initramfs to work, I'm gonna move to nuthouse tomorrow X) ;( :') | 11:09 |
*** gsalazar84 is now known as gsalazar | 11:10 | |
zandrey | fbre: 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 partition | 11:13 |
zandrey | fbre: important is to tell the u-boot that you would like to load that kernel, and *not* Image | 11:14 |
*** gtristan <gtristan!~tristanva@110.11.238.91> has quit IRC | 11:16 | |
zandrey | marex: 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 |
fbre | zandrey: 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 rw | 11:17 |
fbre | zandrey: A kernel boots but it grumbles about missing a bootable thing in /dev/ram0 | 11:18 |
*** gaston53 <gaston53!669c3026@102.156.48.38> has left #yocto | 11:18 | |
zandrey | fbre: 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 |
zandrey | fbre: pastebin your boot log, would be easier to figure out what's wrong | 11:19 |
fbre | zandrey: aaaaaaah Okaaaaaaay..... | 11:19 |
zandrey | and "env print", just like marex suggested to me yesterday | 11:20 |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 11:23 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 11:24 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 11:25 | |
marex | zandrey: yeah, that fdt_high detail is particularly nasty | 11:26 |
marex | zandrey: glad to hear it helped | 11:26 |
fbre | zandrey: Do you mean I must set this one in u-boot?: setenv rootfs /dev/ram0 | 11:27 |
marex | fbre: really, pastebin the whole log from power on till failure AND pastebin output of 'env print' in U-Boot | 11:30 |
marex | otherwise its all guessing and it is difficult to help | 11:30 |
*** hipr_c <hipr_c!~Thunderbi@89.187.182.106> has joined #yocto | 11:33 | |
*** hipr_c <hipr_c!~Thunderbi@89.187.182.106> has joined #yocto | 11:33 | |
*** hipr_c <hipr_c!~Thunderbi@89.187.182.106> has joined #yocto | 11:33 | |
*** berton <berton!~berton@181.220.78.182> has joined #yocto | 11:35 | |
fbre | zandrey: here we go with the whole log: https://www.dropbox.com/s/u15bu3l0oinjnb8/log.txt?dl=0 Thanx in advance for helping me | 11:36 |
marex | fbre: your machine seems to boot though, so whats the problem ? | 11:38 |
marex | fbre: also, initrd_high and fdt_high is broken | 11:38 |
marex | if set to -1 that is | 11:38 |
fbre | marex: 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 it | 11:40 |
fbre | ...boots the roofs from /dev/mmcblk1p2 | 11:41 |
fbre | marex: I bundled this one: INITRAMFS_IMAGE = 'core-image-tiny-initramfs' | 11:42 |
marex | fbre: you are not booting using fitImage, are you ? | 11:42 |
marex | uh | 11:42 |
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 11:42 | |
marex | I havent used bundled initrd for a long time | 11:42 |
marex | isn't there some noinitrd or somesuch kernel bootarg which controls what gets booted first ? | 11:42 |
marex | well, of course, check whetehr the kernel you are booting really has the initrd in it | 11:43 |
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 11:43 | |
marex | also | 11:44 |
marex | [ 0.000000] Kernel command line: console=ttymxc1,115200 root=/dev/mmcblk1p2 rootwait rw | 11:44 |
marex | your kernel command line was never changed | 11:44 |
fbre | marex: 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_FILES | 11:44 |
fbre | marex: yes, that is why I setenv mmcroot /dev/ram0 rootwait rw because mmcroot changes that root cmdline parameter | 11:46 |
zandrey | fbre: 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 #yocto | 11:47 | |
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 11:47 | |
zandrey | => setenv mmcargs 'setenv bootargs ${jh_clk} console=${console} root=/dev/ram0' | 11:47 |
zandrey | and then boot | 11:47 |
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 11:49 | |
zandrey | marex: 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 case | 11:49 |
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:49 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 11:50 | |
*** camus1 is now known as kaspter | 11:50 | |
zandrey | marex: fbre does not use fit, his boot_fit is set to "no", so he's not (yet) :) affected by the fdh_high | 11:50 |
fbre | zandrey|marex: This is what happens with root=/dev/ram0 : https://www.dropbox.com/s/pcez63qkhd3szgc/log2.txt?dl=0 | 11:52 |
*** jgb <jgb!c227da0a@http-v.fe.bosch.de> has joined #yocto | 11:52 | |
fbre | zandrey marex: It seems the kernel cannot find an initramfs | 11:52 |
marex | fbre: zcat /proc/config.gz | grep INITR | 11:56 |
marex | fbre: is it enabled ? and the matching compression method ? | 11:56 |
marex | reboot the system and run that on it ^ | 11:56 |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-bhseyojlgvdeelvo> has joined #yocto | 11:57 | |
fbre | zandrey 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 IRC | 11:59 | |
fbre | marex: that zcat call outputs this stuff: CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_ARCH_HAS_KEEPINITRD=y | 12:00 |
*** vicale <vicale!~vicale@dyn-13-cust157.netit.se> has quit IRC | 12:01 | |
*** [Sno] <[Sno]!~sno@p5b25b03a.dip0.t-ipconnect.de> has quit IRC | 12:04 | |
fbre | I wonder if it's important why CONFIG_INITRAMFS_SOURCE is not set | 12:05 |
*** sno <sno!~sno@p5b25b03a.dip0.t-ipconnect.de> has joined #yocto | 12:06 | |
*** luneff <luneff!~yury@80.72.17.178> has joined #yocto | 12:09 | |
*** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 12:14 | |
fbre | Are you still around? | 12:15 |
fbre | Is there something I should/can do next to find out things and solve this problem? | 12:15 |
marex | fbre: shouldn't CONFIG_INITRAMFS_SOURCE be set to the initramfs cpio archive if the archive is built in ? | 12:21 |
marex | and then, check supported compression, e.g. if you build cpio.gz, make sure the kernel has GZ support in it | 12:21 |
fbre | marex: 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-image | 12:24 |
fbre | marex: 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=0 | 12:25 |
fbre | marex: 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 somehow | 12:26 |
fbre | marex: all compression checkboxes are switched on in the menuconfig of the kernel: https://www.dropbox.com/s/woszsscp67q7koa/20200820_143013.jpg?dl=0 | 12:31 |
ant__ | fbre, the magic happens in kernel.bbclass, there are some comments as well about it | 12:40 |
marex | also docs for 2.4.y are obsolete, update to 3.y | 12:41 |
*** Hanky <Hanky!b92ed46e@185.46.212.110> has quit IRC | 12:42 | |
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-147.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 12:44 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:47 | |
*** paulg <paulg!~paulg@198-84-145-15.cpe.teksavvy.com> has joined #yocto | 12:56 | |
fbre | When 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 general | 12:57 |
fbre | misunderstanding in the logic? | 12:57 |
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has joined #yocto | 12:59 | |
fbre | The 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 IRC | 12:59 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 13:00 | |
fbre | The cmdline parameter root just tells what the root filesystem is _after_ that whole initial RAM filesystem thingy | 13:00 |
fbre | So far my understanding and questions :) | 13:01 |
*** tgamblin_ <tgamblin_!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 13:02 | |
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 13:02 | |
mihai- | fbre: if you used IMAGE_INITRAMFS_BUNDLE, Image-initramfs-* should be the kernel + initramfs, you need to boot that | 13:03 |
mihai- | or INITRAMFS_IMAGE_BUNDLE, whatever its name is | 13:03 |
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 13:05 | |
*** tgamblin_ is now known as tgamblin | 13:05 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:06 | |
fbre | mihai-: 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 IRC | 13:12 | |
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC | 13:12 | |
mcfrisk | hi, 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 |
fbre | aaaaaaaaaah, 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 =D | 13:20 |
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 13:21 | |
fbre | I 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 |
mcfrisk | oops, 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 IRC | 13:24 | |
*** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has quit IRC | 13: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 console | 13:28 |
fbre | zandrey_: 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 |
fbre | Maybe I should also try core-image-minimal-initramfs instead of core-image-tiny-initramfs as bundle and see if that works better | 13:32 |
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 13:36 | |
mihai- | fbre: there should be a way to have setenv image done on packaging somehow, maybe through an uboot env file | 13:38 |
fbre | mihai-: 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 Image | 13:41 |
mihai- | fbre: ok :) | 13:41 |
*** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has quit IRC | 13:43 | |
*** xtron <xtron!~xtron@103.113.103.91> has joined #yocto | 13:43 | |
*** zandrey_ <zandrey_!~zandrey@193.8.40.110> has quit IRC | 13:45 | |
*** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 13:45 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:54 | |
*** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 13:56 | |
*** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has joined #yocto | 14:00 | |
*** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto | 14:05 | |
*** kaspter <kaspter!~Instantbi@112.65.52.50> has joined #yocto | 14:06 | |
*** xtron <xtron!~xtron@103.113.103.91> has quit IRC | 14:08 | |
*** rcw <rcw!~rcw@45.72.241.84> has joined #yocto | 14:32 | |
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 14:33 | |
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has quit IRC | 14:34 | |
*** pharaon2502 <pharaon2502!~manjaro-u@cpe-188-129-99-153.dynamic.amis.hr> has joined #yocto | 14:38 | |
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has joined #yocto | 14:39 | |
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has quit IRC | 14:40 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 14:51 | |
*** jgb <jgb!c227da0a@http-v.fe.bosch.de> has quit IRC | 14:52 | |
*** luneff <luneff!~yury@80.72.17.178> has quit IRC | 14:52 | |
*** TundraMan is now known as marka | 14:56 | |
*** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-147.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 15:02 | |
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 15:04 | |
*** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 15:09 | |
*** kaspter <kaspter!~Instantbi@112.65.52.50> has quit IRC | 15:17 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 15:23 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 15:27 | |
*** sh_ <sh_!~sh@ken.tnt.cx> has joined #yocto | 15:27 | |
*** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-nxuwieoqwobtnhze> has quit IRC | 15:29 | |
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 15:35 | |
JPEW | fray: I left a small comment on your github change: https://github.com/mhatle/poky/commit/86fbd639261319de4c951708d9805abba6036510#r41629137 | 15:36 |
fray | ok, I'll look at it in a bit.. reworking it based on RPs comments about delVar right now | 15:37 |
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 15:45 | |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 15:47 | |
fray | JPEW 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 |
fray | I assume this could happen if you were restoring from sstate-cache via a unihash for some reason | 15:48 |
RP | fray: I'm torn on that one to be honest, I'm now not sure it is right :/ | 15:49 |
RP | it could mean a different PR value was returned in a later build | 15:49 |
RP | your changes probably make that semi irrelevant anyway | 15:49 |
fray | this 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 |
fray | so 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 |
fray | should be reproducible with cleansstate right? | 15:50 |
fray | so my test case of modifying do_patch_append in glibc works now. core-image-minimal build only 10 tasks ran | 15:51 |
kergoth | thinking about this hurts my head :) i'm glad i'm not the one neck deep in it | 15:51 |
kergoth | so thanks to you all for taking it on :) | 15:51 |
RP | fray: 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 unavailable | 15:53 |
fray | ok.. I'll pull that line of change back out.. we can monitor it and add it back if needed later | 15:53 |
fray | Hmm.. ya, the one place it could affect.. no sstate-cache, but we have the unihash database.. | 15:54 |
fray | since the PR used will be the NEW PR, even though the unihash will store the record.. | 15:54 |
RP | fray: its probably fine either way. Thinking about the above, BB_UNIHASH may avoid unwanted PR bumps that aren't needed | 15:54 |
fray | Ya, that as well | 15:54 |
fray | and the UNIHASH is likely what is expoted by the PR server? or might that be another bug we need to find/fix.. | 15:54 |
RP | fray: the PR server just expects some id string, it doesn't care what | 15:55 |
fray | case 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 out | 15:55 |
RP | ID changes, new PR | 15:55 |
fray | but 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 |
fray | I'm still going to pull it out into a separate commit thoguh | 15:57 |
fray | I don't want it to be confused with the rest of this change | 15:57 |
*** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 15:57 | |
*** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 15:57 | |
RP | kergoth: 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 |
RP | kergoth: hashequiv makes my head hurt too | 15:58 |
fray | it's simple in principal.. it's the corner cases.. far far too many corner cases | 15: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 #yocto | 16:01 | |
*** kaspter <kaspter!~Instantbi@112.65.53.200> has joined #yocto | 16:01 | |
*** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto | 16:05 | |
JPEW | fray: Ya, unfortunately missing sstate objects that the hashequiv server things should exist happens all the time. I was just explaining it to someone yesterday | 16:05 |
JPEW | s/things/thinks | 16:05 |
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 16:06 | |
kergoth | heh, simple in principle but a ton of corner cases, that sums up half the project, no? ;0 | 16:07 |
fray | JPEW yes.. I'm working on a reproducer for the corner case now, to prove the BB_UNIHASH is needed | 16:08 |
fray | Just 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 now | 16:09 |
fray | https://github.com/mhatle/poky/commits/mgh/hash-pr-equiv | 16:10 |
fray | top two commits are the important ones | 16:10 |
fray | JPEW 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 code | 16:11 |
*** lucaceresoli <lucaceresoli!~lucaceres@185.56.157.72> has quit IRC | 16:14 | |
*** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC | 16:24 | |
*** chris_ber <chris_ber!~quassel@213.138.44.181> has quit IRC | 16:24 | |
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto | 16:33 | |
*** awe001 <awe001!~awe00@unaffiliated/awe00> has joined #yocto | 16:35 | |
*** fl0v0 <fl0v0!~fvo@i5E86AD51.versanet.de> has quit IRC | 16:38 | |
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 16:41 | |
*** awe001 <awe001!~awe00@unaffiliated/awe00> has quit IRC | 16:43 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 16:48 | |
*** zandrey <zandrey!~zandrey@cable-static2-2-7.rsnweb.ch> has joined #yocto | 16:50 | |
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC | 16:51 | |
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 16:55 | |
*** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 16:56 | |
RP | kergoth: we don't have corner cases do we? :) | 17:12 |
RP | perhaps features | 17:12 |
*** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has quit IRC | 17:15 | |
*** kaspter <kaspter!~Instantbi@112.65.53.200> has quit IRC | 17:24 | |
*** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto | 17:30 | |
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 17:32 | |
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 17:36 | |
*** King_InuYasha is now known as Conan_Kudo | 17:38 | |
*** Conan_Kudo is now known as King_InuYasha | 17:38 | |
*** King_InuYasha is now known as Conan_Kudo | 17:43 | |
*** Conan_Kudo is now known as King_InuYasha | 17:44 | |
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 17:44 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 17:46 | |
*** NiksDev <NiksDev!~NiksDev@192.91.75.12> has quit IRC | 17:46 | |
*** NiksDev <NiksDev!~NiksDev@192.91.101.30> has joined #yocto | 17:46 | |
roussinm | fray: 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 IRC | 17:52 | |
khem | RP: I see that you are still reverting the revert of reverting -fno-common defaults on master-next :) | 17:53 |
khem | RP: I think all fixed need to default to -fno-common are in now | 17:54 |
fray | roussinm only if unihash is involved, otherwise no | 17:54 |
fray | JPEW / 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 |
JPEW | fray: It should be the same | 17:56 |
JPEW | fray: Or rather it will be the same unless the hash server knows otherwise | 17:57 |
fray | original 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 0 | 17:58 |
fray | I'm going to have to repeat the experiement and this time capture the hash changes from the log as I go | 17:58 |
fray | From the PRSERV db: | 17:59 |
fray | linux-libc-headers-5.4-r0|cortexa57|2e9490caff2bc96a4b6e95da78710c8205fe30c7107496ae93747e813ef4f255|0 | 17:59 |
fray | glibc-2.32-r0|cortexa57|41429b6dbf811d96d78d755d21e21684319402b0636e4fa5fc16a81d9afab8fe|1 | 17:59 |
fray | glibc-2.32-r0|cortexa57|6d2c9e211c52ab3cb04240e9d683e09c9fed578ecc83ef6d2e5384723c89847d|2 | 17:59 |
fray | this 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 #yocto | 17:59 | |
*** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 18:02 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 18:04 | |
*** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC | 18:06 | |
*** vineela <vineela!vtummala@nat/intel/x-rlfbbtkcktmijclm> has joined #yocto | 18:08 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-kqitmrpzlonwtdqg> has quit IRC | 18:09 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 18:13 | |
*** gtristan <gtristan!~tristanva@175.211.69.194> has joined #yocto | 18:14 | |
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC | 18:17 | |
fray | JPEW / 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 |
fray | looking at the prserv database, and the three runs I get: | 18:47 |
fray | run1: glibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|0 | 18:47 |
fray | run2: | 18:47 |
fray | glibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|0 | 18:47 |
fray | glibc-2.32-r0|cortexa57|fce498b97366e298899d395546538252107acea07a5ac959401dbe243c664792|1 | 18:47 |
fray | (both expected) | 18:47 |
fray | run3: | 18:47 |
fray | glibc-2.32-r0|cortexa57|fce498b97366e298899d395546538252107acea07a5ac959401dbe243c664792|1 | 18:47 |
fray | glibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|2 | 18:47 |
fray | somehow 0 was replaced by 2?! | 18:47 |
marex | rollback protection ? | 18:52 |
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has quit IRC | 18:52 | |
fray | ya, 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 |
fray | i.e. the |1 version really never 'existed' | 18:53 |
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 18:55 | |
RP | fray: it is rollback protection, the value must always increase :/ | 19:03 |
RP | JPEW: 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 |
fray | Ok, 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 |
RP | fray: does BB_TASKHASH work any better? | 19:04 |
fray | I'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-cache | 19: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 |
JPEW | RP: Well... that's weird. curl wasn't a valid shell last time I checked | 19:14 |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 19:14 | |
*** Timba <Timba!~Timba@161.97.215.98> has joined #yocto | 19:18 | |
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 19:20 | |
JPEW | fray: 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 server | 19:33 |
*** comptroller <comptroller!~comptroll@47-213-220-127.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 19:33 | |
fray | yes.. if an equivalency has been detected, we really need to tell the PR server.. so likely that is the next step | 19:34 |
fray | the 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 IRC | 19:45 | |
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto | 19:48 | |
*** f0h <f0h!~f0h@farfarello.0xf0.eu> has joined #yocto | 19:54 | |
fray | RP 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 .1 | 19:54 |
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has quit IRC | 19:56 | |
RP | fray: cool, we were right not to change it originally :) | 19:58 |
*** rcoote <rcoote!~rcoote@5.146.199.158> has joined #yocto | 19:58 | |
JPEW | fray: It would be better if the server was more aware of the sstate contents; I don't know the best way to do that though | 19:59 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:59 | |
fray | I 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 |
fray | so order of operation is.. | 19:59 |
fray | we 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 database | 20:00 |
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has joined #yocto | 20:01 | |
RP | fray: I'm not sure it matters | 20:02 |
fray | it does, because now the build with the sstate-cache and without result in two different sets of packages.. | 20:03 |
RP | fray: that is the case for prserv anyway? | 20:03 |
fray | last/tmp/deploy/rpm/cortexa57/libc6-2.32-r0.0.cortexa57.rpm | 20:03 |
fray | tmp/deploy/rpm/cortexa57/libc6-2.32-r0.1.cortexa57.rpm | 20:03 |
fray | but I have the prsev and unihash data.. "but for some reason" (rm -rf) I cant get to the sstate-cache.. | 20:04 |
fray | so between the last and current build, I had a change.. even though NOTHIGN in the layers or the prserv/unihash datbases changed | 20:04 |
fray | (the for some reason in a more real-world situation is the network goes down) | 20:05 |
RP | fray: 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 |
RP | fray: this should hopefully simplify the code so the PR serv really only does bump when needed? | 20:09 |
fray | we'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 value | 20:09 |
RP | fray: no, its not fine, but you can lookup the hash of do_package there and get the resolved unihash | 20:10 |
RP | since by that point its made the comparison | 20:10 |
fray | How do you do that (look up the hash of do_packge in do_pacakge_write? | 20:10 |
RP | fray: BB_TASKDEPDATA | 20:10 |
fray | that contains the revised unihash? | 20:10 |
RP | It has to be a dependency but this obviously is | 20:10 |
RP | I think it should | 20:11 |
fray | is it a dependency if do_package was in the sstate-cache, but do_package_write_* isn?t | 20:11 |
RP | Its deterministic so sstate cache isn't relevant | 20:12 |
fray | ok | 20:12 |
RP | fray: sorry to be slow in coming up with this but I think its probably simpler and will avoid a ton of complexity | 20:13 |
JPEW | fray: The taskhash and the unihash should be in BB_TASKDEPDATA | 20:13 |
RP | right, it should have both iirc | 20:13 |
fray | is there an example of the data in BB_TASKDEPDATA? Since what I need to do is find the UNIHASH result for do_package | 20:14 |
RP | fray: 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 #yocto | 20:17 | |
fray | that's what I needed.. ok | 20:17 |
RP | fray: example users are staging.bbclass, you want those last two fields in the array | 20:17 |
*** ant__ <ant__!~ant__@host-82-60-190-157.retail.telecomitalia.it> has joined #yocto | 20:19 | |
fray | it looks like all of the package classes already call 'read_subpackage_metadata'. So I should be able to add something there... | 20:19 |
fray | thinking of moving package_get_auto_pr from package.bbclass to packagedata.bbclass | 20:20 |
*** rizzitello <rizzitello!~quassel@24.105.220.210> has joined #yocto | 20:21 | |
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/kiwiirc.com/ip.94.60.229.17> has quit IRC | 20:33 | |
*** Timba <Timba!~Timba@161.97.215.98> has quit IRC | 20:48 | |
dl9pf | fray: RP: then why not integrate the prserv function with hashequiv-server if these are so related ... | 20:54 |
dl9pf | keep the old prserv for legacy, but if hashequiv is used, store the PR right there together with the equiv hashes ? | 20:55 |
dl9pf | and 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 IRC | 20:57 | |
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has left #yocto | 20:57 | |
*** matthewzmd <matthewzmd!~user@216-58-109-18.cpe.distributel.net> has joined #yocto | 20:57 | |
*** xtron1 <xtron1!~xtron@110.93.212.98> has joined #yocto | 21:00 | |
*** xtron <xtron!~xtron@103.113.103.91> has quit IRC | 21:00 | |
*** xtron1 <xtron1!~xtron@110.93.212.98> has quit IRC | 21:02 | |
*** xtron1 <xtron1!~xtron@103.113.103.91> has joined #yocto | 21:03 | |
*** maze-BUG <maze-BUG!~Thunderbi@180.166.53.21> has joined #yocto | 21:05 | |
*** Konsgnx <Konsgnx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 21:05 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:08 | |
*** fbre <fbre!52cfeefc@muedsl-82-207-238-252.citykom.de> has joined #yocto | 21:09 | |
*** robbawebba <robbawebba!~rob@8-3-93-140.starry-inc.net> has joined #yocto | 21:09 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 21:10 | |
JPEW | dl9pf: 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 database | 21:11 |
JPEW | But again, I'm not familiar with the PR server | 21:11 |
dl9pf | can you show me a sample hashequiv db entry/line ? | 21:12 |
JPEW | dl9pf: Here's the database schema http://git.openembedded.org/bitbake/tree/lib/hashserv/__init__.py#n29 | 21:13 |
dl9pf | prserv is e.g. glibc-2.32-r0|cortexa57|f77a1419d3693c90374e79d161b838709592b16bf1c58fc064ec665c491ee0e6|2 | 21:14 |
dl9pf | that is ${PF} | ${PACKAGE_ARCH} | taskhash?? | 'pr' | 21:14 |
dl9pf | you already have the optional field of 'pr' in the schema I see | 21:14 |
JPEW | dl9pf: True; thats optional and only sent by the client if debugging is enabled | 21:15 |
dl9pf | so the only thing not in there is $PACKAGE_ARCH | 21:15 |
JPEW | It's more for tracking a unhelp hash back to the source :) | 21:15 |
dl9pf | so all is more or less in there 'as well' | 21:16 |
JPEW | Hmm... I wonder what the query would be | 21:16 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 21:16 | |
*** sajjad__ <sajjad__!~xtron@110.93.212.98> has joined #yocto | 21:17 | |
dl9pf | e.g. http://git.openembedded.org/bitbake/tree/lib/prserv/db.py#n71 ? | 21:19 |
*** sajjad__ <sajjad__!~xtron@110.93.212.98> has quit IRC | 21:19 | |
dl9pf | data=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 IRC | 21:20 | |
fbre | zandrey 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 #yocto | 21:21 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 21:22 | |
JPEW | dl9pf: Right, that would get you the reported PR for a given entry, but its not clear to me how you get a monotonically incrementing value | 21:23 |
*** berton <berton!~berton@181.220.78.182> has quit IRC | 21:23 | |
dl9pf | http://git.openembedded.org/bitbake/tree/lib/prserv/db.py#n79 | 21:24 |
dl9pf | fray: the prserv has a 'hist' and 'nohist' code branch | 21:25 |
dl9pf | that explains why it got replaced ... | 21:25 |
dl9pf | nohist 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 |
dl9pf | hist 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 |
dl9pf | nohist is set by default. | 21:27 |
*** fbre <fbre!52cfeefc@muedsl-82-207-238-252.citykom.de> has quit IRC | 21:28 | |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC | 21:31 | |
*** sajjad__ <sajjad__!~xtron@103.113.103.91> has quit IRC | 21:31 | |
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 21:38 | |
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 21:42 | |
RP | khem: was that curl change related to the mingw issue? | 21:43 |
RP | dl9pf: I think hashequiv is problematic enough without putting the PR policy there as well | 21:44 |
RP | dl9pf: 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 tables | 21:45 |
fray | how is nohist vs hist selected in pr server? | 21:46 |
dl9pf | fray: i saw no cmdline switch | 21:46 |
dl9pf | PRData's __init__(self, filename, nohist=True): and self.nohist=nohist | 21:47 |
RP | dl9pf: there may be a variable | 21:47 |
dl9pf | self.db = prserv.db.PRData(self.dbfile) | 21:48 |
dl9pf | so nohist is default and hist never used | 21:48 |
RP | dl9pf: I know I have used it but I probably just hacked the code | 21:49 |
fray | I suspect it was defaulted to hist in the past, and must have changed to avoid rollbacks | 21:49 |
dl9pf | probably ... | 21:50 |
RP | We wrote the two policies, we obviously just exposed one | 21:51 |
dl9pf | http://git.openembedded.org/bitbake/commit/lib/prserv?id=379567ee879dcdc09a51f7f1212bde1076147a6f | 21:54 |
dl9pf | switchover was to nohist when introduced | 21:55 |
RP | dl9pf: That was a while ago, PRC Intel team. | 21:55 |
*** yocti <yocti!~supybot@mail.yoctoproject.org> has joined #yocto | 22:01 | |
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 22:19 | |
khem | RP: actually, I was looking for a CVE fix which was fixed 3 days ago. | 22:21 |
RP | khem: ok, so the mystery probably remains on that failure :/ | 22:23 |
RP | khem: thought I'd ask! :) | 22:23 |
*** andrew <andrew!6a3368f6@106.51.104.246> has joined #yocto | 22:28 | |
*** andrew <andrew!6a3368f6@106.51.104.246> has quit IRC | 22:30 | |
*** agust <agust!~agust@p508b6ab0.dip0.t-ipconnect.de> has quit IRC | 22:32 | |
*** rizzitello <rizzitello!~quassel@24.105.220.210> has quit IRC | 22:40 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:48 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:52 | |
dl9pf | cccccckulcfnlknguunnifveujdutjnfvgeuejhhevhn | 22:57 |
*** stacktrust <stacktrust!~stacktrus@cpe-24-90-105-219.nyc.res.rr.com> has quit IRC | 23:02 | |
RP | log.do_package_write_rpm:Provides: /bin/sh nativesdk-curl = 7.72.0-r0 | 23:07 |
RP | why does rpmdeps think a windows binary provides /bin/sh ? :/ | 23:07 |
*** risca <risca!~quassel@212.85.71.156> has quit IRC | 23:08 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:08 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 23:08 | |
*** risca <risca!~quassel@212.85.71.156> has joined #yocto | 23:08 | |
khem | zeddii: I am seeing a warning with 5.8 kernel on qemumips https://pastebin.com/J4nytSCG | 23:12 |
khem | RP: yeah currently trying to reduce CVE backlog on dunfell a little | 23:12 |
RP | print_deps(srcrprovides + (" /bin/sh" if srcname.startswith("nativesdk-") else ""), "Provides", spec_preamble_top, d) | 23:16 |
RP | fray: any recollection why package_rpm does that? | 23:16 |
RP | http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package_rpm.bbclass?h=master-next&id=1cf9dd6492e2e234a3b41419d84e94ca1520954c | 23:17 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:21 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:29 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:31 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:33 | |
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 23:35 | |
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC | 23:53 | |
robbawebba | Hi, 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 as | 23: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 IRC | 23:55 | |
*** smurray <smurray!sid98062@gateway/web/irccloud.com/x-cskoehwvzqbtjyel> has quit IRC | 23:56 | |
*** ernstp <ernstp!sid168075@gateway/web/irccloud.com/x-wdvugbvbprcllhzt> has quit IRC | 23:56 | |
*** paulbarker <paulbarker!sid269702@gateway/web/irccloud.com/x-rfqnabdlglmamems> has quit IRC | 23:58 | |
*** ernstp <ernstp!sid168075@gateway/web/irccloud.com/x-gehttxdsavgjhgiq> has joined #yocto | 23:58 | |
*** smurray <smurray!sid98062@gateway/web/irccloud.com/x-feqciffpxtxvegyl> has joined #yocto | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!