Tuesday, 2020-12-08

*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto00:02
*** dmoseley <dmoseley!~dmoseley@> has quit IRC00:10
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto00:11
*** oberstet <oberstet!~oberstet@> has quit IRC00:14
*** Kyubi <Kyubi!~Kyubi@> has quit IRC00:17
*** agust <agust!~agust@p5483339b.dip0.t-ipconnect.de> has quit IRC00:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto00:18
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto00:25
*** leon-anavi <leon-anavi!~Leon@> has quit IRC00:31
*** jwessel1 <jwessel1!~jwessel@unknown-3-103.windriver.com> has joined #yocto01:08
*** jwessel <jwessel!~jwessel@> has quit IRC01:09
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC01:14
*** jwessel <jwessel!~jwessel@> has joined #yocto01:15
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:4f7:596d:bf31:3950:5bda> has quit IRC01:15
*** jwessel1 <jwessel1!~jwessel@unknown-3-103.windriver.com> has quit IRC01:15
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:4f7:596d:bf31:3950:5bda> has joined #yocto01:17
*** lukma <lukma!~lukma@89-64-5-98.dynamic.chello.pl> has quit IRC01:19
*** PaowZ_ <PaowZ_!~vince@2a01:e0a:144:d020:806a:e75f:3191:328d> has quit IRC01:23
*** ssajal <ssajal!~ssajal@bras-base-otwaon0147w-grc-25-70-51-215-36.dsl.bell.ca> has joined #yocto01:24
*** lukma <lukma!~lukma@89-64-25-12.dynamic.chello.pl> has joined #yocto01:37
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC01:37
*** PaowZ <PaowZ!~vince@2a01:e0a:144:d020:806a:e75f:3191:328d> has joined #yocto01:49
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:52
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:04
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC02:06
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has joined #yocto02:06
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC02:08
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto02:09
*** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has quit IRC02:09
*** wyre <wyre!wyre@gateway/shell/xshellz/x-ocxykiomcgbapcpi> has quit IRC02:10
*** stkw0 <stkw0!~quassel@ns3046126.ip-91-121-8.eu> has joined #yocto02:10
*** wyre <wyre!wyre@gateway/shell/xshellz/x-clzsfxtcleoezbmx> has joined #yocto02:14
*** Kyubi <Kyubi!~Kyubi@> has quit IRC02:17
*** kaspter <kaspter!~Instantbi@> has quit IRC02:25
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:25
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto02:26
*** otavio__ <otavio__!~otavio@200-180-244-15.user3p.brasiltelecom.net.br> has joined #yocto02:34
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC02:34
*** nerdboy <nerdboy!~sarnold@> has joined #yocto02:40
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC02:42
*** camus <camus!~Instantbi@> has joined #yocto02:53
*** kaspter <kaspter!~Instantbi@> has quit IRC02:54
*** camus is now known as kaspter02:54
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC03:04
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto03:07
*** kaspter <kaspter!~Instantbi@> has quit IRC03:10
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:10
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto03:16
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto03:17
*** tgamblin <tgamblin!~tgamblin@cpe64777de11593-cm64777de11590.cpe.net.cable.rogers.com> has quit IRC03:18
*** Ru3D3eR <Ru3D3eR!~Ru3D3eR4@> has quit IRC03:18
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC03:19
*** nerdboy <nerdboy!~sarnold@> has quit IRC03:26
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto03:26
*** ssajal <ssajal!~ssajal@bras-base-otwaon0147w-grc-25-70-51-215-36.dsl.bell.ca> has quit IRC03:32
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC03:34
*** zkrx <zkrx!~quassel@adsl-89-217-239-212.adslplus.ch> has quit IRC03:36
*** zkrx <zkrx!~quassel@adsl-89-217-239-212.adslplus.ch> has joined #yocto03:39
*** ahadi <ahadi!~ahadi@> has quit IRC03:52
*** ahadi <ahadi!~ahadi@> has joined #yocto03:53
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has quit IRC04:02
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto04:04
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@> has quit IRC04:07
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has joined #yocto04:15
*** Kyubi <Kyubi!~Kyubi@> has quit IRC04:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto04:25
zeddiihalstead: do you happen to be around ?04:27
*** kaspter <kaspter!~Instantbi@> has quit IRC04:37
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:37
*** kaspter <kaspter!~Instantbi@> has quit IRC05:09
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:09
*** vineela <vineela!~vtummala@> has quit IRC05:20
*** falk0n_ <falk0n_!~falk0n@a85-138-156-79.cpe.netcabo.pt> has quit IRC05:59
*** camus <camus!~Instantbi@> has joined #yocto06:00
*** kaspter <kaspter!~Instantbi@> has quit IRC06:01
*** camus is now known as kaspter06:01
*** Kyubi <Kyubi!~Kyubi@> has quit IRC06:17
*** kaspter <kaspter!~Instantbi@> has quit IRC06:25
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:26
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto06:26
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto06:35
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC06:38
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto06:38
*** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto06:39
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto06:40
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has quit IRC06:41
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC06:41
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto06:43
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-131.dsl.bell.ca> has joined #yocto06:44
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-mdritxwfjatyinqk> has quit IRC06:48
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC06:51
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto06:51
zygagood morning06:52
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has joined #yocto06:55
*** falk0n <falk0n!~falk0n@a85-138-156-79.cpe.netcabo.pt> has joined #yocto06:56
*** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-136-150-cbl.xnet.hr> has joined #yocto07:03
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:04
*** hpsy <hpsy!~hpsy@> has joined #yocto07:04
*** olani <olani!user@nat/axis/x-uhfivaulmnkxasrr> has quit IRC07:05
*** davidinux1 <davidinux1!~davidinux@> has joined #yocto07:09
*** davidinux <davidinux!~davidinux@> has quit IRC07:12
*** agust <agust!~agust@p5483339b.dip0.t-ipconnect.de> has joined #yocto07:21
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has quit IRC07:26
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-ncorulphbkzddkfj> has joined #yocto07:28
LetoThe2ndyo dudX07:33
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@180-150-39-50.b49627.bne.nbn.aussiebb.net> has joined #yocto07:40
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC07:48
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto07:49
*** camus <camus!~Instantbi@> has joined #yocto07:50
*** frwol <frwol!~frwol@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto07:50
*** kaspter <kaspter!~Instantbi@> has quit IRC07:50
*** camus is now known as kaspter07:50
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has joined #yocto07:51
*** wzmuda <wzmuda!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto07:57
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto07:58
*** fl0v0 <fl0v0!~fvo@i5E86AF7A.versanet.de> has joined #yocto07:59
*** jobroe <jobroe!~manjaro-u@p579eb879.dip0.t-ipconnect.de> has joined #yocto08:03
stefan-schmidt[mmorning folks08:15
*** Kyubi <Kyubi!~Kyubi@> has quit IRC08:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto08:17
OutBackDingoRP: so best case scenerio, i need a hint where to look at fixing Subprocess output:dpkg-deb: error: package name has characters that aren't lowercase alphanums or '-+.'08:28
OutBackDingoit is the only thing crashing the wholer build08:28
LetoThe2ndi'm seeing strange problems in esdk creation that seem to be caused by the layer copying. for debugging this, whats the easiest way to insert printf style outputs?08:29
OutBackDingokinda not even sure why qemu is getting built now.... unless hrmmm clang needs it08:30
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:35
paulbarkerOutBackDingo: From what we discussed yesterday I think you'd need to find where the package "qemu-x86_64" is being defined and replace the "_" with a "-"08:36
paulbarkerThere may be some variable expansion involved08:36
paulbarkerLetoThe2nd: I'd guess add some `bb.note()` calls in `copy_buildsystem` in populate_sdk_ext.bbclass08:38
LetoThe2ndpaulbarker: ayup, thx08:39
LetoThe2nddoes bb.note expand/print arbitrary objects? sorry, i'm a total python loser. :(08:41
*** T_UNIX <T_UNIX!~T_UNIX@2a02:8071:b696:bd00:57dc:e194:3053:35c0> has joined #yocto08:42
*** Shikadi` <Shikadi`!~Shikadi@> has quit IRC08:51
*** chris_ber <chris_ber!~quassel@> has joined #yocto08:56
*** camus <camus!~Instantbi@> has joined #yocto09:01
*** kaspter <kaspter!~Instantbi@> has quit IRC09:01
*** camus is now known as kaspter09:01
*** oberstet <oberstet!~oberstet@> has joined #yocto09:10
RPOutBackDingo: As paulbarker said, something is splitting qemu into different packages but I don't know what. Are any of your layers bbappending the qemu recipe? Which layer is the qemu recipe coming from?09:14
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC09:41
*** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has joined #yocto10:05
*** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC10:15
*** Kyubi <Kyubi!~Kyubi@> has quit IRC10:17
*** jkprg <jkprg!~jkprg@> has joined #yocto10:21
*** RobertBerger <RobertBerger!~rber@ppp-2-86-143-170.home.otenet.gr> has joined #yocto10:27
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto10:30
*** camus <camus!~Instantbi@> has joined #yocto10:31
*** kaspter <kaspter!~Instantbi@> has quit IRC10:32
*** camus is now known as kaspter10:32
*** bps <bps!~bps@> has joined #yocto10:36
OutBackDingopaulbarker: possibly this https://github.com/OverC/meta-overc/blob/master/meta-cube/recipes-devtools/qemu/qemu_5.%25.bbappend10:38
OutBackDingozeddii: see above :)10:38
OutBackDingoRP: meta-overc10:38
*** jkprg <jkprg!~jkprg@> has quit IRC10:39
LetoThe2ndpaulbarker: fun. after getting rid of a problem being caused by leftover artifacts, gen-lockedsig-cache now is choking on linking across devices.10:40
*** jkprg <jkprg!~jkprg@> has joined #yocto10:47
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC10:56
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto10:57
OutBackDingonext thought, is there a method to trace package dependenciers with bitbake somehow to see why qemu is even being built11:02
* OutBackDingo jumps into the fire11:03
LetoThe2ndOutBackDingo: enable buildhistory11:04
*** camus <camus!~Instantbi@> has joined #yocto11:05
*** juvenal <juvenal!juvenal@premium.znc.bg> has quit IRC11:06
*** kaspter <kaspter!~Instantbi@> has quit IRC11:06
*** camus is now known as kaspter11:06
OutBackDingoLetoThe2nd: kudos11:06
*** stzsch <stzsch!~stzsch@> has quit IRC11:07
LetoThe2ndare there any limitations on what has to be on the same device in order to build an esdk? at the moment i have seperate mounts for build, download, sstate. gen-lockedsig-cache blows up and i don't get why.11:07
*** stzsch <stzsch!~stzsch@> has joined #yocto11:07
LetoThe2ndOutBackDingo: have fun11:07
OutBackDingoLetoThe2nd: gotta learn the inner workings in depth at some point right!11:08
LetoThe2ndOutBackDingo: might require rebuilding the package in question but then you should find plenty of information.11:09
*** T_UNIX <T_UNIX!~T_UNIX@2a02:8071:b696:bd00:57dc:e194:3053:35c0> has quit IRC11:10
smurrayOutBackDingo: another option is dumping the task dependency graph with 'bitbake -g' and trying to decipher it11:10
smurrayOutBackDingo: that doesn't always help if something is getting in via the package manager fufiling a dependency, though11:10
RPOutBackDingo: definitely that11:12
RPLetoThe2nd: its probably trying to do hardlinks without fallbacks? Sounds like something I may have been responsible for :/11:12
LetoThe2ndRP: i'm the living proof one can have a lot of fun without knowing/understanding too! :)11:12
LetoThe2ndRP: gen-lockedsig-cache blows up on  os.link(f, dst)11:13
RPLetoThe2nd: almost certainly that then, yes11:13
*** eduardas <eduardas!~eduardas@78-61-200-153.static.zebra.lt> has quit IRC11:14
RPits trying to make hardlinks between devices11:14
*** eduardas <eduardas!~eduardas@82-135-139-249.static.zebra.lt> has joined #yocto11:14
LetoThe2ndRP: once i had verified that this bug also exists on current head or at least dunfell i might have poked you in the end, but i usually try to avoid pestering you without really good reason.11:14
RPLetoThe2nd: try replacing that code with something like: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oe/path.py#n13611:15
RPLetoThe2nd: i.e. fall back to a copy11:15
LetoThe2ndRP: seems to be fixed in master, theres already a check for it: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/gen-lockedsig-cache#n10911:15
RPLetoThe2nd: time to ask sakoman about it then :)11:16
RPor is this pre dunfell?11:16
*** armpit <armpit!~armpit@2601:202:4180:a5c0:742d:c90b:2c17:f31> has quit IRC11:17
OutBackDingoRP: so let me guess here, my offending line is FILES_${PN}-x86_64_class-target = "${bindir}/qemu-system-x86_64 ${bindir}/qemu-x86_64" and should be FILES_${PN}-x86_64_class-target = "${bindir}/qemu-system-x86_64 ${bindir}/qemu-x86-64" ? or am i way off base11:17
RPOutBackDingo: the entry in PACKAGES needs tweaking, then the FILES variables would need tweaking to match11:18
* OutBackDingo thinks RP just went way above his level of knowledge :)11:19
OutBackDingoso PACKAGES_prepend_class-target = "${PN}-x86-64 \   and FILES_${PN}-x86_64_class-target = "${bindir}/qemu-system-x86_64 ${bindir}/qemu-x86-6411:20
* OutBackDingo makes a logical animated guess11:21
jkprgHi! Anyone with meta-swupdate experience? Do I understand it correctly it's just a building block and I need to create a layer for my specific board?11:23
LetoThe2ndjkprg: you basically always need a layer for your board/application anyways. but yeah, if you're using swupdate you will have to add some bits and pieces for it usually.11:24
OutBackDingojkprg: why meta-swupdate? unless its for a simple purpose..... aktualizr / ostree might be a better choice11:24
jkprgI need dual-image update strategy.11:25
OutBackDingojkprg: see https://github.com/advancedtelematic/ota-community-edition11:26
jkprgI'm trying to develop some example for x86-64 PC.11:26
LetoThe2ndOutBackDingo: it all depends on the usecase.11:26
eduardasjkprg: I think u-boot + SWUpdate is a good choice for A/B image scheme. The developer of SWUpdate is also a u-boot maintainer, so these two components work well together.11:26
jkprgI thought there will some something ready-to-use for "standard" x8611:26
eduardasRAUC and Mender.io are also popular choices for dual-image schemes11:27
eduardasjkprg: this is not an embedded system?11:28
eduardaswhat is the motivation for doing an A/B update scheme on an x86 PC?11:29
jkprgeduardas: cause it suppose to be simple to implement I'd like to use a simple HTTP based update. I want to write the simple OTA server from scratch .11:29
*** armpit <armpit!~armpit@2601:202:4180:a5c0:75c4:9986:e08c:3005> has joined #yocto11:30
*** carlsb3rg <carlsb3rg!~chrissc@> has joined #yocto11:31
jkprgeduardas: short downtime during upgrade (for A/B it's just  a reboot), fast rollback (go to previous image) and consistency11:31
eduardasjkprg: update agents like SWUpdate are usually strongly tied to bootloader logic, so standard solutions in the embedded space are usually tied to embedded system bootloaders like u-boot or barebox11:31
eduardasjkprg: problem here is that SWUpdate does not have GRUB integration (at least the last time I used it)11:32
eduardasjkprg: as that is not really it's purpose11:32
*** juvenal <juvenal!juvenal@premium.znc.bg> has joined #yocto11:32
jkprgeduardas: I understand that. I thought that "common" requirement would be already solved for  common bootloaders for x86 platform.11:33
eduardasjkprg: I don't really recall any known distro using an A/B scheme on an x86 PC11:33
jkprgeduardas: hmm missing grub integration can be a problem. I have no experience with uboot for x8611:34
eduardasjkprg: well, you can always write your own post-install scripts that make whatever GRUB manipulations you need, I guess11:35
eduardasjkprg: but really I'd suggest you think about it. People are not doing this for sensible reasons.11:36
jkprgeduardas: true :). ok. thx. As I'm new to yocto I'll go to play with it a bit. so basically now i need to write my layer. Does it need to be in poky directory just like other layers or if I need something quick I can create it in built tree?11:37
eduardasjkprg: you can just do containers for your apps if you want little downtime, no?11:37
eduardasjkprg: unless you really need to update the kernel11:38
OutBackDingoRAUC is fine, i wouldnt go near mender11:38
jkprgOutBackDingo: Does RAUC has HTTP API for OTA server? I want to write some simple OTA server myself.11:38
OutBackDingojkprg: another might be worth looking into is FMA https://www.fullmetalupdate.io/11:40
OutBackDingoermmm FMU11:40
OutBackDingojkprg: with hawkbit yes.....11:41
jkprgOutBackDingo: thx. I'll try this one too. Does all those updaters need to write a layer for my board or is there anything out-of-the-box read for x86 platform configurable through parameters?11:42
eduardasjkprg: do not put your layer in poky. I usually put mine inside same directory AS poky11:42
jkprgOutBackDingo: I thought hawkbit was java (=monster) server11:42
jkprgeduardas: great. thx11:43
eduardasjkprg: people usually use something like git-repo or git submodules to check out multiple bitbake metadat repositories11:43
eduardasjkprg: git-repo is a tool Google made for AOSP if you are not familiar already11:44
*** ant__ <ant__!~ant__@host-95-248-189-180.retail.telecomitalia.it> has quit IRC11:44
jkprgeduardas: I see. I was a bit confused because with bitbake-layer tool all the addon layers land in poky directory11:45
eduardasjkprg: here's an example on how multiple layers can be managed: https://github.com/varigit/variscite-bsp-platform/blob/dunfell/default.xml11:45
eduardasjkprg: this XML is used by git-repo11:46
OutBackDingojkprg: will repo can be alot ot learn git submodules is pretty straight forward to use11:46
eduardasjkprg: this is basically very similar to the approach I use for my dayjob11:46
jkprgeduardas: OutBackDingo: thx11:47
eduardasboth approaches work, just don't fork poky11:47
eduardaskeep it separate and clean11:47
LetoThe2ndjkprg: also please see https://youtu.be/KJHJlOtTdaE11:47
* OutBackDingo agrees with eduardas, that would be a night mare to maintain11:47
RPOutBackDingo: PACKAGES looked right, FILES_${PN}-x86_64_XXX needs to become FILES_${PN}-x86-64_XXX to match11:48
*** hpsy <hpsy!~hpsy@> has quit IRC11:50
OutBackDingoRP: ahhh so im good at guessing :)11:50
RPOutBackDingo: ${bindir}/qemu-x86_64 needs to stay as ${bindir}/qemu-x86_64 too11:51
OutBackDingoill file a pull requesu with meta-overc for zeddii11:51
RPOutBackDingo: basically change any of the ${PN}-x86_64 references to ${PN}-x86-6411:52
OutBackDingoRP: yeah i got that11:52
OutBackDingoill test my changes11:52
RPOutBackDingo: just to be clear thats the reference in FILES, RDEPENDS and INSANE_SKIP11:54
OutBackDingoFILES_${PN}-x86-64_class-target = "${bindir}/qemu-system-x86_64 ${bindir}/qemu-x86-64"12:01
OutBackDingoRDEPENDS_${PN}-x86-64_append_class_target = "${PN}"12:01
OutBackDingoINSANE_SKIP_${PN}-x86-64_class-target = "file-rdeps"12:01
OutBackDingoRP: done12:02
OutBackDingo:) thx for the check12:02
RPOutBackDingo: you've changed ${bindir}/qemu-x86-64 though?12:05
OutBackDingoRP: nope12:05
OutBackDingobitbake qemu to test12:06
OutBackDingoRP: my git diff of it https://pastebin.com/5tExu7ks12:10
*** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has joined #yocto12:10
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@180-150-39-50.b49627.bne.nbn.aussiebb.net> has quit IRC12:12
RPOutBackDingo: looks reasonable to me12:13
*** Kyubi <Kyubi!~Kyubi@> has quit IRC12:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto12:18
*** kaspter <kaspter!~Instantbi@> has quit IRC12:27
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:27
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-hkxhcaemktbgfbxa> has joined #yocto12:28
*** Konsgn <Konsgn!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto12:37
OutBackDingowhoop whoopp qemu_5.1.0-r0_amd64.deb12:37
*** Konsgn is now known as konsgnxx12:37
*** jkprg <jkprg!~jkprg@> has quit IRC12:53
*** jkprg <jkprg!~jkprg@> has joined #yocto12:53
*** camus <camus!~Instantbi@> has joined #yocto12:55
*** kaspter <kaspter!~Instantbi@> has quit IRC12:57
*** camus is now known as kaspter12:57
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@180-150-39-50.b49627.bne.nbn.aussiebb.net> has joined #yocto12:59
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@180-150-39-50.b49627.bne.nbn.aussiebb.net> has quit IRC12:59
LetoThe2ndbitbake reports that my basehash changed for .populate_sdk_ext upon reparsing. any pointers how to debug this? bitbake-diffsigs essentially jsut confirms the change.13:01
LetoThe2ndrespectively, where are those sigdatafiles that i can look at?13:02
*** tgamblin <tgamblin!~tgamblin@cpe64777de11593-cm64777de11590.cpe.net.cable.rogers.com> has joined #yocto13:11
Ad0is it better to use rust-embedded13:16
Ad0meta-rust-bin perhaps13:16
Ad0instead of just meta-rust which compiles13:16
paulbarkerAd0: I've been comparing the two approaches. meta-rust-bin has some serious limitations13:18
Ad0like wut13:18
Ad0drives me nuts that rules change violently between rust versions13:19
paulbarkerI need to give it a proper test to be sure but looks like everything is downloaded from crates.io during do_compile instead of do_fetch13:19
Ad0so I have to try the correct version13:19
paulbarkerIs meta-rust not up-to-date? Maintenance of that does seem to have slowed13:19
Ad0it is on 1.4613:20
Ad0I think 1.48 is out now at least13:20
Ad0but it seems active tho13:20
paulbarkerOk that does need updating13:20
paulbarkermeta-rust is likely to be the basis for us adding Rust support to oe-core13:20
Ad0it is a big puzzle. some packages don't work with certain versions of rust because new linting is there etc13:20
Ad0I would prefer binary download instead of 1 hour of compiling per version to test13:21
paulbarkerAd0: The meta-rust-bin issues aren't so much to do with the fact that it uses a pre-built toolchain13:21
paulbarkerThe issue is that they haven't considered Yocto features like the archiver, license compliance tools, etc13:22
Ad0maybe they started out with limited knowledge of yocto13:22
Ad0I don't even know how to set PREFERRED_VERSION13:23
Ad0consider https://github.com/meta-rust/meta-rust/tree/master/recipes-devtools/rust13:26
Ad0do I have to set PREFERRED_VERSION-libstd-rs = .... for each little thing there?13:26
Ad0rust-cross, rust-llvm etc13:27
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@180-150-39-50.b49627.bne.nbn.aussiebb.net> has joined #yocto13:29
LetoThe2ndPREFERRED_VERSION lists can be quite long, yes. thats why its usually a good practise to offer only one or two really relevant versions per release.13:33
*** pbergin <pbergin!~pbergin@> has joined #yocto13:38
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto13:42
LetoThe2ndRP: where are the sigdata files of a populate_sdk_ext task supposed to end up? it doesn't seem to be tmp/stamp/MACHINE/IMAGE13:42
paulbarkerAd0: That needs cleaning up. I bet any testing only covers the most recent version in there. Carrying the older versions feels helpful but in practice it rarely is13:44
Ad0LetoThe2nd, so you are saying that I have to do it explicitly for each recipe?13:44
Ad0ok paulbarker :)13:44
LetoThe2ndAd0: unless something in the recipes explicitly forms a version-bound dependency chain, yes.13:45
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC13:45
Ad0yeah I have no idea hehe13:45
Ad0PREFERRED_VERSION_rust-llvm = "..." etc gotcha13:46
LetoThe2ndAd0: if a layer has like 4 versions for 4 recipes each that do not have any clear dependency chains, then i'd call the layer problematic at least, anyways. the combinatorial complexity alone confirms that it must be essentially untestable.13:47
Ad0rust is used more and more places so I would assume that this would be pretty central13:48
LetoThe2ndAd0: and thats what i'm just saying. if a layer is meant to be considered stable, then i expect it to have only one combination offered at any given (branch) state. two only in cases of emergency.13:49
*** kaspter <kaspter!~Instantbi@> has quit IRC13:54
RPLetoThe2nd: they're nostamp I think?13:55
LetoThe2ndRP: yes bitbake-diffsigs tells me that.13:55
LetoThe2ndthat means i can't even find out what triggers the difference?13:56
RPLetoThe2nd: nostamp means it will always run?13:56
LetoThe2ndRP: but what should i do then about ERROR: When reparsing /repo/recipes-projectname/images/project-image.bb.do_populate_sdk_ext, the basehash value changed from dfabf53df55d3d9ee7886c40d74a0cf4 to 7ac1a1069d7d98a8ec89a48f596f1577. The metadata is not deterministic and this needs to be fixed.13:57
RPLetoThe2nd: that does make things somewhat tricky :/13:59
RPLetoThe2nd: personally, I'd probably hack it to generate the files13:59
LetoThe2ndRP: even more tricky: it doesn't trigger that warning when being kicked off interactively through the cmdline. only if kas starts it.14:00
RPLetoThe2nd: that kind of hints the problem is something kas is doing setup wise14:00
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto14:01
Ad0ugh. rust had introduced some new linting rules or something that was not in sync with a release of the other package that depended on that rust14:01
LetoThe2ndRP: yes, but how to find out? with "interactively" by the way i also mean that kas is involved and all. the same dev container setup, just in one case it drops me into the shell and i type the command, the other time it runs the defined one.14:02
LetoThe2ndRP: "hack to generate", how?14:02
* LetoThe2nd is a total python noob, sorry.14:02
RPLetoThe2nd: by adding something to the code where that basehash message is printed14:04
RPLetoThe2nd: lib/bb/siggen.py:_build_data()14:05
RPLetoThe2nd: some kind of call to self.dump_sigtask()14:06
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has joined #yocto14:12
*** Kyubi <Kyubi!~Kyubi@> has quit IRC14:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto14:22
*** ccole <ccole!~cole@cpe-174-104-198-71.neo.res.rr.com> has joined #yocto14:30
LetoThe2ndRP: hum, tried that but obviously i'm too sutpid.14:43
*** hpsy <hpsy!~hpsy@> has joined #yocto14:53
*** jkprg <jkprg!~jkprg@> has quit IRC14:55
*** jkprg <jkprg!~jkprg@> has joined #yocto14:55
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto14:55
LetoThe2ndRP: despite my opinions on dogfooding i'll do one small exception now and not check against master now: it seems that -k being passed to bitbake breaks it,  if being there on the first invocation after the shell init.14:57
LetoThe2ndso, anybody an idea why -k should affect the hashes even at all?!?14:58
RPLetoThe2nd: that is strange. Are there warnings/errors being printed as the build starts?14:58
LetoThe2ndonly the basehash mismatch i've shown. and like i said, it should be taken with a pinch of salt - but the behaviour is cryptic at least.15:00
*** jkprg <jkprg!~jkprg@> has quit IRC15:04
RPLetoThe2nd: the hash mismatch issues are a pain to debug15:04
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC15:05
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has quit IRC15:14
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto15:15
LetoThe2ndRP: i officially can confirm that.15:16
LetoThe2ndi literally have NFC why -k should affect the hashes, but at least under very special circumstances it obviously can.15:16
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has joined #yocto15:16
RPLetoThe2nd: I would like to understand why that happens, there will be some explanation...15:19
*** davidinux1 <davidinux1!~davidinux@> has quit IRC15:20
LetoThe2ndthere is always an explanation, of course. the question is, can it be found with a reasonable amount of effort15:20
* LetoThe2nd sighs15:22
LetoThe2ndand again, forget everything i just. false positive.15:22
*** ilikecaffeine <ilikecaffeine!8cba9cd7@140-186-156-215-dynamic.midco.net> has joined #yocto15:26
fray When using the licene bbclass, it generates '-lic' packages automatically..  but I don't see an image feature (complementary glob) defined anywhere to install this into the running image, is there a mechanism to cause the running image to get the license files installed into it?15:29
*** bantu <bantu!~bantu@unaffiliated/bantu> has quit IRC15:29
LetoThe2ndfray: https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-COPY_LIC_DIRS and friends?15:30
*** armpit <armpit!~armpit@2601:202:4180:a5c0:75c4:9986:e08c:3005> has quit IRC15:30
fraythat looks slightly different I think..15:31
*** bantu <bantu!~bantu@unaffiliated/bantu> has joined #yocto15:31
LetoThe2ndyeah sure. we at least here use that and then compress the directory into a zip15:31
frayThe LICENSE_CREATE_PACKAGE is what I've been using..15:31
fray...for each recipe and to add those packages to the RRECOMMENDS_${PN}....15:32
*** armpit <armpit!~armpit@2601:202:4180:a5c0:44ad:b2c4:bf7f:7e99> has joined #yocto15:32
frayHmm, I'll have to check my image, maybe it is already there.. I didn't see it in the last one I built though15:32
*** davidinux1 <davidinux1!~davidinux@> has joined #yocto15:33
*** olani <olani!user@nat/axis/x-ovaiqlnrdfgrvaha> has joined #yocto15:33
frayNope, I'm wrong.. I just missed it.. they are already in the image..15:37
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto15:59
*** frsc <frsc!~frsc@p50937620.dip0.t-ipconnect.de> has quit IRC16:04
v0nWhat's the best practice for generating a wic image for my beaglebone, adding a new image recipe?16:05
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC16:07
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto16:07
*** ccole <ccole!~cole@cpe-174-104-198-71.neo.res.rr.com> has quit IRC16:07
*** jobroe <jobroe!~manjaro-u@p579eb879.dip0.t-ipconnect.de> has quit IRC16:08
*** Kyubi <Kyubi!~Kyubi@> has quit IRC16:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto16:18
LetoThe2ndv0n: wic or not is not related to new image or not.16:18
LetoThe2ndv0n: in a nutshell, if you want an imae with customized content, then you should create an image recipe16:18
*** moto-timo <moto-timo!~ttorling@c-73-67-208-188.hsd1.or.comcast.net> has joined #yocto16:21
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto16:21
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC16:26
v0nLetoThe2nd: "image with customized content" includes an SD card or flash medium image, right?16:27
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto16:27
v0nI'm asking because I added " wic" to my initramfs IMAGE_FSTYPES but it felt wrong16:28
*** Shikadi` <Shikadi`!~Shikadi@> has joined #yocto16:29
*** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC16:30
LetoThe2ndNope that's ok but that only changes the resulting format, not the content16:37
LetoThe2ndI'm off now sorry16:37
*** frwol <frwol!~frwol@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC16:39
*** Guest57913 is now known as khem16:39
*** khem <khem!khemmatrix@unaffiliated/khem> has joined #yocto16:40
*** khem <khem!khemmatrix@gateway/shell/matrix.org/x-meqxpfrmjqgapgxq> has joined #yocto16:40
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has joined #yocto16:44
*** dao <dao!02e71d8b@> has joined #yocto16:46
*** wzmuda <wzmuda!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC16:49
tlwoernerRP wants to spread the "nos" around ;-)16:50
zeddiicome to meta-virt, you can see me say no to lots of things!17:00
tlwoerneri think every open source project goes through these same sorts of phases17:00
tlwoernerearly in the project, the project is happy to take *anything*17:01
tlwoernerbut over time the bar for acceptability rises17:01
paulbarkertlwoerner: https://imgur.com/4OHJLX917:01
tlwoernerto the point where almost nothing gets in ;-) at least not without a non-trivial amount of effort17:02
tlwoernerpaulbarker: haha, true17:02
tlwoerneranyway, my point is, that "no" becomes more common, and it's a good thing :-)17:03
rburtonpaulbarker: love a bit of scarfolk17:03
zeddiiapparently OE developers get the urge to use WSL2 and vscode17:03
zeddiiso beware of the jab!17:03
paulbarkerzeddii: I've been using vscode for months. Someone must have jabbed me in secret17:03
zeddii(that's satire, in case anyone is not aware)17:04
* zeddii doesn't want to get cancelled :P17:04
tlwoernerzeddii: haha17:04
paulbarkerrburton: I did wonder how well a scarfolk poster would translate for the non-Brits17:04
frayYPTM: Here now, sorry I'm late17:05
*** eduardas <eduardas!~eduardas@82-135-139-249.static.zebra.lt> has quit IRC17:05
tlwoernerrburton: it's on topic, but didn't notice the Scarfolk thing17:05
paulbarkerfray: You missed us17:05
zeddiifray: already done!17:06
tlwoernerfray: haha, done! you'll have to read the notes17:06
tlwoernerfray: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit17:06
zeddiiI like fray's technique though. miss the whole thing, and pretend like you planned to attend.17:06
zeddiiwell done!17:06
zeddii"it's the thought that matters"17:06
fray6 minute meetings are good meetings17:07
tlwoernerhowever, on a more serious note, the raising bar will deter people, and you end up with a clique situation. again, this is normal, but is it good?17:08
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:22
*** fl0v0 <fl0v0!~fvo@i5E86AF7A.versanet.de> has quit IRC17:23
*** ilikecaffeine <ilikecaffeine!8cba9cd7@140-186-156-215-dynamic.midco.net> has quit IRC17:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:26
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto17:39
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has quit IRC17:49
*** chris_ber <chris_ber!~quassel@> has quit IRC17:51
*** vineela <vineela!~vtummala@> has joined #yocto17:57
v0nDo my image recipes belong in ${LAYERDIR}/recipe-core/images/ or ${LAYERDIR}/images/ ?18:03
*** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-136-150-cbl.xnet.hr> has quit IRC18:07
paulbarkerv0n: There's no specific requirement on where to put image recipes. Just make sure the paths are in BBFILES in your layer.conf file18:17
*** Kyubi <Kyubi!~Kyubi@> has quit IRC18:17
paulbarkerMost layers have `${LAYERDIR}/recipes-*/*/*.bb` in BBFILES so placing them in `${LAYERDIR}/images/` wouldn't work without modification18:18
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC18:21
v0nyeah it seems more conventional to have a simple line BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend" without extra patterns in the layer.conf file18:25
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto18:26
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto18:26
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has joined #yocto18:33
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@2607:fea8:bdf:dda2:4908:564f:8430:8c41> has joined #yocto18:36
Mr_Singh_Hi, I am new at here and I am new on yocto as well . I want to know Can we port existing cmake project on Yocto ?18:38
Mr_Singh_Project have lakhs of lines code18:38
Mr_Singh_and it is based on cmake18:39
Mr_Singh_Anyone please18:39
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC18:44
champagnegyes, any projects could be built and included in a linux distribution built by yocto. You should take a look around https://docs.yoctoproject.org/ to familiarize yourself with yocto.18:45
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto18:45
*** vineela <vineela!~vtummala@> has quit IRC18:46
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC18:46
paulbarkerMr_Singh_: There's plenty of examples of cmake usage. I recommend checking out the poky and meta-openembedded repositories and doing a search18:46
Mr_Singh_Thank you so much19:02
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC19:03
Mr_Singh_So it does not matter how project is large right19:03
Mr_Singh_any project we can move to yocto19:03
Mr_Singh_My plan is make my project to part of linux os with minimal drivers and apis19:04
*** davidinux1 is now known as davidinux19:04
*** vineela <vineela!~vtummala@> has joined #yocto19:07
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has quit IRC19:12
*** wzmuda <wzmuda!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto19:33
*** wzmuda <wzmuda!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC19:37
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC19:51
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:f038:1ea1:3507:febb> has joined #yocto19:52
* LetoThe2nd recommends Mr_Singh_ to spend some time with https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj19:54
*** bluelightning_ is now known as bluelightning19:54
LetoThe2ndOne of the sessions even covers C++/cmake :)19:54
*** alessio_ <alessio_!~alessio@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:08
*** otavio__ <otavio__!~otavio@200-180-244-15.user3p.brasiltelecom.net.br> has quit IRC20:08
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto20:10
*** testdime <testdime!5d2fe408@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:11
*** alessio_ <alessio_!~alessio@93-47-228-8.ip115.fastwebnet.it> has quit IRC20:11
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto20:12
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:13
*** testdime <testdime!5d2fe408@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:15
*** testdime <testdime!5d2fe408@93-47-228-8.ip115.fastwebnet.it> has left #yocto20:15
*** Kyubi <Kyubi!~Kyubi@> has quit IRC20:17
*** alessioigor_ <alessioigor_!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:23
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto20:24
*** alessioigor_ <alessioigor_!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:24
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto20:26
*** alessioigor__ <alessioigor__!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto20:27
*** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-136-150-cbl.xnet.hr> has joined #yocto20:28
*** alessioigor__ <alessioigor__!~alessioig@93-47-228-8.ip115.fastwebnet.it> has quit IRC20:29
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC20:33
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto20:35
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has left #yocto20:37
*** alessioigor_ <alessioigor_!~alessioig@93-47-228-8.ip115.fastwebnet.it> has quit IRC20:39
kergothhuh. can't use distrooverrides.bbclass without failing yocto-check-layer, as uboot and grub both getVar OVERRIDESE without adding it to vardepsexclude, so any addition to OVERRIDES will change their signatures :)20:43
* kergoth adds to his list20:43
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC20:45
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto20:46
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has joined #yocto20:54
*** oberstet <oberstet!~oberstet@> has quit IRC21:09
*** bps3 <bps3!~bps@> has joined #yocto21:20
*** bps <bps!~bps@> has quit IRC21:22
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto21:26
kiwi_29Hello, how do I know the list (sequence) in which packages are installed in rootfs21:28
*** pharaon2502 <pharaon2502!~manjaro-u@cpezg-94-253-136-150-cbl.xnet.hr> has quit IRC21:31
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC21:39
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has joined #yocto21:39
*** Ru3D3e <Ru3D3e!~Ru3D3eR4@> has joined #yocto21:42
*** olani[m] <olani[m]!olanimatri@gateway/shell/matrix.org/x-npgfvxezucngrtgj> has joined #yocto21:43
*** alejandrohs <alejandrohs!~alejandro@cpe-68-201-52-49.elp.res.rr.com> has quit IRC21:44
*** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has quit IRC21:45
*** konsgnxx <konsgnxx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC22:01
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC22:15
*** otavio <otavio!~otavio@200-180-244-15.user3p.brasiltelecom.net.br> has joined #yocto22:16
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto22:16
*** Kyubi <Kyubi!~Kyubi@> has quit IRC22:17
*** pbergin <pbergin!~pbergin@> has quit IRC22:21
RPkergoth: that sounds like the kind of bug we should fix :)22:22
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto22:30
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC22:38
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto22:40
*** wzmuda <wzmuda!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto22:41
*** codyps <codyps!~codyps@2601:18f:800:209d:60b1:22ff:fea0:5284> has joined #yocto22:52
codypsHi folks. Say I've got 2 boards which need the same software _except_ they have a different device tree (in the machine conf, we specify the device tree to build into the image). Should I just have seperate images and avoid having different MACHINEs (given the difference only shows up in the image, I build the device trees for all boards all the time), or should I really do different MACHINEs?22:54
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC23:00
*** codysch[m] <codysch[m]!codyschmat@gateway/shell/matrix.org/x-ncghfncsaahdqnoz> has joined #yocto23:04
smurraycodyps: if the image is otherwise identical, I'd vote just building both devicetrees into it and picking the appropriate dtb via bootloader config23:11
codypssmurray: ya, it would be nice to have 1 image that can support both. right now, I'm loading the device tree from a raw parition, so it isn't clear that there's a good way to pick (this is an arm platform using u-boot). I also think picking via bootloader would mean I'd have to build 2 different u-boot images (I don't have a way to easily determine which platform the bootloader is on)23:14
codypsand building 2 different u-boots seems to imply 2 different machines. (it seems that yocto normally switches u-boot on a MACHINE level).23:15
smurraycodyps: set a uboot env variable at mfg time, perhaps?23:15
*** hadi <hadi!a5e1d930@> has joined #yocto23:16
hadiIs there a way to package the whole repo content in the src.rpm. Currently the src rpm only contains header and C file.23:17
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-ncorulphbkzddkfj> has quit IRC23:18
smurraycodyps: if there's no way to easily tell which board from inside uboot and you can set something at mfg time, then you likely do end up with something more along the lines of building 2 different u-boots or perhaps hacking up something to make 2 different disk images with some difference u-boot can see23:18
smurraycodyps: if you go the 2 different u-boots route, defining 2 different MACHINEs (probably using a common inc or one including the other as base) is maybe the most straightforward way. I'd recommend looking at using multiconfig to simplify building both of them23:20
smurraycodyps: err, meant s/can set/cannot set/ above23:22
codypssmurray: thanks for all the advise here. I'm currently using a common inc for the different MACHINEs, just was considering if it would be better to remove the MACHINEs in favor of distinct images. I'll look at multiconfig. I'll think about the mfg time stuff, but I'm not sure I totally trust that it'll be fool proof considering the system is still in development with other developers using the23:25
codypsimages I'm creating.23:25
smurraycodyps: building 2 images with the same bits is perhaps workable if you were to maybe use a ROOTFS_POSTPROCESS_CMD to rename or symlink the required dtb23:28
smurraycodyps: that's probably easy to prototype23:28
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC23:33
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto23:36
*** bps3 <bps3!~bps@> has quit IRC23:38
codypssmurray: right now I'm using a wks.in file that uses a variable to locate the appropriate device tree file to embed into the right partition in the generated image. I think as long as I add the variable to WICVARS, it should be settable in the image itself.23:38
codypsmy angle here was more of "am I doing something really bad in a style-wise way" by doing this in images vs machines (or vice versa)23:39
*** habing <habing!~habing@2001:4bb8:19a:fdd9:b486:552f:43c9:2> has joined #yocto23:41
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:e1ea:8f38:f518:4e69> has quit IRC23:43
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5178:619c:fc92:5a85> has joined #yocto23:44
smurraycodyps: there's a case to be made for either.  Doing it with 2 images is the path to the least amount of building23:54
*** agust <agust!~agust@p5483339b.dip0.t-ipconnect.de> has quit IRC23:54
smurraycodyps: probably, I'm willing to believe I'm wrong ;)23:56
codypsI'm certainly hoping to limit the amount of building :)23:56
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC23:56
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto23:57

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