Friday, 2020-08-21

*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has joined #yocto00:01
*** robbawebba <robbawebba!> has quit IRC00:01
*** paulbarker <paulbarker!sid269702@gateway/web/> has joined #yocto00:01
*** robbawebba <robbawebba!> has joined #yocto00:03
*** geissonator <geissonator!~geissonat@> has quit IRC00:09
*** stacktrust <stacktrust!> has joined #yocto00:11
*** ernstp <ernstp!sid168075@gateway/web/> has quit IRC00:13
*** ernstp <ernstp!sid168075@gateway/web/> has joined #yocto00:16
*** stacktrust <stacktrust!> has quit IRC00:17
*** stacktrust <stacktrust!> has joined #yocto00:19
robbawebbahmm this article seems to be helpful (although what I'm doing is definitely feeling hacky):
*** vineela <vineela!vtummala@nat/intel/x-rlfbbtkcktmijclm> has quit IRC00:21
zeddiikhem: I have a change for that here. will send with my queue tomorrow.00:25
*** sgw <sgw!> has quit IRC00:27
khemthanks zeddii00:27
khemrobbawebba: that article is right, use patchelf to insert the right linker path. usually we distribute nativesdk binaries and they also rewrite ldso path when SDK is installed, this of course happens behind the scene00:29
khemRP: do we still have performance issues on mips ?00:34
robbawebbakhem: thanks for the support once again! It feels wrong trying to skirt around uninative which provides a lot of benefits to the build system and sdk, but I guess this is necessary if I want to avoid distributing the full SDK for a single application.00:34
*** ericch <ericch!> has quit IRC00:35
khemrobbawebba: sure, you will have to create a post processing step anyway so add patchelf step in that00:36
*** geissonator <geissonator!~geissonat@> has joined #yocto00:37
robbawebbakhme: thanks! Another question that came to mind after finding this patch ( is it possible to override or remove the --dynamic-linker flag for a specific recipe? or is this less practical or ineffective compared to the patchelf approach?00:39
*** vineela <vineela!vtummala@nat/intel/x-ivnouytilwrzplcz> has joined #yocto01:04
*** rcw <rcw!~rcw@> has quit IRC01:11
*** vineela <vineela!vtummala@nat/intel/x-ivnouytilwrzplcz> has quit IRC01:18
*** kiwi_29 <kiwi_29!> has quit IRC01:36
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:47
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:48
*** stephano <stephano!> has quit IRC02:27
*** kaspter <kaspter!~Instantbi@> has quit IRC02:35
*** kiwi_29 <kiwi_29!> has joined #yocto02:38
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto02:41
khemrobbawebba: I think for your case you are better of not using uninative02:42
*** gregw <gregw!> has joined #yocto02:51
*** kiwi_29 <kiwi_29!> has quit IRC02:52
*** kiwi_29 <kiwi_29!> has joined #yocto02:53
gregwI'm packaging code with its own complex build-system that requires the `fakeroot` command.  Is there a way to make that available as a host-tool during build commands?  I'm really having trouble searching for a solution (besides "don't").03:01
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:03
khemgregw: you have explore using pseudo which is provided by yocto project to do privilige management like fakeroot03:07
*** kiwi_29 <kiwi_29!> has quit IRC03:08
khemalso see this
*** kiwi_29 <kiwi_29!> has joined #yocto03:11
*** gregw <gregw!> has quit IRC03:11
*** kiwi_29 <kiwi_29!> has quit IRC03:14
*** kiwi_29 <kiwi_29!> has joined #yocto03:15
*** kaspter <kaspter!~Instantbi@> has quit IRC03:26
*** gregw <gregw!> has joined #yocto03:26
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:27
gregwthanks khem - I'm aware that pseudo is the preferred way to acheive this - the issue is that the build system of the package calls `fakeroot` by name deep in its bowels.  Really i just need to satisfy the builder without having to dismantle the build system.03:29
*** kiwi_29 <kiwi_29!> has quit IRC03:30
*** kiwi_29 <kiwi_29!> has joined #yocto03:31
*** khem <khem!~khem@unaffiliated/khem> has quit IRC03:34
*** kiwi_29 <kiwi_29!> has quit IRC03:37
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto03:45
*** matthewzmd <matthewzmd!> has quit IRC04:05
*** stacktrust <stacktrust!> has quit IRC04:20
*** kaspter <kaspter!~Instantbi@> has quit IRC04:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:23
*** stacktrust <stacktrust!> has joined #yocto04:27
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:27
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC04:53
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto04:53
*** paulg <paulg!> has quit IRC05:01
*** feddischson <feddischson!> has joined #yocto05:03
*** gregw <gregw!> has quit IRC05:07
*** sgw <sgw!> has joined #yocto05:15
*** gtristan <gtristan!~tristanva@> has quit IRC05:17
*** camus1 <camus1!~Instantbi@> has joined #yocto05:27
*** kaspter <kaspter!~Instantbi@> has quit IRC05:29
*** camus1 is now known as kaspter05:29
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto05:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC05:35
*** camus1 <camus1!~Instantbi@> has joined #yocto05:37
*** kaspter <kaspter!~Instantbi@> has quit IRC05:38
*** camus1 is now known as kaspter05:38
*** zandrey <zandrey!> has quit IRC05:41
*** ada91 <ada91!cb7e0071@> has joined #yocto05:43
*** ada100 <ada100!cb7e0071@> has joined #yocto05:44
*** jobroe <jobroe!> has joined #yocto05:46
*** minimaxw1ll <minimaxw1ll!> has joined #yocto05:46
*** minimaxwell <minimaxwell!> has quit IRC05:47
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto06:00
*** ibinderwolf <ibinderwolf!> has quit IRC06:08
*** ibinderwolf <ibinderwolf!> has joined #yocto06:10
*** zandrey <zandrey!~zandrey@> has joined #yocto06:17
*** agust <agust!> has joined #yocto06:18
*** goliath <goliath!> has joined #yocto06:18
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:19
*** sgw <sgw!> has quit IRC06:38
*** ant__ <ant__!> has quit IRC06:38
*** pharaon2502 <pharaon2502!> has quit IRC06:38
*** Bunio_FH <Bunio_FH!> has quit IRC06:38
*** dagmcr <dagmcr!sid323878@gateway/web/> has quit IRC06:38
*** junland <junland!~junland@> has quit IRC06:38
*** georgem <georgem!~georgem@> has quit IRC06:38
*** denix <denix!> has quit IRC06:38
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC06:38
*** stew-dw <stew-dw!~stew-dw@> has quit IRC06:38
*** laurittr <laurittr!> has quit IRC06:38
*** woky <woky!> has quit IRC06:38
*** dkc <dkc!> has quit IRC06:38
*** jwessel <jwessel!~jwessel@> has quit IRC06:38
*** dv_ <dv_!> has quit IRC06:38
*** sgw <sgw!> has joined #yocto06:43
*** ant__ <ant__!> has joined #yocto06:43
*** pharaon2502 <pharaon2502!> has joined #yocto06:43
*** Bunio_FH <Bunio_FH!> has joined #yocto06:43
*** dagmcr <dagmcr!sid323878@gateway/web/> has joined #yocto06:43
*** junland <junland!~junland@> has joined #yocto06:43
*** georgem <georgem!~georgem@> has joined #yocto06:43
*** denix <denix!> has joined #yocto06:43
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto06:43
*** stew-dw <stew-dw!~stew-dw@> has joined #yocto06:43
*** laurittr <laurittr!> has joined #yocto06:43
*** woky <woky!> has joined #yocto06:43
*** jwessel <jwessel!~jwessel@> has joined #yocto06:43
*** dv_ <dv_!> has joined #yocto06:43
*** pharaon2502 <pharaon2502!> has quit IRC06:49
*** pharaon2502 <pharaon2502!> has joined #yocto06:50
ada100Are there any documents about how to use meta-virtualization?06:54
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has joined #yocto06:54
*** beneth <beneth!> has joined #yocto06:56
*** dkc <dkc!> has joined #yocto06:59
LetoThe2ndada100: other than probably not.07:00
LetoThe2ndada100: what is not clear?07:01
*** creich <creich!> has quit IRC07:03
ada100LetoThe2nd Yeah, It's not very clear. I have read this readme before.07:04
LetoThe2ndada100: but *what* ist not clear?07:05
LetoThe2ndits just a layer like any other AFAICS07:05
*** chris_ber <chris_ber!~quassel@> has joined #yocto07:05
*** creich <creich!> has joined #yocto07:05
*** sajjad__ <sajjad__!~xtron@> has joined #yocto07:06
ada100LetoThe2nd It's hard to have a clear dependencis. I want to install docker. I built it and found it depend on containerd. And containerd require cni07:07
*** AndersD <AndersD!> has joined #yocto07:08
LetoThe2ndum, so what?07:10
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:10
LetoThe2ndfrom a first peek, the docker dependencies are defined here:
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto07:13
LetoThe2ndplus, the layer dependencies are also properly set up:
ada100LetoThe2nd I am a new to it. So is it enough to specify IMAGE_INSTALL_append = "  docker"  and DISTRO_FEATURES_append = " systemd virtualization " in local.conf? And all of the dependencies will be install automaticlly?07:15
LetoThe2ndhum. close.07:15
ada100LetoThe2nd Got it. I'll have a try. Thank a lot07:16
LetoThe2ndada100: do yourself a favor, watch this: and this and then act accordingly. e.g. create a layer, a custom image, and a custom distro07:17
LetoThe2ndada100: in a nutshell: the build time dependencies will be built automatically, the runtime dependencies will be installed automatically. but do *NOT* do extensive modifications in your local.conf.07:20
*** kaspter <kaspter!~Instantbi@> has quit IRC07:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:21
ada100LetoThe2nd Another question. After building this image and runqemu with it, to start docker service with systemctl. Any is any other configuration needed?07:21
ada100LetoThe2nd I followed this document to build docker.07:22
LetoThe2ndada100: it should be automatically started:
LetoThe2ndada100: just like the wiki page you linked says.07:23
LetoThe2ndada100: and while the page says to work with local.conf, well... its only the half truth. its enough to make it work, but certainly not the way to go if you actually want to use and maintain whatever you built with it.07:25
LetoThe2ndada100: so seriously, getting a grasp of a custom layer/image/distro is absolutely mandatory.07:25
ada100letothe2nd: Yeah, a lot long way to go07:27
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC07:27
LetoThe2ndada100: so i strongly suggest to get an understanding of the basics, before playing with docker :)07:29
*** xtron1 <xtron1!~xtron@> has joined #yocto07:31
ada100LetoThe2nd Sharpen the knife and chop wood. Thanks for your advice.<307:34
*** sajjad__ <sajjad__!~xtron@> has quit IRC07:34
*** kiwi_29 <kiwi_29!> has joined #yocto07:39
*** kiwi_29 <kiwi_29!> has quit IRC07:43
*** fbre <fbre!91fdde45@> has joined #yocto07:44
*** risca <risca!~quassel@> has quit IRC07:50
*** iokill <iokill!> has quit IRC07:50
*** robbawebba <robbawebba!> has quit IRC07:54
*** AndersD <AndersD!> has quit IRC08:01
RPkhem: yes, mips issues basically remain :(08:07
*** Brian90 <Brian90!> has joined #yocto08:17
*** camus1 <camus1!~Instantbi@> has joined #yocto08:20
*** kaspter <kaspter!~Instantbi@> has quit IRC08:21
*** camus1 is now known as kaspter08:21
*** risca <risca!~quassel@> has joined #yocto08:22
*** iokill <iokill!> has joined #yocto08:22
Brian90Hi i have with yocto zeus the following problem: I want to integrate my self builded qt 5 (for Arm) as a recipe but yocto have the problem that the sdk for qt5 have x86 (like qmake)... How can i solve it???08:22
LetoThe2ndBrian90: if your recipe sticks to the usual qt practises, this should all work automagically.08:28
*** xtron1 <xtron1!~xtron@> has quit IRC08:31
*** Sibert <Sibert!b98ee38f@> has joined #yocto08:32
SibertHello everyone. I'm using yocto from a docker container. I would like to use the devshell for some things, but I cannot scroll/go up in the devshell. Does anyone if it's possible and ifso, how?08:33
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC08:46
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto08:47
*** xtron1 <xtron1!~xtron@> has joined #yocto08:58
*** sstiller <sstiller!> has joined #yocto09:00
*** RichterDirk[m] <RichterDirk[m]!rrdsofting@gateway/shell/> has quit IRC09:03
*** xtron1 <xtron1!~xtron@> has quit IRC09:03
*** xtron1 <xtron1!~xtron@> has joined #yocto09:05
*** kaspter <kaspter!~Instantbi@> has quit IRC09:11
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:12
*** samvlewis <samvlewis!~samvlewis@> has quit IRC09:14
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto09:15
SibertHello everyone. I'm using yocto from a docker container. I would like to use the devshell for some things, but I cannot scroll/go up in the devshell. Does anyone if it's possible and ifso, how?09:16
*** samvlewis <samvlewis!~samvlewis@> has quit IRC09:17
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto09:17
LetoThe2ndSibert: it probably depends a bit on the exact environment, where the shell is executed.09:18
LetoThe2ndif you execute it inside a tmux session or such it doesn't help?09:20
SibertI don't know what tmux is, I'll have to look into it09:25
SibertI'm currently using a ubuntu 18.04 VM, that runs a docker with docker09:25
*** florian_kc is now known as florian09:25
SibertWell I'll be damned, thanks LetoThe2nd09:27
SibertGoogling tmux helped me achieve what I needed09:27
*** xtron1 <xtron1!~xtron@> has quit IRC09:28
LetoThe2ndno need to be damned, but screen/tmux are core parts of each linux developers toolbox :)09:29
*** xtron <xtron!~xtron@> has joined #yocto09:30
SibertYeah I know screen09:31
Sibertbut those commands didn't seem to work09:31
*** goliath <goliath!> has quit IRC09:33
*** kaspter <kaspter!~Instantbi@> has quit IRC09:44
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:44
*** JaMa <JaMa!> has quit IRC09:46
*** xtron1 <xtron1!~xtron@> has joined #yocto09:57
*** xtron <xtron!~xtron@> has quit IRC09:59
*** goliath <goliath!> has joined #yocto10:12
fbreHi! The kernel does not start. What does this error happen?:10:22
fbrefailed on fdt_overlay_apply(): FDT_ERR_BADMAGIC10:23
fbrebase fdt does did not have a /__symbols__ node10:23
fbremake sure you've compiled with -@10:23
fbreIt happened as I changed via     bitbake virtual/kernel -c menuconfig    from overlayfs (M)  to (*)   which means not as kernel module but compiled in10:28
*** ada100 <ada100!cb7e0071@> has quit IRC10:40
*** luneff <luneff!~yury@> has joined #yocto10:49
*** goliath <goliath!> has quit IRC10:49
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto11:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC11:01
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC11:03
*** Konsgnx <Konsgnx!> has joined #yocto11:15
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:16
*** fbre <fbre!91fdde45@> has quit IRC11:19
*** berton <berton!~berton@> has joined #yocto11:38
*** kiwi_29 <kiwi_29!> has joined #yocto11:40
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC11:43
*** kiwi_29 <kiwi_29!> has quit IRC11:44
*** awe002 <awe002!~awe00@unaffiliated/awe00> has joined #yocto11:51
*** Sibert <Sibert!b98ee38f@> has quit IRC11:53
*** jobroe <jobroe!> has quit IRC11:56
*** goliath <goliath!> has joined #yocto12:01
*** NiksDev <NiksDev!~NiksDev@> has quit IRC12:04
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto12:04
*** florian_kc is now known as florian12:05
*** kaspter <kaspter!~Instantbi@> has quit IRC12:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:07
*** sh00p <sh00p!> has quit IRC12:13
*** laurittr <laurittr!> has quit IRC12:18
*** laurittr <laurittr!> has joined #yocto12:18
*** dmoseley <dmoseley!~dmoseley@> has quit IRC12:37
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto12:38
*** gsalazar87 <gsalazar87!5e3ce511@gateway/web/cgi-irc/> has joined #yocto12:38
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC12:42
*** gsalazar87 is now known as gsalazar12:42
*** Brian90 <Brian90!> has quit IRC12:51
*** matthewzmd <matthewzmd!> has joined #yocto12:52
*** comptroller <comptroller!> has quit IRC12:56
*** comptroller <comptroller!> has joined #yocto12:56
*** kaspter <kaspter!~Instantbi@> has quit IRC13:13
*** goliath <goliath!> has quit IRC13:14
*** sstiller <sstiller!> has quit IRC13:17
*** paulg <paulg!> has joined #yocto13:21
*** vineela <vineela!~vtummala@> has joined #yocto13:25
*** vineela <vineela!~vtummala@> has quit IRC13:29
kanavin_homeRP: I see some of the version updates are making their way from other people - I guess sunday evening would be a good moment to rebase and send my patchset?13:30
kanavin_homeM3 deadlines are drawing closer13:30
*** ericch <ericch!> has joined #yocto13:32
*** comptroller <comptroller!> has quit IRC13:33
zeddiikhem: I just did a clean build of qemumips with what is in master currently, and the virtio warning isn't showing. If you can send me your layer configuration later today, I'll double check before sending my series.13:33
*** luneff <luneff!~yury@> has quit IRC13:39
*** awe002 <awe002!~awe00@unaffiliated/awe00> has quit IRC13:41
*** awe003 <awe003!~awe00@unaffiliated/awe00> has joined #yocto13:42
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC13:47
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto13:48
*** clement <clement!~clement@> has quit IRC13:52
RPkanavin_home: probably, yes. We have seen some bits coming through at least13:52
RPzeddii: I merged the 5.8 bits since they seemed to build cleanly and it gives more exposure13:54
zeddiiyah. I'll send the default changing patches soon, just so they are out there. I havent' seen any issues for a couple of weeks now13:54
*** mattsm <mattsm!> has quit IRC13:55
*** mattsm <mattsm!> has joined #yocto13:55
zeddiiI expect I'll have some config tweaks to do, since the enhanced audit is more capabable. but the default configs are all clean (I made sure of that).13:55
RPzeddii: makes sense. we can run the patches through over the weekend and see what state things are in13:55
*** clement <clement!~clement@> has joined #yocto13:59
*** Bunio_FH <Bunio_FH!> has quit IRC14:00
*** Bunio_FH <Bunio_FH!> has joined #yocto14:01
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto14:11
*** comptroller <comptroller!> has joined #yocto14:14
*** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto14:15
*** awe003 <awe003!~awe00@unaffiliated/awe00> has quit IRC14:17
*** xtron1 <xtron1!~xtron@> has quit IRC14:20
RPJPEW: Are you ok with my fix in master-next of mingw?14:27
*** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC14:42
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC14:47
*** awe004 <awe004!~awe00@unaffiliated/awe00> has joined #yocto14:50
kanavin_homeThis patch series add a new flag "-fparallel-jobs=" to control if the compiler should try to compile the current file in parallel.14:52
kanavin_homenot sure if oe-core has many recipes which would benefit, but definitely something to consider14:52
kanavin_homeI guess particularly very large (e.g. generated) c++ files would benefit14:52
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has joined #yocto14:54
RPkanavin_home: right, sounds fairly specialist for our general use case but interesting14:55
*** creich <creich!> has quit IRC15:02
kanavin_homeRP: you wouldn't believe abuses of c++ I see internally :)15:03
*** creich <creich!> has joined #yocto15:03
kanavin_homeit is considered okay to generate a c++ file so large that gcc takes 10 minutes to process it15:04
*** jwessel <jwessel!~jwessel@> has quit IRC15:07
kanavin_homeRP: btw, Konrad (the linter guy) sits next to me in the daimler office ;)15:10
kanavin_home(just reading the minutes from yesterday)15:10
kanavin_homewe all applied for travelling to Dublin, but alas, wont happen this year15:11
RPkanavin_home: I would believe them but it is sad :/15:11
RPkanavin_home: it is a shame about Dublin, could have been a good 10 year celebration15:11
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC15:14
*** matthewzmd <matthewzmd!> has quit IRC15:20
*** chris_ber <chris_ber!~quassel@> has quit IRC15:21
*** matthewzmd <matthewzmd!> has joined #yocto15:23
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:27
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has joined #yocto15:31
kanavin_homeRP: is anything virtual planned?15:31
RPkanavin_home: There will be a two day YP summit/YPDD sometime around the conference15:32
*** rcoote <rcoote!~rcoote@> has quit IRC15:36
*** kiwi_29 <kiwi_29!> has joined #yocto15:39
*** cp- <cp-!> has quit IRC15:42
*** cp- <cp-!> has joined #yocto15:43
*** kiwi_29 <kiwi_29!> has quit IRC15:43
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto15:46
dl9pfJPEW: RP: fyi compare these 2:15:58
dl9pfprserv: 2020-08-21 15:46:57,783 poiapp-git-r0 corei7-64 fad44da993bf97cea3e4899f1b2a0a2e1bb92652a3d86c61ef1510a65e44762315:59
dl9pfhashserv: Adding taskhash fad44da993bf97cea3e4899f1b2a0a2e1bb92652a3d86c61ef1510a65e447623 with unihash fad44da993bf97cea3e4899f1b2a0a2e1bb92652a3d86c61ef1510a65e44762315:59
dl9pfso in my understanding, we would want a specific PR value tied to the unihash then. no ?16:00
dl9pfsame unihash should get same pr from prserv ?16:00
RPdl9pf: It depends on the mode of PRServ you have enabled. There are cases where you always want PR to increment16:05
RPdl9pf: fray is working on some changes here which should help a lot (and separate out PR policy from hashequiv)16:05
RPdl9pf: the differing policies are one reason I do not want to tie PR serv and hash equiv tables16:06
*** jwessel <jwessel!~jwessel@> has joined #yocto16:10
*** feddischson <feddischson!> has quit IRC16:23
RPdl9pf: think of it this way - you could want a package feed where PR always increases, so if that hash was replaced and PR bumped, then something reverted, you'd want PR to increase again so on target you got the newer change16:24
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC16:29
*** stephano <stephano!> has joined #yocto16:33
*** gsalazar <gsalazar!5e3ce511@gateway/web/cgi-irc/> has quit IRC16:35
*** codusnocturnus <codusnocturnus!~codusnoct@2600:8800:a601:3a00:dc8e:9494:b779:1e93> has quit IRC16:38
RPJPEW: talking with fray, I think it may be an idea to keep a client side outhash cache inside unihash.dat16:39
RPJPEW: it does mean we'd need to server to tell us the outhash when we request a unihash though16:39
*** armpit <armpit!~armpit@2601:202:4180:a5c0:3543:531d:382f:ed2a> has quit IRC16:41
*** armpit <armpit!~armpit@2601:202:4180:a5c0:ccb4:20b:5f9e:68b5> has joined #yocto16:54
*** robbawebba <robbawebba!~rob@> has joined #yocto16:55
*** zandrey <zandrey!~zandrey@> has quit IRC16:58
*** robbawebba <robbawebba!~rob@> has left #yocto16:59
*** robbawebba <robbawebba!~rob@> has joined #yocto16:59
kergothhmm, on dunfell hitting TypeError: can't pickle _thread.RLock objects in runCommand connection.send(). guessing that was probably fixed in master17:01
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC17:02
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto17:04
JPEWRP: meta-mingw fix seem sfine17:18
JPEWRP: Hmm; IIRC requesting the initial unihash is one of the slowest operations (its why we have the streaming mode); doubling the data may not help17:23
JPEWUnless the idea is that the client can deduce it's own unihashes without talking to the server?17:24
khemzeddii: my setup is
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto17:44
*** rcoote <rcoote!~rcoote@> has joined #yocto17:53
zeddiicool. thanks khem, I'll dig into it!17:56
*** rcoote <rcoote!~rcoote@> has quit IRC18:03
frayJPEW the use-case is:  user created an eSDK.. user modifies some setting.. user runs a build.. We don't want things that 'didn't actually change' to change, because there is not hashequiv 'database'.. So if we have the data stored in the unihash.dat then we don't need a 'server'18:05
fray(user runs a build FROM WITHIN THE eSDK)18:05
*** osullivan99 <osullivan99!> has quit IRC18:06
JPEWfray: How does the outhash help with that?18:06
frayRP was saying that today (with no changes made by the user) the unihash.dat is used without the database..18:08
fraysince the database is "big", he was saying he didn't want the database in the eSDK.. but if the data is there, we can protect the eSDK user from having to create new things if the unihash matches the prior build (what was cached in the unihash.dat)18:08
frayWe have a similar problem with the PR service data BTW.18:09
JPEWWell, like I said it's going to double the about of data transfered at whats already the largest bottleneck.... is there a way we can only request that data when we are build the eSDK instead of all the time?18:11
frayI don't understand enough about what is happening, but RP just said can't we store on each entry the "outhash"..18:12
fraywe're not going to computer it or anything, just store it when we have it18:12
fraywith the other data already stored per entry, I'm not sure how much large it makes things?  1/4?18:13
JPEWfray: Probably about that; I don't *think* the size of unihashes.dat is what RP is concerned about, but rather the hashequiv SQL database (which can be GB's)18:15
JPEWHe should correct me if that's wrong18:16
fraywhich is why he was saying do NOT use the datbase, but use the bb_unihashes.dat file18:16
fraybut it doesn't have the outhash in it18:16
*** jrdn <jrdn!> has joined #yocto18:17
JPEWRight, I think putting the outhash there is fine, but we already try to make the communication with the hashequiv server as fast as possible when bitbake is initializing the runqueue because it's the biggest bottle neck of the whole process18:17
JPEWThere is a very lightweight protocol where the client sends over a taskhash as a single line of text and the server responds with the unihash18:18
fraythe bb_unihashes.dat is all we were talking aobut..  my solution was to download the database that matched teh user's sstate-cache at the start of the build.. it's not lightweight but would work18:18
JPEWRight thats fine. The server has an API to get the full details about a taskhash from the server (client.get_taskhash())18:19
JPEWAs long as we don't do it during the runqueue initialization, thats fine18:19
JPEWfray: The reason that I point this out is that currently the way bb_unihashes.dat is populate is using the fast mechanism during runqueue initialization, so you'll needs some way to go back and query the outhash for each taskhash you care about at a later point18:21
fraylike I said, I was focusing on the DB, cause I don't know how this works -- nor do I intend to hack on initilization sequences..18:22
frayI understand what RP wants, but I have no (current) way to do it myself..18:22
JPEWfray: Hmm, I feel like I'm missing something18:23
frayI distribute an eSDK to my customers.  My customers will make changes to the config.. They need to be able to use the optimizations within the hashequivalency to avoid buildings when it's not necessary.  So I need 'a hash equivalency database' (note, not an actual database, but the functionality of one) in the eSDK to enable that, unless I am missing something..18:25
frayRP's response was the database is too big, so instead use the unihash.dat file, and add the missing element to it as a better way to distribute it -- as that .dat file is already distributed as part of the eSDK18:26
JPEWYes, that all seems reasonable18:26
frayAt this time, I have no plans to change the way the unihash.dat works or how the hash equivalency works -- outside of the PR service parts I'm working on now..18:26
frayI don't have the knowledge or the time to do it in before the end of this development sprint..18:26
frayso if I copy around a database (ignroing the size) it meets my immediate needs.. but isn't a OE/YP solution to this workflow18:27
JPEWgot it18:28
JPEWHow are you going to deal with the database after you have it? Are you going to start up a server when the user uses the eSDK?18:28
fraynot sure, but most likely we'll shove the database (both hash equiv and pr service) into a directory along side the matching sstate-cache.. then on startup, verify we have the current one download it if we don't.. (or alternatively download a configuration file that points to an external server..)18:29
frayI'm not sure any of that will ACTUALLY work though to be clear18:30
fraybut the way I look at it, hash equiv DB, PR DB and sstate-cache all three go together, so I need to try to keep them 'aligned'.18:31
fraystill have the problem of what happens to local data when the user deviates, etc.. I dont have any solutions to this..18:32
frayI'm hoping on the PR service side, I can supply a lockdown file, and 'add another digit' to the PR.. but that would all custom code..18:32
frayi.e. we release foo-1.0-r0.1 ... the user modifies something that causes a rebuild and then get r0.1.1 .. we release an update our update becomes r0.2 (or r0.2.0)18:33
JPEWYa, not sure. There is no "read-only" option for hash equiv (although it's requested a lot), so if your running the server to read the database (which the the only way to do it really...) it will write back changes the user makes18:33
JPEWbut perhaps thats not a problem for hash equiv like it is for PR18:34
frayMight have to do something 'similar' to the PR service and have some sort of static file that makes it read only.. but then again, maybe it's not REALLY a problem18:34
frayfor PR, I can customize the PR auto code to combine the lockdown and (local) service code..18:34
fray(right now they're mutually exclusive)18:34
JPEWYa, I suspect it's not really a problem since hash equiv is supposed to be more of a optimization18:34
frayyes.. and the sstate-cache we're shipping to customers isn't months worth of development either.. it'll be "one build".. so the database size (starting) is significantly smaller..18:35
JPEWfray: Ya, that approach seems reasonable (for that use case)18:36
zeddiikhem: what's the magic to force 5.8 for qemumips in your yoe setup ? is it master-next or something ? I'm only seeing the 5.4 bits in my clone of master.18:39
JPEWfray: FWIW, I've also intended for hash equiv servers to be hierarchical where one server could have an "upstream" server where it would query/push equivalencies; in that case you could always run a local server and the solution would look very similar to what you are planning18:42
fraythat was the orgiinal intent on the PR server as well.. along with rules to dictate which server set which values..18:43
frayso the return could be 0.0 vs 0... but it wasn't implemented that way in the end18:43
JPEWfray: Ya, it's probably a lot harder with PR having to make sure the number never goes backwards18:43
frayya, to me that is an action for the local server.. but coordinating could be difficult to say the least18:44
JPEWThe data hashequiv is reporting is actually pretty simple18:44
JPEWThe tricky part is the SQL qeury that the server uses to find the equivalencies (and all the bitbake code to make it work!)18:44
*** rokm <rokm!> has joined #yocto18:45
rokmHI, is it possible to use override mechanism with image name ?18:46
rokmPREFERRED_PROVIDER_virtual/my_package_qemu-x86 ?= "my_real_package"18:47
rokmPREFERRED_PROVIDER_virtual/my_package_qemu-x86_core-image-test = "my_test_package"18:48
rokmSo when I build core-image-test for qemu I expect that "my_test_package" will be used and installed on rootfs but it uses "my_real_package"18:49
frayoverrides are on a distribution basis.  You can chnge variable definitions within a recipe (image being no exception) but PREFERRED_PROVIDER is distribution wide..18:49
frayYou will need to be explicit in your test image that you want 'my_test_package', not virtual/my_package_qemu18:50
rokmSo it is not possible (even with some trick) to switch package depends on image type18:51
frayno.  PREFERRED_PROVIDER is a 'build this, not this' behavior.. so you can't build both18:52
rokmI don't want to build both18:52
frayWhat if you run  'bitbake core-image-one core-image-two core-image-test core-image-something-else"18:53
fraythe system doesn't know which package (PREFERED_PROVIDER) for each image..  and the image 'override' wouldn't have meaning since you selected 4 images18:53
*** sakoman <sakoman!> has quit IRC18:54
rokmSo solution would be to remove PREFERRED_PROVIDER and define packages per image18:54
rokmmy_test_package for core-image-test18:54
frayyes.. have a relase image and a test image..18:54
rokmand mu_teal_package for core-image-real18:54
fraythe release image gets one package, the test image gets a different one.. that kind of thing18:54
*** sakoman <sakoman!> has joined #yocto18:56
*** roussinm <roussinm!> has quit IRC19:01
*** roussinm <roussinm!> has joined #yocto19:01
*** roussinm <roussinm!> has quit IRC19:03
*** pharaon2502 <pharaon2502!> has quit IRC19:11
*** vineela <vineela!~vtummala@> has joined #yocto19:18
*** creich_ <creich_!> has joined #yocto19:30
*** armpit2 <armpit2!~armpit@2601:202:4180:a5c0:ccb4:20b:5f9e:68b5> has joined #yocto19:31
*** armpit <armpit!~armpit@2601:202:4180:a5c0:ccb4:20b:5f9e:68b5> has quit IRC19:32
*** creich <creich!> has quit IRC19:32
*** NiksDev2 <NiksDev2!~NiksDev@> has joined #yocto19:32
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has quit IRC19:33
*** Bunio_FH <Bunio_FH!> has quit IRC19:34
*** Bunio_FH <Bunio_FH!> has joined #yocto19:35
*** wmills <wmills!~bill@2601:144:4100:fd1:12bf:48ff:fed7:9537> has joined #yocto19:38
*** adelcast1 <adelcast1!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has joined #yocto19:39
*** NiksDev <NiksDev!~NiksDev@> has quit IRC19:42
*** adelcast <adelcast!~adelcast@2605:6000:101c:3b5:37f1:578e:8088:a1b4> has quit IRC19:42
*** cp- <cp-!> has quit IRC19:42
*** dmoseley <dmoseley!~dmoseley@> has quit IRC19:42
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto19:48
*** cp- <cp-!> has joined #yocto19:49
*** comptroller <comptroller!> has quit IRC20:07
*** dmoseley <dmoseley!~dmoseley@> has quit IRC20:21
*** comptroller <comptroller!> has joined #yocto20:22
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto20:28
*** matthewzmd <matthewzmd!> has quit IRC20:30
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto20:30
*** matthewzmd <matthewzmd!> has joined #yocto20:33
*** dmoseley <dmoseley!~dmoseley@> has quit IRC20:35
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto20:37
*** Konsgnx <Konsgnx!> has quit IRC20:59
*** stacktrust <stacktrust!> has quit IRC21:02
*** beneth <beneth!> has left #yocto21:05
*** berton <berton!~berton@> has quit IRC21:05
*** odda <odda!> has joined #yocto21:22
*** matthewzmd <matthewzmd!> has quit IRC21:50
*** agust <agust!> has quit IRC22:19
RPJPEW: my thinking was that if we have the outhash data in the local cache we can avoid trips to the server under the "new rebuild matches the last one" scenario. We still need to notify the server of the equivalence but if there is no longer a server, things can still show more magic22:25
RPJPEW: but to do that, we need the outhash that matches the unihash22:25
RPJPEW: the eSDK currently neatly uses the unihash.dat file and I'd really prefer we use that than add something new22:26
khemRP: I saw patches from you for nativesdk do they handle the /usr/bin/env sh issue ?22:39
RPkhem: yes, they do22:42
RPkhem: took me quite a bit of work to find those but its the better fix22:42
RPkhem: I just need another round of tests to confirm all is now well22:42
khemRP: something is failing on me on master-next22:44
RPkhem: where/how?22:45
*** vineela <vineela!~vtummala@> has quit IRC22:46
khemrecipe-sysroot-native/usr/lib/rpm/rpmdeps: /mnt/b/yoe/master/build/tmp/sysroots-uninative/x86_64-linux/lib/ version `GLIBC_2.32' not found (required by /usr/lib/
RPkhem: did you upgrade the system to a new glibc?22:47
RPkhem: I suspect you need a newer uninative release22:47
*** ericch <ericch!> has quit IRC22:47
khemRP: glibc is updates see [2020-08-21T15:41:21-0700] [ALPM] upgraded glibc (2.31-5 -> 2.32-2)22:48
RPkhem: we need a new uninative release with 2.3222:49
khemRP: ok is it available somewhere or need to cook ?22:50
RPhalstead: fancy making a new uninative release? :)22:50
halsteadRP, Sounds fun.22:50
RPkhem: we need to make one22:50
RPhalstead: current master is probably as good as anything22:50
halsteadRP, That's what I was about to ask. :)22:50
khemok would be good to have my machine is stalled otherwise for weekend :22:51
RPkhem: you can disable uninative worst case22:51
khemyeah that would mean new sstate but I will do that22:51
RPkhem: if we have halstead around, we can probably sort a release quite quickly, depends what he's doing as I always struggle to get the tarballs where they should be22:53
*** khem <khem!~khem@unaffiliated/khem> has quit IRC22:54
halsteadUninative 2.9.rc1 is building now.22:57
RPhalstead: thanks. Not sure what happened to khem!22:58
RPhalstead: I need to sleep, if you could drop khem an email pointing at the uninative build output he can likely test it23:06
halsteadRP, Okay. Okay will do.23:11
halsteadRP, Shall I put in in it's final place for testing?23:12
RPhalstead: please, I just noticed its finished23:12
RPhalstead: sorry, I'm struggling to stay awake, didn't realise how late it was here :/23:14
RPI'll test tomorrow if khem hasn't23:14
* RP really goes23:14
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto23:21
*** ant__ <ant__!> has quit IRC23:22
khemRP: I ran testimages with -fno-common defaults and it seems to improve performance a notch too23:32
*** stephano <stephano!> has quit IRC23:35
halsteadkhem, Files are up at
khemhalstead: oh cool23:40
halsteadkhem, This includes the switch from md5sum to sha256sum. Let me know if I need to create md5sum files.23:40
halsteadkhem, I've made signed tags for the release. Let me know if tests are successful and I can push them.23:43
khemhalstead: I send update to fetch 2.9 uninative to ml23:52
khemlet me run it locally it seems to be holding well thus dar23:52
*** armpit2 is now known as armpit23:52
halsteadThank you khem23:53
*** awe004 <awe004!~awe00@unaffiliated/awe00> has quit IRC23:54
khemzeddii: btw. the kernel warning is still happening with latest master-next
khemthis is on qemumips23:55

Generated by 2.17.2 by Marius Gedminas - find it at!