Monday, 2019-11-25

hyper_daveOkay it worked now00:05
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC00:11
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto00:11
*** camus <camus!~Instantbi@222.67.152.154> has joined #yocto00:34
*** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC00:35
*** camus is now known as kaspter00:35
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto00:53
hyper_daveWhat are the environment variables for /usr/man and /opt01:10
hyper_daveI tried ${mandir} but no luck01:10
*** camus <camus!~Instantbi@124.77.81.26> has joined #yocto01:12
*** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC01:13
*** camus is now known as kaspter01:13
*** camus <camus!~Instantbi@124.77.81.26> has joined #yocto01:31
*** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC01:33
*** camus is now known as kaspter01:33
kergothcheck meta/conf/bitbake.conf02:37
kergoththats where those vars are defined, along with a lot of other critical ones02:37
*** armpit <armpit!~armpit@2601:202:4180:a5c0:69ac:e4d2:e89f:98da> has quit IRC02:56
*** armpit <armpit!~armpit@2601:202:4180:a5c0:d43b:ccb:4c7a:4a12> has joined #yocto03:07
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto03:16
*** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC03:18
*** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto03:18
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto03:27
*** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has quit IRC03:35
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-sxpnkomywsjikyvu> has joined #yocto03:57
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC04:04
*** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has joined #yocto04:20
*** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC04:21
*** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto04:22
*** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC05:19
*** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto05:20
*** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto06:00
*** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC06:16
*** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has quit IRC06:21
*** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has joined #yocto06:34
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:36
*** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has quit IRC06:42
*** cp- <cp-!~cp-@b157153.ppp.asahi-net.or.jp> has joined #yocto06:49
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-gxygurkyftlnjcje> has quit IRC07:01
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto07:06
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto07:08
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto07:09
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC07:25
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto07:29
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto07:31
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:33
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC07:36
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto07:39
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:39
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto07:39
*** mckoan|away is now known as mckoan07:43
mckoangood morning07:44
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:46
*** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC07:46
*** kaspter <kaspter!~Instantbi@222.67.188.180> has joined #yocto07:46
*** alessioigor <alessioigor!~alessioig@out-207-227.elettra.trieste.it> has quit IRC07:58
yoctiNew news from stackoverflow: Yocto bitbake script not displaying echo statement <https://stackoverflow.com/questions/36226828/yocto-bitbake-script-not-displaying-echo-statement>07:58
*** palate <palate!~palate@unaffiliated/palate> has quit IRC08:02
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC08:03
*** alessioigor <alessioigor!~alessioig@out-207-227.elettra.trieste.it> has joined #yocto08:07
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:07
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:14
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC08:29
*** hyper_dave <hyper_dave!~quassel@196.188.72.247> has quit IRC08:32
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC08:52
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto08:53
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC09:01
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto09:01
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:03
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC09:04
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto09:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:08
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC09:09
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto09:11
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC09:14
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC09:16
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto09:17
*** goliath <goliath!~goliath@82.150.214.1> has joined #yocto09:17
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-vkpggcsedxykuiua> has joined #yocto09:21
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:24
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC09:26
*** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto09:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:36
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto09:39
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-grzifmaovbjixtlo> has joined #yocto09:43
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC09:57
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto10:03
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto10:08
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto10:09
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto10:17
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC10:23
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:28
yoctiNew news from stackoverflow: How to clone a git repo with its submodules recursively in Yocto <https://stackoverflow.com/questions/37569941/how-to-clone-a-git-repo-with-its-submodules-recursively-in-yocto>10:29
*** malanecora <malanecora!b23cc82c@178.60.200.44> has joined #yocto10:36
*** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has joined #yocto10:37
*** florian_kc is now known as florian10:51
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.138.42> has joined #yocto10:58
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto11:32
*** camus <camus!~Instantbi@222.67.152.154> has joined #yocto11:35
*** kaspter <kaspter!~Instantbi@222.67.188.180> has quit IRC11:39
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC11:39
*** camus is now known as kaspter11:39
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto11:40
*** georgem_ <georgem_!~georgem@216.21.169.52> has joined #yocto11:42
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto11:43
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC11:45
*** berton <berton!~berton@189.103.49.163> has joined #yocto11:47
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC11:48
*** Phanes <Phanes!~Phanes@surro/founder/phanes> has quit IRC11:48
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC11:48
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC11:48
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has quit IRC11:48
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto11:48
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has joined #yocto11:50
*** berton <berton!~berton@189.103.49.163> has quit IRC11:52
*** berton <berton!~berton@189.103.49.163> has joined #yocto11:53
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC12:04
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto12:05
rburtonwhen firing a new build, remember to push12:06
LetoThe2ndpush harder!12:07
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:11
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC12:18
malanecoraHi guys! I just noticed that the certificates file that is shipped with openjdk (which resides in "/usr/lib/jvm/java-7-openjdk/jre/lib/security/") have expired, however it is still being included in the image instead of being updated at build time. Is this the default behavior? Should I perform any manual action in order to get the current12:29
malanecoracertificates?12:29
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:41
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto12:45
*** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto12:46
ThomasD13Hi, I've got a strange issue which is not directly yocto related.... maybe someone has an idea what the problem could be? https://pastebin.com/GNHERJj7 (Accessing /dev/mem as root)12:50
rburtonThomasD13: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.16-Def-Strict-Dev-Mem?12:51
ThomasD13rburton, thats should be no problem. This kernel configuration just limits the access of /dev/mem to the first megabyte.12:52
ThomasD13I already set this in my .config to "n". I just want to verify that... and now I'm facing the issue that I cannot access /dev/mem on my linux image12:53
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto12:56
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC12:57
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto12:57
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC12:57
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC12:58
yoctiNew news from stackoverflow: PHP odbc driver as shared extension <https://stackoverflow.com/questions/53774481/php-odbc-driver-as-shared-extension>12:59
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto13:00
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto13:02
*** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC13:02
*** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto13:04
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto13:12
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto13:22
*** georgem_ is now known as georgem13:29
*** florian_kc is now known as florian13:32
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto13:46
ThomasD13I have a layer "A" which appends some kernel cfg files. It's structured like /A/recipes-kernel/linux/linux-raspberrypi-rt_%.bbappend13:50
ThomasD13in /A/recipes-kernel/linux/files are the .cfg-files13:50
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:51
ThomasD13Now I have a second layer "B" which should also append some kernel cfg files. It has the same structure as A: /B/recipes-kernel/linux/linux-raspberrypi-rt_%.bbappend + the file directoy with .cfg-files13:51
ThomasD13However, only the .cfg-files from layer "A" are applied to my kernel config. Should it work with my structure or did I setup something wrong?13:52
ThomasD13Layer "A" has 6 as priority, Layer "B" has 9913:53
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto14:00
*** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC14:07
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto14:11
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto14:16
*** rcw <rcw!~rcw@216.154.23.143> has joined #yocto14:37
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC14:38
*** Dracos-Carazza_ is now known as Dracos-Carazza14:40
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto14:54
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto15:01
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC15:08
*** malanecora <malanecora!b23cc82c@178.60.200.44> has quit IRC15:13
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC15:16
*** rcw <rcw!~rcw@216.154.23.143> has quit IRC15:19
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC15:21
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has joined #yocto15:39
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:42
sagnerI set PV = "${DATETIME}" and PV[vardepsexclude] = "DATETIME" in an image recipe, however, I still get basehash value changed errors. bitbake-diffsigs says "Variable PV value changed from '20191125153756' to '20191125153809'", shouldn't that be solved by using vardepsexclude?15:42
RPJPEW: happen to be around yet?15:45
JPEWRP: Ya, I'm here15:56
*** goliath <goliath!~goliath@82.150.214.1> has quit IRC15:57
RPJPEW: just wondering what you make of our email discussion15:58
RPJPEW: and how horrific my patch is? :)15:58
JPEWRP: It's what I expected (e.g. what I would have done :) )15:59
fraysagner, do: PV := "${DATETIME}"  it will be evaluated -once-.15:59
JPEWRP: So is the problem limited only to -cross recipes? They seem to be outliers, since AFAICT they are "target" recipes but generate "native" executable?16:00
JPEW^^ Didn't look closely, I might be wrong16:00
RPJPEW: I think I uncovered another latent bug with the new hash not being written out to the stamp causing setscenes to rerun in the next build16:00
RPJPEW: would apply to any native recipe too16:00
RPfoo-native built on an ARM server will be different to an x86 server16:01
JPEWPrimarily because the native arch isn't part of the task hash, and sstate deals with that by putting them in different directories?16:01
RPJPEW: right, its part of the filename16:01
RPJPEW: I hadn't quite realised how important that was here :/16:01
JPEWme either16:01
sagnerfray: hm, I remember doing that in DISTRO_VERSION where it caused trouble. Its basically imeadiate expansion, but from what I understand we parse multiple times, so the variable will change the value non the less16:02
RPJPEW: I'm wondering how to proceed. I could apply my patch (have an updated fixed version locally) and update the autobuilder server instance with it, then retest16:03
JPEWYa, it's probably worth a try to see if it fixes the problem (if there are free cycles), but I'd like to keep thinking about it16:04
RPJPEW: Cycles are available for this, its key we get this fixed.16:04
RPJPEW: also a question of whether this is 3.0.1 material and we should delay that?16:05
* RP suspects not delaying is the right thing to do16:05
JPEWThe hashes reported to the equiv server don't *have* to be taskhashes... would it be bad to include the host arch in the hashes reported for -native?16:05
JPEWRP: I don't think we should delay either16:06
RPJPEW: how would the arch help us?16:06
sagnerfray: just tried it, still the same issue... Not sure what's going on, but it feels as if PV behaves somewhat different16:09
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto16:11
JPEWWhen bitbake asks the server for an equivalent hash, it won't report the x86-native unihash for arm-native or vis-versa16:12
RPJPEW: that isn't the problem we have though, its the opposite16:14
JPEWThe server should report the same unihash, but it isn't?16:15
RPJPEW: right. we need the same hash for meta-extsdk-toolchain regardless of whether gdb-cross was arm or x8616:16
JPEWsame taskhash, same unihash or both?16:17
armpitRP, 3.0.1 should go and fix the hash issue afterwards16:19
armpitRP, will this hash issue be a M1 blocker?16:20
RParmpit: yes, I think so for M1 and agreed on 3.0.116:21
rburtonChecking for unpackaged file(s): /data/poky-tmp/master/work/intel_corei7_64-poky-linux/packagegroup-core-boot/1.0-r17/recipe-sysroot-native/usr/bin/../../usr/lib/rpm/check-files /data/poky-tmp/master/work/intel_corei7_64-poky-linux/packagegroup-core-boot/1.0-r17/package16:23
rburtonSegmentation fault (core dumped)16:23
rburtonargh16:23
rburtonkanavin_: seen rpm crash like that? ^^^16:25
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has quit IRC16:27
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has joined #yocto16:29
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC16:32
kanavin_rburton, nope16:32
rburtonbah16:32
alessioigorERROR: ParseError at ../meta-96boards/recipes-graphics/mesa/mesa-lima.inc:29: Could not inherit file classes/features_check.bbclass16:34
alessioigorDoes anyone something about it ^^^^ ?16:35
alessioigor*know16:35
rburtonalessioigor: you've updated meta-96boards to master but not oe-core16:35
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto16:36
rburton    distro_features_check: expand with MACHINE_FEATURES and COMBINED_FEATURES, rename16:36
rburtonoe-core 5f4875b950ce199e91f99c8e945a0c709166dc1416:36
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has left #yocto16:36
rburtonif you're using a stable branch of oe-core then use the corresponding branch for meta-96boards, otherwise stuff like this happens16:37
alessioigorrburton: meta-96boards doesn't provide zeus branch :-(16:38
rburtonalessioigor: tell them to, because they just broke zeus users16:38
rburtonshould be trivial to find the patch which did the rename in meta-96boards and revert it locally until they add a zeus branch16:38
alessioigorkhem: ^^^^16:39
alessioigorrburton: Thanks for the tip!16:39
rburtonyeah its the top commit16:39
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC16:40
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto16:40
rburtonndec: fyi meta-96boards is broken with zeus16:41
rburtonkergoth: you need to subscribe to yocto@  :)16:42
kergothoh, huh, i never noticed i hadn't16:43
kergothoops16:43
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC16:44
kergothuhhh16:45
kergothrburton: if i try to login, it says "That email address does not have a lists.yoctoproject.org account.". if i try to register, it says "That email address is already registered."16:45
kergothi think it's confused.16:45
rburtonkergoth: nice16:45
rburtonwell you're on the approved list now16:46
rburtonmaybe halstead knows what its trying to say with those errors16:46
kergothk, thanks16:46
ndecrburton: broken how?16:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:46
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:46
* kergoth tries again16:46
kergothnevermind, got i. halstead ignore that16:47
* kergoth yawns16:47
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:48
sagnerfray: hm, I think this causes problems: http://lists.openembedded.org/pipermail/openembedded-core/2016-July/242143.html16:50
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-qxwdhpilxgetlaqm> has quit IRC16:53
halsteadGood morning. Glad that's sorted.16:54
JPEWRP: Ok, I think I understand the problem: We want the unihashes to look like this: https://docs.google.com/spreadsheets/d/1wicdc6rO67cxglRkORmKkP7nPxzWUNJX5tw5eIIer3o/edit?usp=sharing16:55
*** yann|work <yann|work!~yann@85.118.38.73> has quit IRC16:57
RPJPEW: yes16:58
RPJPEW: realistically that isn't possible so the equiv mapping gives the best way I can think of to establish it16:58
JPEWRight. Theortcially, if you can get the A:arm and A:x86 to match, B would fall in automatically16:59
RPJPEW: yes16:59
RPJPEW: although its actually the case we have D which depends on this task and its D we want the same unihash for17:01
RPthe arch of D being irrelevant as its target, not native17:01
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:01
fraysagner, when ysing DATETIME, it does the current date and time at that exact momemnt..  thus you need VALUE := "${DATETIME}" because you need to evaluate it ONCE, or it will result in hash problems17:02
kergotheven then it can cause problems when files are reparsed, as they are when the tasks run..17:03
sagnerfray, unfortunately I get basehash value changed even when using :=17:03
frayEmbedded a moving data/time stamp is never a good idea.. but that used to work at least..17:04
frayyou can define in your local.conf a data-time  (using the :=) and then use that value in all of the recipes where it matters17:05
fraythe key is it has to be evaluated only once17:05
JPEWRP: Ok, I filled in what I think the code currently does in the file, does that look correct?17:07
RPJPEW: I'm confused now. E2 should be B ?17:11
RPer, E317:11
RPand E7 should be D, not C17:12
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has quit IRC17:13
frayRP - is there any documentation on how to use the hash equivalency stuff in Zeus/Master?  I thought you posted something, but I'm failing to find it17:13
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC17:14
RPfray:  look at local.conf.sample ?17:15
frayFail, I didn't look there.. :P17:15
frayI thought you had to enable a bbclass to do the comparison though..17:17
RPfray: no, all magic done behind the scenes17:17
frayok, so I misunderstood that then.. ok17:18
frayHow/where does it detect two hashes are actually the same and publish that to the server?17:18
RPfray: hook in sstate.bbclass which calls into the siggen17:19
RPdefault siggen handler is an empty function for the old sig hander. For hashequiv its not17:19
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto17:20
frayok.. thanks17:23
RPJPEW: I added patches to -next for this17:31
frayok.. so if I'm understand correctly.. the way it works is during initial parse, it contacts the server to see if there is an existing hash equivalence.. if there is, it uses it... if not it goes ahead and builds, then as it constructs sstate-caches, it checks for equivalency in output and marks a hash as equivalent if they come out the same, uploading that data to the server..  is that correct?17:33
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC17:37
*** sagner <sagner!~ags@37.17.234.113> has joined #yocto17:37
*** armpit <armpit!~armpit@2601:202:4180:a5c0:d43b:ccb:4c7a:4a12> has quit IRC17:44
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC17:45
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-vkpggcsedxykuiua> has quit IRC17:50
RPfray: yes17:51
fraythanks.. that helps a bunch.. it was the second half I wasn't aware of before..17:51
rburtonRP: ross/next is about to go green if you want to pick from that17:51
rburtonjust a couple of bits left17:51
RPrburton: cool, will take a look17:52
RPrburton: thanks17:53
rburtonRP: don't pick the u-boot patch, alex has sent something that supercedes it17:53
rburtonpushing a revert to make that clear :)17:54
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC17:54
*** mckoan is now known as mckoan|away17:54
RPrburton: I'm already editing :)17:54
rburtoni'd base it on master-next but there's some of your HACK BREAK ALL THE THINGS patches in there ;)17:55
RPrburton: right, trying to get to the bottom of the problems17:55
RPrburton: parted missing S-o-b17:56
rburtondamnit17:56
rburtonfeel free to drop that, there was more originally17:56
frayso relatd ... does packagefeed stability use any of the same components as the hash equivalency?17:56
rburtonfray: i'd say hash equiv is a prerequisitic for easy feed stability17:57
rburtonit moves the 'these binaries are the same' away from the feed and into the build17:57
rburtonso instead of building it all and throwing away the result, just don't build17:57
frayyes, I assumed they could both be used at the same time...17:58
RPrburton: pushed stuff. There are more patches in -next which are probably safe17:58
frayI'm in the process of writing up some guidelines for a binary distribution and I'm trying to remember all of the moving pieces.17:59
RPfray: hashequiv will definitely make a binary distro easier17:59
JPEWRP: Ok, it's order dependent. I left comments in the cells to explain the logic18:00
fraypackage stability, pr service, hash equivalency... the reproducible builds..18:00
JPEWIn the second example, it does what we want (by accident)18:00
frayAm I missing anything?18:00
RPfray: would we need package stability?18:01
frayyes, otherwise different builds of common tools could result in slightly different contents.. (i.e. the whole python internal hash thingy)18:01
fray'er.. wait that is the reproducible builds..18:01
* fray backs up..18:01
fraythe package stability and pr service are linked AFAIK.. so I thought they the stability would still be desired with the hash equivalency18:02
RPJPEW: I think I understand now18:02
RPJPEW: I was misreading what you meant in there I think18:02
JPEWYa, the important thing to remember is that the unihash defaults to the taskhash18:03
RPfray: I hope that you can just get away with hash equiv and prserv18:03
frayI was concerned that that could result in odd pr behavior but maybe not?18:03
rburtonRP: will do a build test here then fire another round on the AB18:03
RPfray: shouldn't18:04
frayRP the other thing we talked about before was a way to extend the buildhistory..  Based on some conversations from ELC-E, I want to implement ABI/API comparison using build history as the storage mechanism.. but I'd first need the extension support we talked about earlier in the year18:04
RPrburton: cool. Bonus marks for enabling reproducibile builds as default in poky but not hashequiv as a test build. THink that may be ready18:04
RPfray: right18:05
* RP -> afk, food18:05
rburtonfray: redhat have a nice abi comparison tool18:05
JPEWEww, that first case is pathological :(18:06
frayyes.. I already know how to implement it..18:07
fray(turns it I'm not sure it's actually Red Hat, but something Red Hat uses)18:07
fraythe comparison parts of the tooling Fedora/RH use aren't nearly as useful to us as the dumping of the API and ABI info, and storage to the build history..18:07
frayif that happens, then we can have our own comparison tooling..18:07
rburtonthe one i'm thinking of - the name of which i've forgotten - was written by an ex-colleague at RH18:08
rburton(RP: dodji!)18:08
*** armpit <armpit!~armpit@2601:202:4180:a5c0:4070:35fc:4101:33f5> has joined #yocto18:08
rburtonlibabigail!18:08
rburtonthat's the one18:08
armpitrburton, is that Gaelic ?18:11
armpitor one too many beers ?18:12
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:21
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto18:33
rburtonarmpit: abigail is a name, and its an ABI tool, so i guess that's the derivation?18:43
JPEWRP: Ok, I think i have the server side fix18:45
JPEWEffectively does the same thing but probably more efficiently. I'll have to think about repercussions18:45
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:01
sagnerfray: I think I start to understand now: bitbake these days parses twice, once in the cooker and once in the worker. Even when using immediate expansion those two parse runs will result in different hashes and ultimately to the basehash value changed error message (this is what https://git.openembedded.org/bitbake/commit/?id=857829048c14338132784326ba98a71f12192db8&h=master explains nicely)19:03
sagnerfray: the only way out here is using vardepsexclude, however, this i broken for PV for two reasons:19:04
sagnerfray: 1. We use PV[vardepvalue] = "${PV}" in sstate.bbclass.19:05
kergothwas fray's suggestion to set it with := in local.conf or elsewhere in the config metadata and then use it in the recipe not viable?19:06
sagnerfray: 2. for tasks generated in IMAGE_CMD_x "localdata.setVar('PV', d.getVar('PV'))" is used in image.bbclass, which forces expansion19:06
sagnerkergoth: no, since PV will still change19:07
kergothwhat's the purpose behind using the datetime stamp in the version at all?19:08
sagnerkergoth: we use the image's PV as version for a custom image format (since "package version" on the image sounds like a reasonable variable to reuse for this case...). This we do since quite a while, only recently we'd like to have a timestamp in the version. So that is why I started investigating19:10
sagnerkergoth: one option is to not use PV in our custom image format but some other variable.19:11
kergothi'd suggest either emitting the stamp into a .conf that bitbake includes before running bitbake, so it's locked down before bitbake even starts, or use a different variable rather than PV19:11
sagnerkergoth: yeah that works for scripted CI jobs, where we already add build numbers. I was considering this for development, where it is sometimes hard to link a currently installed build from what is lying on my build machine when doing several cycles a day. So ideally it should be "OE built-in" functionality...19:14
sagnerkergoth: anyways, I think I will move away from using PV. Will also send an email to the mailing list as I haven't found anything about that topic (PV vs. DATETIME vs. vardepsexclude).19:15
* kergoth nods, sounds like a good plan, could arguably open a bug proposing a future enhancement to make this workflow easier in the future19:16
JPEWRP: Ok, I'm convinced that updating the hashes is the correct thing to do, but I think it will be much easier server side19:50
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto20:03
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC20:10
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:24
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC20:26
yoctiNew news from stackoverflow: YOCTO Change kernel version and select drivers <https://stackoverflow.com/questions/58836721/yocto-change-kernel-version-and-select-drivers>20:31
RPJPEW: My SQL in my patch is horrid ;-)20:38
RPJPEW: not sure you can do this totally server side since you need more information about the previous hash20:39
ndechi kergoth , something looks odd with your mailing list account. are you receiving emails?20:41
kergothit's gmail, i highly doubt it's down :)20:41
ndeci can see your mentor email address.20:41
ndecset to 'no email' in the system. is that what you wanted/20:41
ndecyour last message still needs to be moderated.20:42
kergothi don't believe any of my patch emails were from my mentor address. they cc'd the mentor address, but weren't from it20:43
kergothmore likely i was just not subscribed to all the lists, i didn't check them all20:43
* kergoth shrugs20:43
kergothcatching up on my upstream submission backlog20:43
ndeckergoth: hmm.. what email address do you expect to use on lists.yoctoproject.org (before the transition)?20:44
ndecah, i can see your gmail address.. and it's set to deliver emails. let me check what you subscribed to.20:45
kergoththe only address i use with lists.yoctoproject.org is kergoth@gmail20:45
ndecwell, there is one email from your mentor email sent a couple of hours ago, which is the moderated queue20:46
ndeca reply to "[meta-intel][PATCH] thermald: fix the url"20:46
kergothah, that was unintentional, apparently Sparrow picked the wrong from address20:48
kergoththe reply was just saying to ignore that patch anyway, i sent it to the wrong list :)20:48
kergothre-sent it to meta-intel@20:48
ndecok, so i should delete that email, and i guess you mentor address as well?20:49
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto20:50
rburtonkergoth: is sparrow still around?20:55
kergother, i meant Spark, not sparrow. stopped using hte latter ages ago20:59
JPEWRP: I'll do some cleanup and documentation and post it up for review21:00
rburtonkergoth: can you let me /query you please, want to pick your brains for a moment21:06
RPJPEW: ok, curious how you plan to do it differently!21:12
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has joined #yocto21:14
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-sxpnkomywsjikyvu> has quit IRC21:15
*** berton <berton!~berton@189.103.49.163> has quit IRC21:16
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC21:19
*** vineela <vineela!vtummala@nat/intel/x-xtwedaiuvbwqpwyb> has joined #yocto21:20
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC21:32
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto21:35
*** vineela <vineela!vtummala@nat/intel/x-xtwedaiuvbwqpwyb> has quit IRC21:44
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto21:44
RParmpit: I merged zeus. I've sneaked a couple of other bitbake fixes in ;-)21:45
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21:52
*** vineela <vineela!vtummala@nat/intel/x-unguqpgwpkqhyerm> has joined #yocto21:54
*** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has quit IRC21:55
*** chandana73 <chandana73!~ckalluri@149.199.62.129> has quit IRC22:08
*** chandana73 <chandana73!~ckalluri@149.199.62.131> has joined #yocto22:12
*** chandana73 <chandana73!~ckalluri@149.199.62.131> has joined #yocto22:14
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto22:18
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC22:20
*** JaMa <JaMa!~martin@109.238.218.228> has quit IRC22:21
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC22:26
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto22:30
*** khem <khem!~khem@unaffiliated/khem> has quit IRC22:36
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto22:43
* armpit looks22:49
armpitack22:52
armpitthanks22:52
armpitrp, what about the other changes core changes /me looks at merge request22:55
rburtonRP: my python 'clean up' patch is broken.  or actually it's good, but its too good, and breaks packaging.22:56
armpitdid the other 8 not being accepted ?22:56
armpitrburton, we don't want too good22:57
rburtonfor some reason .pyo files are generated when they were not before, and they all end up in python-xml :)22:57
*** aehs29 <aehs29!~aehs29@149.199.62.131> has joined #yocto23:08
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC23:32
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC23:33
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto23:34
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC23:37
* armpit cool 5.4 dropped23:54
* armpit short eol 23:54
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC23:56
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto23:59

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!