Tuesday, 2022-03-22

*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto00:13
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Client Quit)00:14
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto00:15
*** dacav <dacav!~dacav@h94-245-9-196.cust.a3fiber.se> has quit IRC (Ping timeout: 240 seconds)00:16
*** codavi <codavi!~akiCA@user/akica> has joined #yocto00:22
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds)00:26
*** Habbie <Habbie!peter@lorentz.7bits.nl> has quit IRC (Ping timeout: 240 seconds)00:34
*** Habbie <Habbie!peter@lorentz.7bits.nl> has joined #yocto00:41
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)00:42
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto00:46
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection)00:47
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto00:48
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)00:53
khemRP seeing peudo fetch errors with master-next00:54
khempseudo-native PROVIDES virtual/fakeroot-native but was skipped: Skipping Recipe : Unable to resolve 'df1d1321fb093283485c387e3c933d2d264e509' in upstream git repository in git ls-remote output for git.yoctoproject.org/pseudo00:54
*** tcdiem <tcdiem!~tcdiem@ppp-188-174-62-170.dynamic.mnet-online.de> has quit IRC (Ping timeout: 252 seconds)00:55
khemRP see https://git.yoctoproject.org/poky-contrib/commit/?h=kraj/poky-next&id=3a1d7992c079a727fc4d3340c5372a0467b8723c01:00
khemsielicki given the situation you explained, I would suggest to start with kirkstone and make your intention clear to vendors that you are using this LTS, for same reason we started doing LTS, where large number of layers can be compatible with each other, dunfell was our first LTS and I could give rider to some of the layers to not have a release against it, but hope they have got their act together this time around with kirkstone01:08
khemXilinix does not support dunfell ? thats a bummer, I was not expecting that but then I dont expect too much these days01:09
khemI think realistically there are two options use LTS or stay on master, staying on master might be troublesome too since some BSP layers do not support master as well as some others, perhaps your procurement should make a policy in MSA and ask explicitly for LTS before you buy these chips01:10
sielickinah, you can see them justify it here: https://lists.yoctoproject.org/g/meta-xilinx/topic/is_xilinx_working_on_a/77383753?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,7738375301:10
khemyes thats perhaps fine as dunfell was first LTS, I hope they are on board with kirkstone01:12
sielickiwhat's disappointing to me is to see him say, "We suspect that gatesgarth will work with dunsfell, but we've not tested it.". Kind of why I bring up the idea of giving users the ability to try it and see with a special flag. Vendors won't stick their neck out to throw a line in there, because they don't want to be on the hook for supporting it.01:12
sielickiHere's hoping. I'm really hoping to catch the LTS train on kirkstone and help my company stay on the LTS train for as long as i'm here.01:13
khemI think if a SOC support layer or any other layer is not LTS, I would consider that a big negative for chosing that SOC, especiallly if you have multi SOC products01:14
sielickithe cold hard reality, much to my dismay, is that we don't actually value having up to date or secure systems. We still cook dora images.01:16
khemoh wow, get your act together I must say01:17
*** tcdiem <tcdiem!~tcdiem@ppp-188-174-87-254.dynamic.mnet-online.de> has joined #yocto01:18
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)01:37
*** camus <camus!~Instantbi@> has joined #yocto01:53
*** dacav <dacav!~dacav@h94-245-9-200.cust.a3fiber.se> has joined #yocto01:59
*** starblue <starblue!~juergen@dslb-094-221-188-003.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds)02:17
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has joined #yocto02:18
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 250 seconds)02:18
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto02:23
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 252 seconds)02:30
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto02:32
*** RobertBerger <RobertBerger!~rber|res@ppp-94-67-133-210.home.otenet.gr> has joined #yocto02:32
*** rber|res <rber|res!~rber|res@ppp-94-67-133-210.home.otenet.gr> has quit IRC (Ping timeout: 252 seconds)02:34
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto02:35
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 268 seconds)02:42
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)02:43
*** camus <camus!~Instantbi@> has joined #yocto02:45
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto02:48
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 240 seconds)02:53
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto02:58
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 252 seconds)03:04
*** tcdiem <tcdiem!~tcdiem@ppp-188-174-87-254.dynamic.mnet-online.de> has quit IRC (Ping timeout: 240 seconds)03:07
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto03:08
*** michalkotyla_ <michalkotyla_!~quassel@84-10-27-202.static.chello.pl> has joined #yocto03:10
*** otavio <otavio!~otavio@201-3-135-79.paemt705.dsl.brasiltelecom.net.br> has joined #yocto03:10
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto03:11
*** otavio_ <otavio_!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has quit IRC (*.net *.split)03:11
*** michalkotyla <michalkotyla!~quassel@84-10-27-202.static.chello.pl> has quit IRC (*.net *.split)03:11
*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (*.net *.split)03:11
*** dv__ <dv__!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC (*.net *.split)03:11
*** sgw <sgw!~swold_loc@user/sgw> has joined #yocto03:11
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 250 seconds)03:17
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto03:24
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 256 seconds)03:31
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto03:36
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds)03:43
*** jclsn73 <jclsn73!~jclsn@> has quit IRC (Ping timeout: 256 seconds)03:47
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 252 seconds)03:50
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has joined #yocto03:51
*** jclsn73 <jclsn73!~jclsn@> has joined #yocto03:53
*** amitk <amitk!~amit@> has joined #yocto04:25
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)04:37
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto04:50
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds)05:00
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto05:15
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds)05:19
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto05:37
*** frieder <frieder!~frieder@i59F4B31D.versanet.de> has joined #yocto05:56
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:56
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:58
moto-timoJaMa: https://github.com/moto-timo/meta-ros/tree/kirkstone (WIP)05:59
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:03
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340:cfbf:d57d:b0f7:eb51> has quit IRC (Ping timeout: 240 seconds)06:07
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)06:08
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340:cfbf:d57d:b0f7:eb51> has joined #yocto06:12
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)06:26
*** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has joined #yocto07:04
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:04
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto07:07
*** jclsn73 is now known as jclsn07:12
jclsnUps no terminal haha07:12
jclsnqschulz: I did not have any success diffing the build folders btw. The diff on linux-fslc-ixm takes ages. I also tried a diff on kernel-imx-gpu-viv and I don't see anything suspicious https://pastebin.com/DC53BDVH07:19
jclsnIf I don't find out the cause for this, I will just wipe my laptop. The other machine I have installed, produces a bootable kernel with the same Ubuntu version, tools and zsh07:19
cb5rWhat's the way to enable LTO for only one recipe?07:20
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:21
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto07:27
jclsncb5r: LTO?07:29
*** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)07:31
jclsnHmm no idea07:32
cb5rI am aware that DISTRO_FEATURES:append = " lto" exists, but apparently will fail for some recipes (https://git.yoctoproject.org/poky/plain/meta/conf/distro/include/lto.inc). I tried the settings from the link in a dunfell build but it failed (qemu-native). Anyhow - I think LTO for my entire build might be a bit overkill considering the increased build time07:32
cb5rI think I should be fine optimizing only a few components07:33
*** mckoan|away is now known as mckoan07:41
mckoangood morning07:42
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 252 seconds)07:45
*** davidinux <davidinux!~davidinux@> has joined #yocto07:47
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 268 seconds)07:56
*** rperier <rperier!~quassel@234.ip-51-91-57.eu> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)07:59
*** rperier <rperier!~quassel@234.ip-51-91-57.eu> has joined #yocto07:59
*** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has joined #yocto08:00
*** GillesM <GillesM!~gilles@> has joined #yocto08:04
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto08:15
*** camus1 <camus1!~Instantbi@> has joined #yocto08:23
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)08:24
*** camus <camus!~Instantbi@> has joined #yocto08:26
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto08:26
*** vladest <vladest!~Thunderbi@81-229-209-18-no288.tbcn.telia.com> has quit IRC (Quit: vladest)08:27
*** camus1 <camus1!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)08:27
*** vladest <vladest!~Thunderbi@81-229-209-18-no288.tbcn.telia.com> has joined #yocto08:28
*** camus1 <camus1!~Instantbi@> has joined #yocto08:40
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)08:41
*** camus <camus!~Instantbi@> has joined #yocto08:41
*** camus1 <camus1!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)08:44
*** camus1 <camus1!~Instantbi@> has joined #yocto08:48
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)08:48
*** camus <camus!~Instantbi@> has joined #yocto08:49
*** camus1 <camus1!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)08:52
*** Schiller <Schiller!~Schiller@p200300efa709a001d9499e31e9cd6eaa.dip0.t-ipconnect.de> has joined #yocto08:55
SchillerHello there. I am new to this Channel and it got it suggested from Michael Halstead for some quick questions. Further more i am not a native speaker so i hope it is all understandable. I have some problems with setting up standalone YPAutobuilder. Can you help me or suggest someone for further information? (also i am from germany and confronted you09:02
Schillerbecause of your username).09:02
*** Schiller <Schiller!~Schiller@p200300efa709a001d9499e31e9cd6eaa.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed)09:08
*** Schiller <Schiller!~Schiller@p200300efa709a001d9499e31e9cd6eaa.dip0.t-ipconnect.de> has joined #yocto09:08
SchillerHello to everyone. I am having trouble with setting up the YPAutobuilder. It's also my first time in this Chatroom. So i guess if someone has the time and knowledge you can contact me privately. Thank you in advance for the help.09:11
*** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has quit IRC (Read error: Connection reset by peer)09:17
*** florian_kc <florian_kc!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has joined #yocto09:17
*** florian_kc <florian_kc!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has quit IRC (Read error: Connection reset by peer)09:17
*** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has joined #yocto09:17
rburtonSchiller: there's a few people here who know about it, but it's best if you explain what your problem is09:31
SchillerThank for the reply. I have some questions on the hash equivalency server and some general questions about the buildfactorysteps.09:35
*** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has joined #yocto09:40
*** camus1 <camus1!~Instantbi@> has joined #yocto09:49
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)09:52
*** camus1 is now known as camus09:52
qschulzSchiller: we're all ears, please ask your questions09:53
*** camus1 <camus1!~Instantbi@> has joined #yocto09:54
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:55
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)09:56
*** camus1 is now known as camus09:56
SchillerWhen i run a build - let's say beaglebone - in my setup everything seems to work properly. All 10 Buildsteps which are mentioned in the Builders.py finish correctly. When i compare it to the Buildprocesses in https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/4955 i recognized way more Buildsteps. For instants the setup i run doesn't09:57
Schillereven run a full build with bitbake. Is that a buildstep i have to add manually or should it already be implemented in the minimal setup suggested on the Guide https://git.yoctoproject.org/yocto-autobuilder2/tree/README-Guide.md09:57
GillesMHello cant iI runqemu without network ... I tried runqemu qemux86 qemuparams="-nic none" without success10:12
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 252 seconds)10:30
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:c329:5a78:19e:dafb> has joined #yocto10:35
landgrafGillesM: adding -nodefaults might help.10:42
SchillerI'm new to this hole framework. Is my question understandable? Also not a native speaker.10:51
RPqschulz: morning. I tried to reply yesterday, hope I made sense! :)10:55
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto10:55
RPSchiller: I think that the code has changed a bit since the README you refer to was written10:57
RPSchiller: The code now supports "dynamic" build steps the json code in yocto-autobuilder-helper can dynamically set how many steps are needed10:58
RPSchiller: for the beaglebone you mentioned, it is declared here: https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n27510:59
RP(which uses the arch-hw template defined above that earlier in the file)11:00
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds)11:04
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds)11:04
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto11:05
qschulzRP: it did, thank you very much for sending a v2 of all patches in one thread :) I'll get to the review this afternoon11:06
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has joined #yocto11:06
rburtonRP: do you have an opinion on the timeout question in JaMa's reply to my bitbake patch?11:07
RPrburton: happy to have it be 10 mins11:12
RPrburton: I worry that for long running AB tests we'll see spam but it probably is more useful than not11:13
rburtonlets see how spammy it is with a 10 minute cycle11:13
RPqschulz: I thought it might help make things clearer (the autobuilder-helper and transition branch patches aren't there)11:14
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto11:20
*** mabnhdev2 <mabnhdev2!~mabnhdev2@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has joined #yocto11:23
mabnhdev2Hi, I'm trying to add several python recipes to my system.  Several of these packages don't include a license text file.  Instead, they just refer to the license in documentation or project metadata.  How do I handle this in Yocto?11:25
rburtonmabnhdev2: start by filing a bug so they ship a license statement in the source.  worst case, i've set the license checksum to the specific line in the setup.py that says license="mit" or whatever.11:26
rburtonthe checksum is all about noticing if the licence changes, so eg the setup.py license assignment is a good thing to track anyway as its canonical (gets used on pypi for example)11:27
mabnhdev2rburton That war has already been fought and lost - https://github.com/jaraco/skeleton/issues/111:28
rburtonin that case just set the license checksum to eg specifically line 11 of setup.cfg11:31
rburtonby setting LICENSE to MIT you get the full canonical license text in the license data we generate already11:31
mabnhdev2rburton I'm not sure I understand about setting the checksum to a specific line.  Is there an example you can point me to.11:31
rburtonmeta/recipes-core/musl/bsd-headers.bb:LIC_FILES_CHKSUM = "file://sys-queue.h;beginline=1;endline=32;md5=c6352b0f03bb448600456547d334b56f"11:32
mabnhdev2rburton Cool.  Thanks!11:32
rburtonor more relevantly for python code11:32
rburtonmeta/recipes-devtools/python/python3-setuptools-scm_6.4.2.bb:LIC_FILES_CHKSUM = "file://PKG-INFO;beginline=8;endline=8;md5=8227180126797a0148f94f483f3e148911:32
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)11:41
*** camus <camus!~Instantbi@> has joined #yocto11:42
rburtonRP: hm. did a full build with the public sstate and three tasks failed with this message. obviously that log file is long gone, which is a pain. Maybe download problems and that's a bad way of saying timeout? https://www.irccloud.com/pastebin/b06WBykI/11:50
*** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto11:55
RPrburton: not sure. That is annoying11:58
rburtonthree out of nearly 10k fetches12:03
rburtonfinal aggregate results are Wanted 45932, found 19791 locally, 9773 remote, missed 16368. Hit rate 64%.12:03
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto12:03
RPrburton: shame we don't know how it failed :/12:15
rburtoni think i just got our CI to archive the build logs12:15
rburtonso will see if it happens again12:15
cb5rIf I set DL_DIR to download/ from a different build dir (with slightly older layers) - should this normally work? - Or is there a chance that BB will use wrong sources then?12:15
rburtoncb5r: it will always work12:15
rburtonthe only way it can use the "wrong" source is if eg bash-4.0.tar.gz has changed contents12:16
rburtonif that has happened, you've bigger problems12:16
cb5rrburton: ...which basically only should happen if I manually modify it?12:16
rburtonyou're absolutely encouraged to share DL_DIR and SSTATE_DIR between all builds and all versions12:17
rburtonwell upstream could change the content without changing the version12:17
rburtonagain, bigger problems: is that a sneaky fix, or is that a backdoor12:17
rburtonthe checksums will fail12:17
cb5rOK great - I shall share DL_DIR and SSTATE_DIR in the future then - thanks!12:18
rburtonwhen in doubt ask what the yocto autobuilder does: every build across every supported release and every build host uses the same NFS mount for DL_DIR and SSTATE_DIR12:18
cb5rAre there also temp dirs that I can/should put on a tempfs to speed up build time and reduce SSD wear? Or does BB use /tmp anyway?12:20
cb5r"NFS mount for DL_DIR and SSTATE_DIR" << OK thats good to know - so those 2 dirs to not rely on high speed then?12:20
rburtonthey're fetched occasionally so high speed isn't critical12:21
rburtonyou can put the build dir in a tmpfs if you have enough RAM, yes12:21
rburtonyou'll want rm_work to keep usage low12:21
cb5rI am trying to optimize my partitions/mounts/shares/whatever here currently, since I am working with different  VMs etc. So sharing would be pretty cool12:21
cb5rwhats rm_work?12:22
cb5rthis? https://git.yoctoproject.org/poky/plain/meta/classes/rm_work.bbclass12:24
rburtonno point keeping 10gb of build tree in ram when its not needed anymore12:26
*** pabigot <pabigot!~pab@67-1-16-117.tcso.qwest.net> has quit IRC (Remote host closed the connection)12:31
*** pabigot <pabigot!~pab@67-1-16-117.tcso.qwest.net> has joined #yocto12:34
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)12:38
cb5rThats true. - But if the build fails, my "cache" is gone - so everything needs to be compiled from scratch - right?12:46
marc3nope, there's a difference between the 'work' and the 'shared-state cache'12:50
marc3See: https://docs.yoctoproject.org/overview-manual/concepts.html#shared-state-cache12:52
*** mabnhdev2 <mabnhdev2!~mabnhdev2@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has quit IRC (Quit: Client closed)12:55
*** BobPungartnik <BobPungartnik!~Pung@> has joined #yocto12:57
*** BobPungartnik <BobPungartnik!~Pung@> has quit IRC (Remote host closed the connection)12:58
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds)13:04
cb5rOK, thanks!13:10
hmw[m]Hi i'm trying to build an application with qt and mysql but when using a qt call db = QSqlDatabase::addDatabase("QMYSQL", name); i get a SIGILL13:12
rburtonillegal instruction: your compiler tune/etc doesn't actually match the hardware13:15
rburtondmesg will tell you what the instruction is, but tell us what MACHINE and what hardware and it might be obvious13:15
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto13:16
rburtonRP: https://github.com/openssl/openssl/commit/9e1a54f4a187195fc417ad0f90e84d208d478968 finally got that in :)13:16
hmw[m]rburton: oke tnx but i use the sdk generated from same thing as the running rootfs13:17
rburtonis the target x86 and you're running the sdk on x86?13:19
hmw[m]target is arm and the compiler in qt is arm-oe-linux-gnueabi-gcc13:19
rburton<shrugs>. you're getting illegal instruction, so your compiler tune flags are wrong13:20
hmw[m]( running the sdk on x8613:20
rburtondmesg will tell you what the instruction is, or run it in gdb and let that catch it to tell you where13:20
rburtoncould be some dumb code making assumptions like 'yes of course i have <some instruction>' which you don't have13:20
rburtonlike how last month I upgraded uboot and it assumes that CRC instructions are present, but they're optional.13:21
rburtonsuddenly, it didn't boot13:21
hmw[m]m tnx seems like i don´t have qtsql package13:23
hmw[m]on rootfs13:23
hmw[m]that is not a package :(13:27
RPrburton: nice to have that sorted :)13:27
rburtonone more down!13:31
*** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has quit IRC (Read error: Connection reset by peer)13:39
*** florian__ <florian__!~florian@> has joined #yocto13:39
qschulzhmw[m]: oe-pkgdata-util find-path '*sql*' to find which package to install13:39
qschulzhmw[m]: if the recipe building the package has been baked13:40
Schillerwhen i setup the YPAutobuilder like in this Guide https://git.yoctoproject.org/yocto-autobuilder2/tree/README-Guide.md . To accomplish a full build (for example beaglebone) do i need to configure the .../yocto-auto-helper/config.json for additional steps or should they already be set per default. Because my Step 9. (Check run-config steps to use)13:44
Schillerseems to finish in less then a sec which surely isn't correct.13:44
hmw[m]<qschulz> "hmw: oe-pkgdata-util find-path '..." <- it created sqldrivers/mysql/.moc/moc_qsql_mysql_p.cpp13:50
hmw[m]so it should be in ?13:50
qschulzhmw[m]: didn't understand your message sorry13:52
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:54
hmw[m]qschulz: if the  oe-pkgdata-util find-path '*sql*' | grep qt # returns qtbase-src: /usr/src/debug/qtbase/5.14.2+gitAUTOINC+3a6d8df521-r0.arago17/git/src/sql/kernel/qsqldriver.h13:56
hmw[m]than that that "package" is installed ?13:56
qschulzit returns which file belongs to which package13:56
qschulzhere /usr/src/debug/qtbase/5.14.2+gitAUTOINC+3a6d8df521-r0.arago17/git/src/sql/kernel/qsqldriver.h belongs to qtbase-src package13:56
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)13:57
qschulzhmw[m]: also, don't grep for qt,since I think the file you're looking for is probably qsql and not qtsql13:57
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto13:59
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:00
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto14:02
RPqschulz: To change activereleases I think I'll have to do another test cycle so it will take a while :/14:06
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto14:12
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 252 seconds)14:16
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:16
moto-timohmw[m]: you need to add the PACKAGECONFIG https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase_git.bb#L12014:16
moto-timohmw[m]: MySQL support is not included in the default14:17
*** yolo <yolo!~xxiao@li1120-73.members.linode.com> has joined #yocto14:17
yolois usrmerge enabled by default in new yocto or oe-core these days14:17
hmw[m]PACKAGECONFIG[qtbase] += "sql-mysql" ?14:18
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)14:19
moto-timo hmw[m]: no look at local.conf for example, such as https://git.yoctoproject.org/poky/tree/meta-poky/conf/local.conf.sample#n24714:22
RPyolo: no14:22
qschulzhmw[m]: create a bbappend for qtbase in your own layer and add PACKAGECONFIG += "sql-mysql" (or PACKAGECONFIG_append = " sql-mysql" or PACKAGECONFIG:append = " sql-mysql")14:23
sgwMorning all14:24
*** Schiller <Schiller!~Schiller@p200300efa709a001d9499e31e9cd6eaa.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed)14:26
* sgw has a historical question about kernel package naming, anyone know my most qemu MACHINE types install a kernel-<ver> package but Intel MACHINE types (including genericx86) install both a kernel and kernel-<ver> package. Yes, I have been digging around conf/machine, nothing jumps out at me yet.14:26
sgws/my most/why most/14:27
RPsgw: no idea FWIW14:27
sgwRP: more digging required, this is partly related to the depmod issue, since any Intel HW specific (not qemu) MACHINE types seem to add the kernel package, this causes the kernel-dbg package to be installed also, but other MACHINE types (including qemu) with kernel-<ver> don't have a kernel-<ver>-dbg, thus don't see this issue.14:29
LetoThe2ndyo dudX14:30
mckoanLetoThe2nd: hear! hear! the jester is back with us!14:34
LetoThe2ndmckoan: yeah... i would have loved to not be "away"14:34
mckoanLetoThe2nd: I am pleased to note that you have to work now, LOL14:35
yoloRP: how to enable that? google did not show anything, mega-manual does not mention it either, is it 'ready' for use14:37
yoloDISTRO_FEATURES_append = " usrmerge" -- is this it14:38
hmw[m]<qschulz> "hmw: create a bbappend for..." <- tnx apparently i did do that already. still finde the SIGILL strange14:41
qschulzyolo: seems about right (might be :append if you are on honister or master branch)14:41
qschulzhmw[m]: are you sure the package with the appropriate file is installed in your image?14:41
yoloqschulz: thanks!14:46
RPyolo: probably DISTRO_FEATURES:append = " usrmerge"14:47
RPheh, qschulz beat me to it14:47
yolocool, building and testing now14:47
hmw[m]qschulz: no but If I ask for opkg info qtbase it shows that that is installed14:47
* yolo is trying to suggest FHS to add /opt/local/{bin,sbin,lib,man,etc} to replace /usr/local so /usr can be read-only14:48
yoloall scripts default to install to /usr/local but to have /usr read-only is worth that change IMHO14:48
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)14:57
qschulzRP: adding tags? but that's cheating :D15:08
*** frieder <frieder!~frieder@i59F4B31D.versanet.de> has quit IRC (Remote host closed the connection)15:10
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)15:12
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:15
hmw[m]<qschulz> "hmw: are you sure the package..." <- find /usr/ -iname "*qsql*"15:16
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer)15:17
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto15:17
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection)15:18
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto15:18
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds)15:25
*** creich_ <creich_!~creich@p200300f6af2fa2103004eb7d76543b37.dip0.t-ipconnect.de> has joined #yocto15:25
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto15:26
*** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has joined #yocto15:26
*** creich <creich!~creich@p200300f6af1194100000000000000100.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)15:27
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)15:27
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto15:28
Schillerin the YPAutobuilder setup u will need a User with root rights. Is it acceptable to edit the UID and GID in the /etc/passwd to 0 or will this run into some conflicts because i am not pokybuild3 anymore.15:29
rburtonRP: good news! my little patch to openssl has exploded their ci.  by good i mean terrible.15:31
RPSchiller: you don't need root. Just run runqemu-gen-tapdevs to setup the tap devices on the worker15:32
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds)15:32
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:32
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)15:33
*** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto15:36
Schillerdo you mean this shell-script https://github.com/openembedded/openembedded-core/blob/master/scripts/runqemu-gen-tapdevs within the yocto-worker?15:37
RPrburton: oops, or do I mean congrats :)15:39
RPSchiller: yes15:39
RPSchiller: that script allows the tap devices to be setup in advance removing the need for root access anywhere ele15:40
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto15:40
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 252 seconds)15:44
Schillerik. stupid question but what exactly is a tap device (because i have to input a number).15:44
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto15:45
RPSchiller: it is basically like a network interface. How many images might you run in parallel15:45
Schillerk thx15:45
*** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has quit IRC (Quit: Connection closed)15:47
Schilleris that script supposed to lie somewhere and get called during buildprocess and edited or is it supposed to be run manually before i start the buildbot-controller?15:53
Alban[m]Hi! Is there a good alternative to NFS to share sstates, something that would work well over the public internet?15:55
RPAlban[m]: http if you're ok with read only15:56
Alban[m]RP: That would be using SSTATE_MIRRORS?16:00
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds)16:06
Schilleri am not quite sure how to use the runqemu-gen-tabdevs script. does it get called from some othere script? where in the YPAutobuilder project does this script has to lie. which parameter does native-sysroot-basedir expect (what path)?16:15
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds)16:18
*** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has joined #yocto16:20
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 240 seconds)16:34
Alban[m]Build don't seems to re-use sstates properly, now looking at some sig diff I see the following:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/75a9bfc53e59f2c2896b34c6c1f2757b366b7c9d)16:37
Alban[m]Any idea what could be causing this re-ordering?16:37
Alban[m]Could it be that some dictionary is in play somewhere? I have python 3.6 and ordered dict as default are from 3.7 on.16:44
RPSchiller: on the autobuilder we run it once at boot up to setup those devices17:02
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)17:03
RPAlban[m]: That looks like a display issue, it isn't the real difference17:03
RPAlban[m]: was hopefully fixed in https://git.yoctoproject.org/poky/commit/bitbake/lib/bb/siggen.py?id=72e03d8a91fab9d774abb577c6620d1bb59ae69f17:04
rburtonRP: my ci job has hung, if only bitbake would tell me what jobs are still running after five minute of no output17:04
RPrburton: you'll soon know ;-)17:05
Alban[m]I see, then there is only differences in the "Hash for dependent task" 😕17:06
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection)17:06
*** mckoan is now known as mckoan|away17:16
RPAlban[m]: have a look at the difference in the dependent task then?17:16
Alban[m]I'm looking at that, but wouldn't that be tasks that depend on the one I was looking at?17:17
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)17:18
RPAlban[m]: no, it works the other way17:18
Alban[m]the wording is quiet confusing17:19
RPAlban[m]: now you mention that, the wording is not great :/17:19
RPAlban[m]: I've never noticed that before17:19
Alban[m]it's like tx/rx it often get difficult to understand what direction is really meant17:20
*** wmat[m] <wmat[m]!~wmatmatri@2001:470:69fc:105::1:38e6> has joined #yocto17:21
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto17:21
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Read error: Connection reset by peer)17:22
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto17:23
RPAlban[m]: I proposed a fix: https://lists.openembedded.org/g/bitbake-devel/message/1349617:25
Alban[m]That would be much better 🙂17:26
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)17:28
Alban[m]I'm hitting some empty files in tmp/stamps, is that to be expected?17:28
*** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has joined #yocto17:32
RPAlban[m]: if they're the stamp files themselves, yes17:35
*** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed)17:38
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Ping timeout: 256 seconds)17:40
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto17:44
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)17:46
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto17:46
kevinrowlandWhat happens internally if I use `_append` and `+=` in the same assignment? E.g. `IMAGE_INSTALL_append += "python3"`. That feels like a slick way to follow the recommendation to use `IMAGE_INSTALL_append = " python3"`, where the space before the variable is mandatory.17:47
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)17:49
qschulzkevinrowland: this is not allowed anymore and will fail checks17:49
qschulzbut yes, that was the observed behavior17:49
qschulzbasically the += applies to _append operator17:50
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:50
kevinrowlandHa shoot, ok. Any idea why it was nixed? Seems to pass checks in Hardknott, is that a restriction in newer one?17:50
qschulzhttps://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf for some info (though not much is given on _append + +=17:50
qschulzkevinrowland: restriction in kirkstone and later17:51
qschulzso just master branch for now17:51
qschulzit was removed because _append += was never intended to be supported and it's also super confusing17:51
qschulzbecause it implies you can "add" to existing _append but that is absolutely not how it works17:51
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto17:51
qschulzeach _append is isolated, and you can't do operations on an _append or its content (except doing a _remove)17:52
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)17:54
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:c329:5a78:19e:dafb> has quit IRC (Remote host closed the connection)18:02
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving)18:03
Alban[m]I have 2 workspace side by side, with shared sstate dir, the same layers and the same local.conf. After building in the first one I would expect the second workspace to be able to  pull everything from the sstates, right?18:17
landgrafRP: BB_SERVER_TIMEOUT issue... if devtool.DevtoolUpgradeTests.test_devtool_upgrade_git triggered after devtool.DevtoolUpgradeTests.test_devtool_upgrade it failed (do_fetch/unpack/patch not triggered for some reason), if devtool.DevtoolUpgradeTests.test_devtool_upgrade_git is triggered *without* previous devtool.DevtoolUpgradeTests.test_devtool_upgrade it works just fine. I guess the server "thinks"18:32
landgrafdo_fetch for test_devtool_upgrade_git is not needed to be re-executed. Do you have some hints where can be this logic?18:32
landgrafRP: without TIMEOUT server restarts between tests and everything works18:33
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 268 seconds)18:35
*** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has joined #yocto18:47
*** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed)18:57
rburtonAlban[m]: yes18:58
*** Schiller <Schiller!~Schiller@p200300efa709a0011d76477b2ae9e77a.dip0.t-ipconnect.de> has joined #yocto19:07
*** Schiller <Schiller!~Schiller@p200300efa709a0011d76477b2ae9e77a.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed)19:18
sakomanLooking for a little debug help!  I've added a recipe for an out of tree kernel module (patterned after the sample in meta-skeleton) and added kernel-module-foo to MACHINE_ESSENTIAL_EXTRA_RDEPENDS19:36
sakomanOn machine A (Ubuntu 20.04) the recipe builds without error, the kernel-module-foo package is added to the image and it works as expected19:37
sakomanOn machine B (also Ubuntu 20.04) the recipe builds without error, but do_rootfs fails with:19:38
sakomanThe following packages have unmet dependencies:19:38
sakoman packagegroup-core-boot : Depends: kernel-module-foo19:38
sakomanE: Unable to correct problems, you have held broken packages.19:38
sakomanUsing debian packaging, checking in deploy/deb on both machines shows the same .deb packages for the module, with identical sizes19:39
sakomanAny hints on how to debug this?  Not seeing any clues in the logs :-(19:40
sakomanAnd to add to the mystery, trying a different MACHINE works as expected when building on either A or B19:42
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection)19:58
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)20:30
zeddiisakoman, I think sgw was mentioning something like this earlier. something with a kernel-image depend.20:36
*** florian__ <florian__!~florian@> has quit IRC (Ping timeout: 256 seconds)20:45
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:39a3:f627:7e38:45ce> has joined #yocto20:56
*** florian__ <florian__!~florian@> has joined #yocto20:57
RPlandgraf: tracking it down to a specific two test cases like that is extremely helpful. I don't have any specific hints about what may be wrong. There is a lot of caching in bitbake so I suspect one of these caches must not be being reset properly21:10
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto21:11
RPsakoman: are both sharing sstate or anything like that?21:13
sakomanRP: no, nothing shared between machines A and B21:30
*** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has quit IRC (Quit: Ping timeout (120 seconds))21:31
sakomanRP:  also rm'd the tmp dir on both and rebuilt -- same result21:31
sgwsakoman: this sounds different than what I was finding, my finding was for Intel and after further investigations MACHINE_FEATURES with efi enabled have an RDEPENDS on "kernel" where other MACHINEs without EFI get some default dependency (which I have not found where yet) for "kernel-<ver>".21:31
sakomansgw: yeah, sounds completely different!21:32
sgwsakoman: another thing to look for is -dbg packages being installed with .debug .ko files21:32
sgwbut again it sounds different, unless you have more details error logs21:33
sakomansgw: the dbg.deb's in deploy/deb on both machines are the same21:34
sgware they being installed?21:35
sakomansgw: no, I don't see any evidence of any dbg.deb's being installed21:37
sgwThen probably different issue21:37
sakomansgw: the only obvious difference between the A and B build machines is that A has an Intel processor and B an AMD processor ;-)21:39
sakomansgw: I may do a build from scratch on B just to make sure it isn't a sstate corruption issue21:40
RPsakoman: which release?21:41
sakomanRP: dunfell21:41
RPsakoman: it is odd and would be nice to get to the bottom of. Can you do a diffoscope between the two sets of debs, see where any difference is arising ?21:41
sakomanRP: sure I can try that21:42
RPsakoman: or just compare them. Something has to be different21:43
*** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has joined #yocto21:44
*** goliath <goliath!~goliath@user/goliath> has joined #yocto21:55
sakomanRP: there is a difference - on the passing machine the git tag in the kernel-module.deb filename matches all of the other kernel-module.debs. On the failing machine the git tag in the filename for the new module is different than all the others, so that is why it is failing21:55
*** florian__ <florian__!~florian@> has quit IRC (Ping timeout: 240 seconds)22:01
sakomanGives me a thread to pull on.  I just realized that there was one other difference -- build machine B inherits rm_work22:02
*** florian__ <florian__!~florian@> has joined #yocto22:03
RPsakoman: may or may not be related to rm_work but I think you follow that filename thread22:07
sakomanRP: yup, that is a good clue22:08
sakomanRP: starting with no sstate just to see if it will reproduce22:08
*** florian__ <florian__!~florian@> has quit IRC (Ping timeout: 240 seconds)22:16
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)22:16
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)22:36
Alban[m]Regarding my sstate problem I was able to narrow it down on my first workspace, it seems that the sstate computed before running the task doesn't match with what it is later. With some debug in sstate_checkhashes() I see the "missing" sstate, for example:22:41
Alban[m]Missed /builder/workdir/openembedded-core/meta/recipes-support/gnutls/gnutls_3.7.2.bb:do_populate_lic: /builder/sstate-cache/e7/5b/sstate:gnutls::3.7.2:r0::3:e75b40c862a6d42f517f7abf9c770194c14f272fb55a6463f5da80776773c30a_populate_lic.tgz22:41
RPAlban[m]: do you have hash equivalence enabled?22:42
Alban[m]But when I look in this file after the build it contains another hash:22:42
Alban[m]bitbake-dumpsig /builder/sstate-cache/b7/1e/sstate:gnutls:core2-64-aerq-linux:3.7.2:r0:core2-64:3:b71e34f368685ceada267c5c426d3a1e03b4c2fa205edc0b9ee28a588613b47b_packagedata.tgz.siginfo | tail -n 122:42
Alban[m]Computed task hash is 597bfe8be9a4cbd71aa8a607afc96f849c3f74657c234a453991d8e99883bc7d22:42
Alban[m]I think so22:42
Alban[m]Is it that broken?22:42
RPAlban[m]: if you share sstate between builds you also have to share hash equivlance data22:43
Alban[m]597bfe8b... is the hash that the second workspace search and then doesn't find ☹️22:43
Alban[m]but the sstate is written at the wrong place, the file b71e34f3... contains the data for 597bfe8b...22:44
RPAlban[m]: it is hash equivalence making a mess22:46
RPor I suspect so anyway. Either try disabling hash equivalence, or sharing the hash equivalence between the builds22:46
Alban[m]My distro has BB_HASHSERVE ??= "auto"22:46
RPwhich will be local to each build22:46
RPwe need to make this issue more discoverable somehow :/22:47
sakomanRP: building with no sstate and no rm_work on build machine B succeeds, now to try no sstate and with rm_work22:50
Alban[m]still the sstate is broken as some file contain a different data that the hash from the path22:50
RPsakoman: I suspect rm_work could remove something which breaks the module version used somehow :/22:50
Alban[m]even if they are supposed to be equivalent it is still badly inconsistent data22:51
sakomanRP: I'll keep trying to reproduce22:51
RPAlban[m]: it gets complicated and isn't simple as you think :(22:51
Alban[m]well my second workspace lookup a hash that exists but is stored under another one22:52
Alban[m]and my first workspace also return this hash after the build22:53
RPAlban[m]: I'm tired, stressed, overworked and really don't want to get into a discussion about whether it is right or wrong22:53
Alban[m]just before the build the forst workspace somehow see a different hash22:53
RPAlban[m]: I've tried to explain what I suspect is causing your problem and I'm sorry you've hit it, I think we do need to better document and expose it somehow22:53
Alban[m]right, thank you for the help22:54
RPtrying to add new features to a well established system like sstate is hard and you're finding a glitch in the periphery of it. If we had a team of people to work on it, we could likely do better but we have me and someone else doing our best22:55
Alban[m]don't worry I do appreciate. btw I disabled hash equivalence and now my first workspace use the right hash from the start22:58
*** GillesM <GillesM!~gilles@> has quit IRC (Quit: Leaving)23:34
*** GillesM <GillesM!~gilles@> has joined #yocto23:34
*** GillesM <GillesM!~gilles@> has quit IRC (Client Quit)23:35
armpitsmurray: you have anything to do with CVE-2022-24595?23:35
*** AustrianCurrent <AustrianCurrent!~AustrianC@c-73-133-243-111.hsd1.md.comcast.net> has joined #yocto23:37
smurrayarmpit: heh, first I'm hearing of it.  There's a good chance it could become my problem if someone from IoT.bzh doesn't pop up to fix it.23:38
smurrayarmpit: all the afb* stuff has been dropped from the upcoming release of AGL, and it's quite unclear if anyone uses it in a product (I wouldn't ;) )23:39
AustrianCurrentQuestion: Is this an appropriate place to ask a question about Yocto as a user, or is this an internal development chat? Sorry for the possible spam.23:40
moto-timoAustrianCurrent: just ask. It’s free for all. Although we do hope you will do your own homework/footwork and not expect us to be unpaid consultants.23:47

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