| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 00:13 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Client Quit) | 00:14 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 00: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 #yocto | 00: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 #yocto | 00: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 #yocto | 00: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 #yocto | 00:48 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 00:53 | |
| khem | RP seeing peudo fetch errors with master-next | 00:54 |
|---|---|---|
| khem | pseudo-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/pseudo | 00:54 |
| *** tcdiem <tcdiem!~tcdiem@ppp-188-174-62-170.dynamic.mnet-online.de> has quit IRC (Ping timeout: 252 seconds) | 00:55 | |
| khem | RP see https://git.yoctoproject.org/poky-contrib/commit/?h=kraj/poky-next&id=3a1d7992c079a727fc4d3340c5372a0467b8723c | 01:00 |
| khem | :) | 01:00 |
| khem | sielicki 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 kirkstone | 01:08 |
| khem | Xilinix does not support dunfell ? thats a bummer, I was not expecting that but then I dont expect too much these days | 01:09 |
| khem | I 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 chips | 01:10 |
| sielicki | nah, 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,77383753 | 01:10 |
| khem | yes thats perhaps fine as dunfell was first LTS, I hope they are on board with kirkstone | 01:12 |
| sielicki | what'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 |
| sielicki | Here'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 |
| khem | I 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 products | 01:14 |
| sielicki | the 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 |
| khem | oh wow, get your act together I must say | 01:17 |
| sielicki | yeah | 01:18 |
| *** tcdiem <tcdiem!~tcdiem@ppp-188-174-87-254.dynamic.mnet-online.de> has joined #yocto | 01:18 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:37 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 01:53 | |
| *** dacav <dacav!~dacav@h94-245-9-200.cust.a3fiber.se> has joined #yocto | 01: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 #yocto | 02:18 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 250 seconds) | 02:18 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:23 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 252 seconds) | 02:30 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:32 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-94-67-133-210.home.otenet.gr> has joined #yocto | 02: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@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:35 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 268 seconds) | 02:42 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 02:43 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:45 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:48 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:53 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:58 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> 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@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:08 | |
| *** michalkotyla_ <michalkotyla_!~quassel@84-10-27-202.static.chello.pl> has joined #yocto | 03:10 | |
| *** otavio <otavio!~otavio@201-3-135-79.paemt705.dsl.brasiltelecom.net.br> has joined #yocto | 03:10 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 03: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 #yocto | 03:11 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.198.182.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 250 seconds) | 03:17 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.133.76.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:24 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.133.76.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 03:31 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.133.76.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:36 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds) | 03:43 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.133.76.dynamic-pppoe.dt.ipv4.wtnet.de> 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 #yocto | 03:51 | |
| *** jclsn73 <jclsn73!~jclsn@149.233.133.76.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:53 | |
| *** amitk <amitk!~amit@103.59.74.159> has joined #yocto | 04: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 #yocto | 04: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 #yocto | 05: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 #yocto | 05:37 | |
| *** frieder <frieder!~frieder@i59F4B31D.versanet.de> has joined #yocto | 05:56 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:56 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 05:58 | |
| moto-timo | JaMa: https://github.com/moto-timo/meta-ros/tree/kirkstone (WIP) | 05:59 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:03 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340:cfbf:d57d:b0f7:eb51> has quit IRC (Ping timeout: 240 seconds) | 06:07 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:08 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340:cfbf:d57d:b0f7:eb51> has joined #yocto | 06: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 #yocto | 07:04 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:04 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:07 | |
| *** jclsn73 is now known as jclsn | 07:12 | |
| jclsn | clear | 07:12 |
| jclsn | Ups no terminal haha | 07:12 |
| jclsn | Morning | 07:13 |
| jclsn | qschulz: 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/DC53BDVH | 07:19 |
| jclsn | If 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 zsh | 07:19 |
| cb5r | What's the way to enable LTO for only one recipe? | 07:20 |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 07:21 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto | 07:27 | |
| jclsn | cb5r: LTO? | 07:29 |
| cb5r | LinkTimeOptimization | 07:30 |
| *** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 07:31 | |
| jclsn | Hmm no idea | 07:32 |
| cb5r | I 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 time | 07:32 |
| cb5r | I think I should be fine optimizing only a few components | 07:33 |
| *** mckoan|away is now known as mckoan | 07:41 | |
| mckoan | good morning | 07:42 |
| *** davidinux <davidinux!~davidinux@138.199.54.233> has quit IRC (Ping timeout: 252 seconds) | 07:45 | |
| *** davidinux <davidinux!~davidinux@82.102.21.198> has joined #yocto | 07: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 #yocto | 07:59 | |
| *** florian__ <florian__!~florian@dynamic-078-048-128-255.78.48.pool.telefonica.de> has joined #yocto | 08:00 | |
| *** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has joined #yocto | 08:04 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08:15 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 08:23 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 268 seconds) | 08:24 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:26 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:26 | |
| *** vladest <vladest!~Thunderbi@81-229-209-18-no288.tbcn.telia.com> has quit IRC (Quit: vladest) | 08:27 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 08:27 | |
| *** vladest <vladest!~Thunderbi@81-229-209-18-no288.tbcn.telia.com> has joined #yocto | 08:28 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 08:40 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 08:41 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:41 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 08:44 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 08:48 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 08:48 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:49 | |
| qschulz | mornin | 08:49 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 08:52 | |
| *** Schiller <Schiller!~Schiller@p200300efa709a001d9499e31e9cd6eaa.dip0.t-ipconnect.de> has joined #yocto | 08:55 | |
| Schiller | Hello 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 you | 09:02 |
| Schiller | because 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 #yocto | 09:08 | |
| Schiller | Hello 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 #yocto | 09: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 #yocto | 09:17 | |
| rburton | Schiller: there's a few people here who know about it, but it's best if you explain what your problem is | 09:31 |
| Schiller | Thank 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 #yocto | 09:40 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 09:49 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 09:52 | |
| *** camus1 is now known as camus | 09:52 | |
| qschulz | Schiller: we're all ears, please ask your questions | 09:53 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 09:54 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 09:55 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 09:56 | |
| *** camus1 is now known as camus | 09:56 | |
| Schiller | When 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't | 09:57 |
| Schiller | even 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.md | 09:57 |
| GillesM | Hello cant iI runqemu without network ... I tried runqemu qemux86 qemuparams="-nic none" without success | 10: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 #yocto | 10:35 | |
| landgraf | GillesM: adding -nodefaults might help. | 10:42 |
| Schiller | I'm new to this hole framework. Is my question understandable? Also not a native speaker. | 10:51 |
| RP | qschulz: 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 #yocto | 10:55 | |
| RP | Schiller: I think that the code has changed a bit since the README you refer to was written | 10:57 |
| RP | Schiller: The code now supports "dynamic" build steps the json code in yocto-autobuilder-helper can dynamically set how many steps are needed | 10:58 |
| RP | Schiller: for the beaglebone you mentioned, it is declared here: https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n275 | 10: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 #yocto | 11:05 | |
| qschulz | RP: it did, thank you very much for sending a v2 of all patches in one thread :) I'll get to the review this afternoon | 11:06 |
| *** starblue <starblue!~juergen@dslb-094-221-191-054.094.221.pools.vodafone-ip.de> has joined #yocto | 11:06 | |
| rburton | RP: do you have an opinion on the timeout question in JaMa's reply to my bitbake patch? | 11:07 |
| RP | rburton: happy to have it be 10 mins | 11:12 |
| RP | rburton: I worry that for long running AB tests we'll see spam but it probably is more useful than not | 11:13 |
| rburton | lets see how spammy it is with a 10 minute cycle | 11:13 |
| RP | qschulz: I thought it might help make things clearer (the autobuilder-helper and transition branch patches aren't there) | 11:14 |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 11:20 | |
| *** mabnhdev2 <mabnhdev2!~mabnhdev2@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has joined #yocto | 11:23 | |
| mabnhdev2 | Hi, 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 |
| rburton | mabnhdev2: 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 |
| rburton | the 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 |
| mabnhdev2 | rburton That war has already been fought and lost - https://github.com/jaraco/skeleton/issues/1 | 11:28 |
| rburton | :facepalm: | 11:29 |
| rburton | in that case just set the license checksum to eg specifically line 11 of setup.cfg | 11:31 |
| rburton | by setting LICENSE to MIT you get the full canonical license text in the license data we generate already | 11:31 |
| mabnhdev2 | rburton 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 |
| rburton | meta/recipes-core/musl/bsd-headers.bb:LIC_FILES_CHKSUM = "file://sys-queue.h;beginline=1;endline=32;md5=c6352b0f03bb448600456547d334b56f" | 11:32 |
| mabnhdev2 | rburton Cool. Thanks! | 11:32 |
| rburton | or more relevantly for python code | 11:32 |
| rburton | meta/recipes-devtools/python/python3-setuptools-scm_6.4.2.bb:LIC_FILES_CHKSUM = "file://PKG-INFO;beginline=8;endline=8;md5=8227180126797a0148f94f483f3e1489 | 11:32 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 11:41 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 11:42 | |
| rburton | RP: 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 #yocto | 11:55 | |
| RP | rburton: not sure. That is annoying | 11:58 |
| rburton | three out of nearly 10k fetches | 12:03 |
| rburton | final 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 #yocto | 12:03 | |
| RP | rburton: shame we don't know how it failed :/ | 12:15 |
| rburton | i think i just got our CI to archive the build logs | 12:15 |
| rburton | so will see if it happens again | 12:15 |
| cb5r | If 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 |
| rburton | cb5r: it will always work | 12:15 |
| rburton | the only way it can use the "wrong" source is if eg bash-4.0.tar.gz has changed contents | 12:16 |
| rburton | if that has happened, you've bigger problems | 12:16 |
| cb5r | rburton: ...which basically only should happen if I manually modify it? | 12:16 |
| rburton | you're absolutely encouraged to share DL_DIR and SSTATE_DIR between all builds and all versions | 12:17 |
| rburton | well upstream could change the content without changing the version | 12:17 |
| cb5r | True... | 12:17 |
| rburton | again, bigger problems: is that a sneaky fix, or is that a backdoor | 12:17 |
| rburton | the checksums will fail | 12:17 |
| cb5r | OK great - I shall share DL_DIR and SSTATE_DIR in the future then - thanks! | 12:18 |
| rburton | when 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_DIR | 12:18 |
| cb5r | Are 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 |
| rburton | they're fetched occasionally so high speed isn't critical | 12:21 |
| rburton | you can put the build dir in a tmpfs if you have enough RAM, yes | 12:21 |
| rburton | you'll want rm_work to keep usage low | 12:21 |
| cb5r | I am trying to optimize my partitions/mounts/shares/whatever here currently, since I am working with different VMs etc. So sharing would be pretty cool | 12:21 |
| cb5r | whats rm_work? | 12:22 |
| cb5r | this? https://git.yoctoproject.org/poky/plain/meta/classes/rm_work.bbclass | 12:24 |
| rburton | yes | 12:25 |
| rburton | no point keeping 10gb of build tree in ram when its not needed anymore | 12: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 #yocto | 12:34 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 12:38 | |
| cb5r | Thats true. - But if the build fails, my "cache" is gone - so everything needs to be compiled from scratch - right? | 12:46 |
| marc3 | nope, there's a difference between the 'work' and the 'shared-state cache' | 12:50 |
| marc3 | See: https://docs.yoctoproject.org/overview-manual/concepts.html#shared-state-cache | 12:52 |
| *** mabnhdev2 <mabnhdev2!~mabnhdev2@162-224-117-232.lightspeed.rlghnc.sbcglobal.net> has quit IRC (Quit: Client closed) | 12:55 | |
| *** BobPungartnik <BobPungartnik!~Pung@177.41.200.154> has joined #yocto | 12:57 | |
| *** BobPungartnik <BobPungartnik!~Pung@177.41.200.154> 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 | |
| cb5r | OK, 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 SIGILL | 13:12 |
| rburton | illegal instruction: your compiler tune/etc doesn't actually match the hardware | 13:15 |
| rburton | dmesg will tell you what the instruction is, but tell us what MACHINE and what hardware and it might be obvious | 13:15 |
| *** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 13:16 | |
| rburton | RP: 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 rootfs | 13:17 |
| rburton | is 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-gcc | 13:19 |
| rburton | <shrugs>. you're getting illegal instruction, so your compiler tune flags are wrong | 13:20 |
| hmw[m] | ( running the sdk on x86 | 13:20 |
| rburton | dmesg will tell you what the instruction is, or run it in gdb and let that catch it to tell you where | 13:20 |
| rburton | could be some dumb code making assumptions like 'yes of course i have <some instruction>' which you don't have | 13:20 |
| rburton | like how last month I upgraded uboot and it assumes that CRC instructions are present, but they're optional. | 13:21 |
| rburton | suddenly, it didn't boot | 13:21 |
| hmw[m] | m tnx seems like i don´t have qtsql package | 13:23 |
| hmw[m] | on rootfs | 13:23 |
| hmw[m] | that is not a package :( | 13:27 |
| RP | rburton: nice to have that sorted :) | 13:27 |
| rburton | one more down! | 13:31 |
| mckoan | . | 13:39 |
| *** 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@78.48.128.255> has joined #yocto | 13:39 | |
| qschulz | hmw[m]: oe-pkgdata-util find-path '*sql*' to find which package to install | 13:39 |
| qschulz | hmw[m]: if the recipe building the package has been baked | 13:40 |
| Schiller | when 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 |
| Schiller | seems 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.cpp | 13:50 |
| hmw[m] | so it should be in ? | 13:50 |
| qschulz | hmw[m]: didn't understand your message sorry | 13:52 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13: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.h | 13:56 |
| hmw[m] | than that that "package" is installed ? | 13:56 |
| qschulz | no | 13:56 |
| qschulz | it returns which file belongs to which package | 13:56 |
| qschulz | here /usr/src/debug/qtbase/5.14.2+gitAUTOINC+3a6d8df521-r0.arago17/git/src/sql/kernel/qsqldriver.h belongs to qtbase-src package | 13:56 |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 13:57 | |
| qschulz | hmw[m]: also, don't grep for qt,since I think the file you're looking for is probably qsql and not qtsql | 13:57 |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 13:59 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 14:00 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 14:02 | |
| RP | qschulz: 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 #yocto | 14:12 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 252 seconds) | 14:16 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 14:16 | |
| moto-timo | hmw[m]: you need to add the PACKAGECONFIG https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase_git.bb#L120 | 14:16 |
| moto-timo | hmw[m]: MySQL support is not included in the default | 14:17 |
| *** yolo <yolo!~xxiao@li1120-73.members.linode.com> has joined #yocto | 14:17 | |
| yolo | is usrmerge enabled by default in new yocto or oe-core these days | 14: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#n247 | 14:22 |
| RP | yolo: no | 14:22 |
| qschulz | hmw[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 |
| sgw | Morning all | 14:24 |
| qschulz | o/ | 14:25 |
| *** 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 | |
| sgw | s/my most/why most/ | 14:27 |
| RP | sgw: no idea FWIW | 14:27 |
| sgw | RP: 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 |
| LetoThe2nd | yo dudX | 14:30 |
| mckoan | LetoThe2nd: hear! hear! the jester is back with us! | 14:34 |
| LetoThe2nd | mckoan: yeah... i would have loved to not be "away" | 14:34 |
| mckoan | LetoThe2nd: I am pleased to note that you have to work now, LOL | 14:35 |
| yolo | RP: how to enable that? google did not show anything, mega-manual does not mention it either, is it 'ready' for use | 14:37 |
| yolo | DISTRO_FEATURES_append = " usrmerge" -- is this it | 14:38 |
| hmw[m] | <qschulz> "hmw: create a bbappend for..." <- tnx apparently i did do that already. still finde the SIGILL strange | 14:41 |
| qschulz | yolo: seems about right (might be :append if you are on honister or master branch) | 14:41 |
| qschulz | hmw[m]: are you sure the package with the appropriate file is installed in your image? | 14:41 |
| yolo | qschulz: thanks! | 14:46 |
| RP | yolo: probably DISTRO_FEATURES:append = " usrmerge" | 14:47 |
| RP | heh, qschulz beat me to it | 14:47 |
| yolo | cool, building and testing now | 14:47 |
| hmw[m] | qschulz: no but If I ask for opkg info qtbase it shows that that is installed | 14: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-only | 14:48 | |
| yolo | all scripts default to install to /usr/local but to have /usr read-only is worth that change IMHO | 14: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 | |
| qschulz | RP: adding tags? but that's cheating :D | 15:08 |
| *** frieder <frieder!~frieder@i59F4B31D.versanet.de> has quit IRC (Remote host closed the connection) | 15:10 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.179> has quit IRC (Ping timeout: 240 seconds) | 15:12 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.179> has joined #yocto | 15:15 | |
| hmw[m] | <qschulz> "hmw: are you sure the package..." <- find /usr/ -iname "*qsql*" | 15:16 |
| hmw[m] | /usr/lib/plugins/sqldrivers/libqsqlmysql.so | 15:16 |
| hmw[m] | /usr/lib/plugins/sqldrivers/libqsqlite.so | 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 #yocto | 15: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 #yocto | 15: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 #yocto | 15:25 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.188.152> has joined #yocto | 15:26 | |
| *** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has joined #yocto | 15:26 | |
| *** creich <creich!~creich@p200300f6af1194100000000000000100.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds) | 15:27 | |
| *** Tokamak <Tokamak!~Tokamak@107.116.82.179> has quit IRC (Ping timeout: 240 seconds) | 15:27 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 15:28 | |
| Schiller | in 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 |
| rburton | RP: good news! my little patch to openssl has exploded their ci. by good i mean terrible. | 15:31 |
| RP | Schiller: you don't need root. Just run runqemu-gen-tapdevs to setup the tap devices on the worker | 15:32 |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds) | 15:32 | |
| *** Tokamak <Tokamak!~Tokamak@166.205.152.100> has joined #yocto | 15:32 | |
| *** Tokamak_ <Tokamak_!~Tokamak@172.58.188.152> has quit IRC (Ping timeout: 240 seconds) | 15:33 | |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 15:36 | |
| Schiller | do you mean this shell-script https://github.com/openembedded/openembedded-core/blob/master/scripts/runqemu-gen-tapdevs within the yocto-worker? | 15:37 |
| RP | rburton: oops, or do I mean congrats :) | 15:39 |
| RP | Schiller: yes | 15:39 |
| RP | Schiller: that script allows the tap devices to be setup in advance removing the need for root access anywhere ele | 15:40 |
| RP | else | 15:40 |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 15:40 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 252 seconds) | 15:44 | |
| Schiller | ik. stupid question but what exactly is a tap device (because i have to input a number). | 15:44 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 15:45 | |
| RP | Schiller: it is basically like a network interface. How many images might you run in parallel | 15:45 |
| Schiller | k thx | 15:45 |
| *** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has quit IRC (Quit: Connection closed) | 15:47 | |
| Schiller | is 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 |
| RP | Alban[m]: http if you're ok with read only | 15: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 | |
| Schiller | i 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 #yocto | 16:20 | |
| *** amitk <amitk!~amit@103.59.74.159> 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 |
| RP | Schiller: on the autobuilder we run it once at boot up to setup those devices | 17:02 |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 17:03 | |
| RP | Alban[m]: That looks like a display issue, it isn't the real difference | 17:03 |
| RP | Alban[m]: was hopefully fixed in https://git.yoctoproject.org/poky/commit/bitbake/lib/bb/siggen.py?id=72e03d8a91fab9d774abb577c6620d1bb59ae69f | 17:04 |
| rburton | RP: my ci job has hung, if only bitbake would tell me what jobs are still running after five minute of no output | 17:04 |
| RP | rburton: 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|away | 17:16 | |
| RP | Alban[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 | |
| RP | Alban[m]: no, it works the other way | 17:18 |
| Alban[m] | the wording is quiet confusing | 17:19 |
| RP | Alban[m]: now you mention that, the wording is not great :/ | 17:19 |
| RP | Alban[m]: I've never noticed that before | 17:19 |
| Alban[m] | it's like tx/rx it often get difficult to understand what direction is really meant | 17:20 |
| *** wmat[m] <wmat[m]!~wmatmatri@2001:470:69fc:105::1:38e6> has joined #yocto | 17:21 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has joined #yocto | 17: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 #yocto | 17:23 | |
| RP | Alban[m]: I proposed a fix: https://lists.openembedded.org/g/bitbake-devel/message/13496 | 17: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 #yocto | 17:32 | |
| RP | Alban[m]: if they're the stamp files themselves, yes | 17:35 |
| *** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed) | 17:38 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has quit IRC (Ping timeout: 256 seconds) | 17:40 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has joined #yocto | 17:44 | |
| *** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 17:46 | |
| *** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 17:46 | |
| kevinrowland | What 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@166.205.152.100> has quit IRC (Ping timeout: 240 seconds) | 17:49 | |
| qschulz | kevinrowland: this is not allowed anymore and will fail checks | 17:49 |
| qschulz | but yes, that was the observed behavior | 17:49 |
| qschulz | basically the += applies to _append operator | 17:50 |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.127> has joined #yocto | 17:50 | |
| kevinrowland | Ha shoot, ok. Any idea why it was nixed? Seems to pass checks in Hardknott, is that a restriction in newer one? | 17:50 |
| qschulz | https://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 |
| qschulz | kevinrowland: restriction in kirkstone and later | 17:51 |
| qschulz | so just master branch for now | 17:51 |
| qschulz | it was removed because _append += was never intended to be supported and it's also super confusing | 17:51 |
| qschulz | because it implies you can "add" to existing _append but that is absolutely not how it works | 17:51 |
| *** Tokamak_ <Tokamak_!~Tokamak@107.116.82.163> has joined #yocto | 17:51 | |
| qschulz | each _append is isolated, and you can't do operations on an _append or its content (except doing a _remove) | 17:52 |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.127> 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 |
| landgraf | RP: 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 |
| landgraf | do_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 |
| landgraf | RP: without TIMEOUT server restarts between tests and everything works | 18:33 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Ping timeout: 268 seconds) | 18:35 | |
| *** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has joined #yocto | 18:47 | |
| *** Schiller <Schiller!~Schiller@p200300efa709a001e4ca54823b002628.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed) | 18:57 | |
| rburton | Alban[m]: yes | 18:58 |
| *** Schiller <Schiller!~Schiller@p200300efa709a0011d76477b2ae9e77a.dip0.t-ipconnect.de> has joined #yocto | 19:07 | |
| *** Schiller <Schiller!~Schiller@p200300efa709a0011d76477b2ae9e77a.dip0.t-ipconnect.de> has quit IRC (Quit: Client closed) | 19:18 | |
| sakoman | Looking 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_RDEPENDS | 19:36 |
| sakoman | On machine A (Ubuntu 20.04) the recipe builds without error, the kernel-module-foo package is added to the image and it works as expected | 19:37 |
| sakoman | On machine B (also Ubuntu 20.04) the recipe builds without error, but do_rootfs fails with: | 19:38 |
| sakoman | The following packages have unmet dependencies: | 19:38 |
| sakoman | packagegroup-core-boot : Depends: kernel-module-foo | 19:38 |
| sakoman | E: Unable to correct problems, you have held broken packages. | 19:38 |
| sakoman | Using debian packaging, checking in deploy/deb on both machines shows the same .deb packages for the module, with identical sizes | 19:39 |
| sakoman | Any hints on how to debug this? Not seeing any clues in the logs :-( | 19:40 |
| sakoman | And to add to the mystery, trying a different MACHINE works as expected when building on either A or B | 19: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 | |
| zeddii | sakoman, I think sgw was mentioning something like this earlier. something with a kernel-image depend. | 20:36 |
| *** florian__ <florian__!~florian@78.48.128.255> has quit IRC (Ping timeout: 256 seconds) | 20:45 | |
| *** Guest79 <Guest79!~Guest79@2601:644:8102:f530:39a3:f627:7e38:45ce> has joined #yocto | 20:56 | |
| *** florian__ <florian__!~florian@78.48.128.255> has joined #yocto | 20:57 | |
| RP | landgraf: 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 properly | 21:10 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 21:11 | |
| RP | sakoman: are both sharing sstate or anything like that? | 21:13 |
| sakoman | RP: no, nothing shared between machines A and B | 21:30 |
| *** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 21:31 | |
| sakoman | RP: also rm'd the tmp dir on both and rebuilt -- same result | 21:31 |
| sgw | sakoman: 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 |
| sakoman | sgw: yeah, sounds completely different! | 21:32 |
| sgw | sakoman: another thing to look for is -dbg packages being installed with .debug .ko files | 21:32 |
| sgw | but again it sounds different, unless you have more details error logs | 21:33 |
| sakoman | sgw: the dbg.deb's in deploy/deb on both machines are the same | 21:34 |
| sgw | are they being installed? | 21:35 |
| sakoman | sgw: no, I don't see any evidence of any dbg.deb's being installed | 21:37 |
| sgw | Then probably different issue | 21:37 |
| sakoman | sgw: 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 |
| sakoman | sgw: I may do a build from scratch on B just to make sure it isn't a sstate corruption issue | 21:40 |
| RP | sakoman: which release? | 21:41 |
| sakoman | RP: dunfell | 21:41 |
| RP | sakoman: 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 |
| sakoman | RP: sure I can try that | 21:42 |
| RP | sakoman: or just compare them. Something has to be different | 21:43 |
| *** tcdiem <tcdiem!~tcdiem@ppp-93-104-21-219.dynamic.mnet-online.de> has joined #yocto | 21:44 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 21:55 | |
| sakoman | RP: 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 failing | 21:55 |
| *** florian__ <florian__!~florian@78.48.128.255> has quit IRC (Ping timeout: 240 seconds) | 22:01 | |
| sakoman | Gives me a thread to pull on. I just realized that there was one other difference -- build machine B inherits rm_work | 22:02 |
| *** florian__ <florian__!~florian@78.48.128.255> has joined #yocto | 22:03 | |
| RP | sakoman: may or may not be related to rm_work but I think you follow that filename thread | 22:07 |
| sakoman | RP: yup, that is a good clue | 22:08 |
| sakoman | RP: starting with no sstate just to see if it will reproduce | 22:08 |
| *** florian__ <florian__!~florian@78.48.128.255> has quit IRC (Ping timeout: 240 seconds) | 22:16 | |
| *** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> 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.tgz | 22:41 |
| RP | Alban[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 1 | 22:42 |
| Alban[m] | Computed task hash is 597bfe8be9a4cbd71aa8a607afc96f849c3f74657c234a453991d8e99883bc7d | 22:42 |
| Alban[m] | I think so | 22:42 |
| Alban[m] | Is it that broken? | 22:42 |
| RP | Alban[m]: if you share sstate between builds you also have to share hash equivlance data | 22: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 |
| RP | Alban[m]: it is hash equivalence making a mess | 22:46 |
| RP | or I suspect so anyway. Either try disabling hash equivalence, or sharing the hash equivalence between the builds | 22:46 |
| Alban[m] | My distro has BB_HASHSERVE ??= "auto" | 22:46 |
| RP | which will be local to each build | 22:46 |
| RP | we need to make this issue more discoverable somehow :/ | 22:47 |
| sakoman | RP: building with no sstate and no rm_work on build machine B succeeds, now to try no sstate and with rm_work | 22:50 |
| Alban[m] | still the sstate is broken as some file contain a different data that the hash from the path | 22:50 |
| RP | sakoman: 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 data | 22:51 |
| sakoman | RP: I'll keep trying to reproduce | 22:51 |
| RP | Alban[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 one | 22:52 |
| Alban[m] | and my first workspace also return this hash after the build | 22:53 |
| RP | Alban[m]: I'm tired, stressed, overworked and really don't want to get into a discussion about whether it is right or wrong | 22:53 |
| Alban[m] | just before the build the forst workspace somehow see a different hash | 22:53 |
| RP | Alban[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 somehow | 22:53 |
| Alban[m] | right, thank you for the help | 22:54 |
| RP | trying 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 best | 22: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 start | 22:58 |
| *** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has quit IRC (Quit: Leaving) | 23:34 | |
| *** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has joined #yocto | 23:34 | |
| *** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has quit IRC (Client Quit) | 23:35 | |
| armpit | smurray: 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 #yocto | 23:37 | |
| smurray | armpit: 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 |
| smurray | armpit: 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 |
| AustrianCurrent | Question: 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-timo | AustrianCurrent: 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/!