**** BEGIN LOGGING AT Tue Dec 08 02:59:57 2020 Dec 08 04:27:28 halstead: do you happen to be around ? Dec 08 06:52:17 good morning Dec 08 07:33:49 yo dudX Dec 08 08:15:02 morning folks Dec 08 08:24:13 morning Dec 08 08:28:47 RP: 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 '-+.' Dec 08 08:28:58 it is the only thing crashing the wholer build Dec 08 08:29:18 i'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? Dec 08 08:30:06 kinda not even sure why qemu is getting built now.... unless hrmmm clang needs it Dec 08 08:36:34 OutBackDingo: 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 "-" Dec 08 08:36:47 There may be some variable expansion involved Dec 08 08:38:36 LetoThe2nd: I'd guess add some `bb.note()` calls in `copy_buildsystem` in populate_sdk_ext.bbclass Dec 08 08:39:50 paulbarker: ayup, thx Dec 08 08:41:03 does bb.note expand/print arbitrary objects? sorry, i'm a total python loser. :( Dec 08 09:14:54 OutBackDingo: 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? Dec 08 10:38:08 paulbarker: possibly this https://github.com/OverC/meta-overc/blob/master/meta-cube/recipes-devtools/qemu/qemu_5.%25.bbappend Dec 08 10:38:24 zeddii: see above :) Dec 08 10:38:52 RP: meta-overc Dec 08 10:40:16 paulbarker: fun. after getting rid of a problem being caused by leftover artifacts, gen-lockedsig-cache now is choking on linking across devices. Dec 08 11:02:46 next thought, is there a method to trace package dependenciers with bitbake somehow to see why qemu is even being built Dec 08 11:03:36 * OutBackDingo jumps into the fire Dec 08 11:04:24 OutBackDingo: enable buildhistory Dec 08 11:06:59 LetoThe2nd: kudos Dec 08 11:07:30 are 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. Dec 08 11:07:50 OutBackDingo: have fun Dec 08 11:08:23 LetoThe2nd: gotta learn the inner workings in depth at some point right! Dec 08 11:08:49 hehe. Dec 08 11:09:11 OutBackDingo: might require rebuilding the package in question but then you should find plenty of information. Dec 08 11:10:10 OutBackDingo: another option is dumping the task dependency graph with 'bitbake -g' and trying to decipher it Dec 08 11:10:52 OutBackDingo: that doesn't always help if something is getting in via the package manager fufiling a dependency, though Dec 08 11:12:15 OutBackDingo: definitely that Dec 08 11:12:52 LetoThe2nd: its probably trying to do hardlinks without fallbacks? Sounds like something I may have been responsible for :/ Dec 08 11:12:53 RP: i'm the living proof one can have a lot of fun without knowing/understanding too! :) Dec 08 11:13:36 RP: gen-lockedsig-cache blows up on os.link(f, dst) Dec 08 11:13:49 LetoThe2nd: almost certainly that then, yes Dec 08 11:14:05 its trying to make hardlinks between devices Dec 08 11:14:31 RP: 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. Dec 08 11:15:14 LetoThe2nd: try replacing that code with something like: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oe/path.py#n136 Dec 08 11:15:26 LetoThe2nd: i.e. fall back to a copy Dec 08 11:15:40 RP: 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#n109 Dec 08 11:16:15 LetoThe2nd: time to ask sakoman about it then :) Dec 08 11:16:36 or is this pre dunfell? Dec 08 11:17:47 RP: 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 base Dec 08 11:18:31 OutBackDingo: the entry in PACKAGES needs tweaking, then the FILES variables would need tweaking to match Dec 08 11:19:26 * OutBackDingo thinks RP just went way above his level of knowledge :) Dec 08 11:20:42 so PACKAGES_prepend_class-target = "${PN}-x86-64 \ and FILES_${PN}-x86_64_class-target = "${bindir}/qemu-system-x86_64 ${bindir}/qemu-x86-64 Dec 08 11:21:05 * OutBackDingo makes a logical animated guess Dec 08 11:23:36 Hi! 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? Dec 08 11:24:36 jkprg: 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. Dec 08 11:24:52 jkprg: why meta-swupdate? unless its for a simple purpose..... aktualizr / ostree might be a better choice Dec 08 11:25:28 I need dual-image update strategy. Dec 08 11:26:00 jkprg: see https://github.com/advancedtelematic/ota-community-edition Dec 08 11:26:09 I'm trying to develop some example for x86-64 PC. Dec 08 11:26:33 OutBackDingo: it all depends on the usecase. Dec 08 11:26:55 jkprg: 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. Dec 08 11:26:56 I thought there will some something ready-to-use for "standard" x86 Dec 08 11:27:24 RAUC and Mender.io are also popular choices for dual-image schemes Dec 08 11:28:15 jkprg: this is not an embedded system? Dec 08 11:29:29 what is the motivation for doing an A/B update scheme on an x86 PC? Dec 08 11:29:38 eduardas: 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 . Dec 08 11:31:07 eduardas: short downtime during upgrade (for A/B it's just a reboot), fast rollback (go to previous image) and consistency Dec 08 11:31:12 jkprg: 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 barebox Dec 08 11:32:07 jkprg: problem here is that SWUpdate does not have GRUB integration (at least the last time I used it) Dec 08 11:32:21 jkprg: as that is not really it's purpose Dec 08 11:33:32 eduardas: I understand that. I thought that "common" requirement would be already solved for common bootloaders for x86 platform. Dec 08 11:33:49 jkprg: I don't really recall any known distro using an A/B scheme on an x86 PC Dec 08 11:34:08 eduardas: hmm missing grub integration can be a problem. I have no experience with uboot for x86 Dec 08 11:35:10 jkprg: well, you can always write your own post-install scripts that make whatever GRUB manipulations you need, I guess Dec 08 11:36:30 jkprg: but really I'd suggest you think about it. People are not doing this for sensible reasons. Dec 08 11:37:29 eduardas: 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? Dec 08 11:37:39 jkprg: you can just do containers for your apps if you want little downtime, no? Dec 08 11:38:05 jkprg: unless you really need to update the kernel Dec 08 11:38:07 RAUC is fine, i wouldnt go near mender Dec 08 11:38:56 OutBackDingo: Does RAUC has HTTP API for OTA server? I want to write some simple OTA server myself. Dec 08 11:40:00 jkprg: another might be worth looking into is FMA https://www.fullmetalupdate.io/ Dec 08 11:40:06 ermmm FMU Dec 08 11:41:59 jkprg: with hawkbit yes..... Dec 08 11:42:18 OutBackDingo: 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? Dec 08 11:42:48 jkprg: do not put your layer in poky. I usually put mine inside same directory AS poky Dec 08 11:42:59 OutBackDingo: I thought hawkbit was java (=monster) server Dec 08 11:43:23 eduardas: great. thx Dec 08 11:43:39 jkprg: people usually use something like git-repo or git submodules to check out multiple bitbake metadat repositories Dec 08 11:44:07 jkprg: git-repo is a tool Google made for AOSP if you are not familiar already Dec 08 11:45:51 eduardas: I see. I was a bit confused because with bitbake-layer tool all the addon layers land in poky directory Dec 08 11:45:53 jkprg: here's an example on how multiple layers can be managed: https://github.com/varigit/variscite-bsp-platform/blob/dunfell/default.xml Dec 08 11:46:15 jkprg: this XML is used by git-repo Dec 08 11:46:21 jkprg: will repo can be alot ot learn git submodules is pretty straight forward to use Dec 08 11:46:36 jkprg: this is basically very similar to the approach I use for my dayjob Dec 08 11:47:18 eduardas: OutBackDingo: thx Dec 08 11:47:24 both approaches work, just don't fork poky Dec 08 11:47:42 keep it separate and clean Dec 08 11:47:52 jkprg: also please see https://youtu.be/KJHJlOtTdaE Dec 08 11:47:53 * OutBackDingo agrees with eduardas, that would be a night mare to maintain Dec 08 11:48:10 FÖRK ALL THE PÖCKYS! Dec 08 11:48:20 :D Dec 08 11:48:21 OutBackDingo: PACKAGES looked right, FILES_${PN}-x86_64_XXX needs to become FILES_${PN}-x86-64_XXX to match Dec 08 11:50:50 RP: ahhh so im good at guessing :) Dec 08 11:51:44 OutBackDingo: ${bindir}/qemu-x86_64 needs to stay as ${bindir}/qemu-x86_64 too Dec 08 11:51:53 ill file a pull requesu with meta-overc for zeddii Dec 08 11:52:16 OutBackDingo: basically change any of the ${PN}-x86_64 references to ${PN}-x86-64 Dec 08 11:52:23 RP: yeah i got that Dec 08 11:52:31 ill test my changes Dec 08 11:54:01 OutBackDingo: just to be clear thats the reference in FILES, RDEPENDS and INSANE_SKIP Dec 08 12:01:59 FILES_${PN}-x86-64_class-target = "${bindir}/qemu-system-x86_64 ${bindir}/qemu-x86-64" Dec 08 12:01:59 RDEPENDS_${PN}-x86-64_append_class_target = "${PN}" Dec 08 12:01:59 INSANE_SKIP_${PN}-x86-64_class-target = "file-rdeps" Dec 08 12:02:03 RP: done Dec 08 12:02:10 :) thx for the check Dec 08 12:05:03 OutBackDingo: you've changed ${bindir}/qemu-x86-64 though? Dec 08 12:05:34 RP: nope Dec 08 12:05:41 opps Dec 08 12:05:46 right! Dec 08 12:06:30 fixed Dec 08 12:06:50 bitbake qemu to test Dec 08 12:10:17 RP: my git diff of it https://pastebin.com/5tExu7ks Dec 08 12:13:13 OutBackDingo: looks reasonable to me Dec 08 12:37:42 whoop whoopp qemu_5.1.0-r0_amd64.deb Dec 08 13:01:25 bitbake reports that my basehash changed for .populate_sdk_ext upon reparsing. any pointers how to debug this? bitbake-diffsigs essentially jsut confirms the change. Dec 08 13:02:53 respectively, where are those sigdatafiles that i can look at? Dec 08 13:16:20 is it better to use rust-embedded Dec 08 13:16:20 meta-rust-bin perhaps Dec 08 13:16:30 instead of just meta-rust which compiles Dec 08 13:18:28 Ad0: I've been comparing the two approaches. meta-rust-bin has some serious limitations Dec 08 13:18:37 like wut Dec 08 13:19:23 drives me nuts that rules change violently between rust versions Dec 08 13:19:25 I 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_fetch Dec 08 13:19:33 so I have to try the correct version Dec 08 13:19:50 ok Dec 08 13:19:57 Is meta-rust not up-to-date? Maintenance of that does seem to have slowed Dec 08 13:20:10 it is on 1.46 Dec 08 13:20:21 I think 1.48 is out now at least Dec 08 13:20:27 but it seems active tho Dec 08 13:20:27 Ok that does need updating Dec 08 13:20:39 meta-rust is likely to be the basis for us adding Rust support to oe-core Dec 08 13:20:55 it is a big puzzle. some packages don't work with certain versions of rust because new linting is there etc Dec 08 13:21:28 I would prefer binary download instead of 1 hour of compiling per version to test Dec 08 13:21:29 hehe Dec 08 13:21:52 Ad0: The meta-rust-bin issues aren't so much to do with the fact that it uses a pre-built toolchain Dec 08 13:22:35 The issue is that they haven't considered Yocto features like the archiver, license compliance tools, etc Dec 08 13:22:54 maybe they started out with limited knowledge of yocto Dec 08 13:23:20 I don't even know how to set PREFERRED_VERSION Dec 08 13:26:33 consider https://github.com/meta-rust/meta-rust/tree/master/recipes-devtools/rust Dec 08 13:26:57 do I have to set PREFERRED_VERSION-libstd-rs = .... for each little thing there? Dec 08 13:27:26 rust-cross, rust-llvm etc Dec 08 13:33:27 PREFERRED_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. Dec 08 13:42:34 RP: where are the sigdata files of a populate_sdk_ext task supposed to end up? it doesn't seem to be tmp/stamp/MACHINE/IMAGE Dec 08 13:44:30 Ad0: 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 is Dec 08 13:44:38 LetoThe2nd, so you are saying that I have to do it explicitly for each recipe? Dec 08 13:44:43 ok paulbarker :) Dec 08 13:45:38 Ad0: unless something in the recipes explicitly forms a version-bound dependency chain, yes. Dec 08 13:45:55 yeah I have no idea hehe Dec 08 13:46:33 PREFERRED_VERSION_rust-llvm = "..." etc gotcha Dec 08 13:47:40 Ad0: 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. Dec 08 13:47:56 yeah Dec 08 13:48:18 rust is used more and more places so I would assume that this would be pretty central Dec 08 13:49:17 Ad0: 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. Dec 08 13:50:38 right Dec 08 13:55:12 LetoThe2nd: they're nostamp I think? Dec 08 13:55:38 RP: yes bitbake-diffsigs tells me that. Dec 08 13:56:07 that means i can't even find out what triggers the difference? Dec 08 13:56:21 LetoThe2nd: nostamp means it will always run? Dec 08 13:57:35 RP: 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. Dec 08 13:59:02 LetoThe2nd: that does make things somewhat tricky :/ Dec 08 13:59:37 LetoThe2nd: personally, I'd probably hack it to generate the files Dec 08 14:00:06 RP: even more tricky: it doesn't trigger that warning when being kicked off interactively through the cmdline. only if kas starts it. Dec 08 14:00:53 LetoThe2nd: that kind of hints the problem is something kas is doing setup wise Dec 08 14:01:07 ugh. 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 rust Dec 08 14:02:26 RP: 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. Dec 08 14:02:40 RP: "hack to generate", how? Dec 08 14:02:49 * LetoThe2nd is a total python noob, sorry. Dec 08 14:04:55 LetoThe2nd: by adding something to the code where that basehash message is printed Dec 08 14:05:40 LetoThe2nd: lib/bb/siggen.py:_build_data() Dec 08 14:06:24 LetoThe2nd: some kind of call to self.dump_sigtask() Dec 08 14:43:27 RP: hum, tried that but obviously i'm too sutpid. Dec 08 14:57:34 RP: 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. Dec 08 14:58:08 so, anybody an idea why -k should affect the hashes even at all?!? Dec 08 14:58:54 LetoThe2nd: that is strange. Are there warnings/errors being printed as the build starts? Dec 08 15:00:14 only 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. Dec 08 15:03:36 :q Dec 08 15:04:38 LetoThe2nd: the hash mismatch issues are a pain to debug Dec 08 15:16:01 RP: i officially can confirm that. Dec 08 15:16:43 i literally have NFC why -k should affect the hashes, but at least under very special circumstances it obviously can. Dec 08 15:19:41 LetoThe2nd: I would like to understand why that happens, there will be some explanation... Dec 08 15:20:44 there is always an explanation, of course. the question is, can it be found with a reasonable amount of effort Dec 08 15:22:04 * LetoThe2nd sighs Dec 08 15:22:20 and again, forget everything i just. false positive. Dec 08 15:29:32 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? Dec 08 15:30:28 fray: https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-COPY_LIC_DIRS and friends? Dec 08 15:31:05 that looks slightly different I think.. Dec 08 15:31:50 yeah sure. we at least here use that and then compress the directory into a zip Dec 08 15:31:58 The LICENSE_CREATE_PACKAGE is what I've been using.. Dec 08 15:32:20 ...for each recipe and to add those packages to the RRECOMMENDS_${PN}.... Dec 08 15:32:35 Hmm, I'll have to check my image, maybe it is already there.. I didn't see it in the last one I built though Dec 08 15:37:06 Nope, I'm wrong.. I just missed it.. they are already in the image.. Dec 08 16:05:53 What's the best practice for generating a wic image for my beaglebone, adding a new image recipe? Dec 08 16:18:33 v0n: wic or not is not related to new image or not. Dec 08 16:18:55 v0n: in a nutshell, if you want an imae with customized content, then you should create an image recipe Dec 08 16:27:37 LetoThe2nd: "image with customized content" includes an SD card or flash medium image, right? Dec 08 16:28:38 I'm asking because I added " wic" to my initramfs IMAGE_FSTYPES but it felt wrong Dec 08 16:37:09 Nope that's ok but that only changes the resulting format, not the content Dec 08 16:37:20 I'm off now sorry Dec 08 16:50:15 RP wants to spread the "nos" around ;-) Dec 08 17:00:16 come to meta-virt, you can see me say no to lots of things! Dec 08 17:00:57 i think every open source project goes through these same sorts of phases Dec 08 17:01:09 early in the project, the project is happy to take *anything* Dec 08 17:01:23 but over time the bar for acceptability rises Dec 08 17:01:57 tlwoerner: https://imgur.com/4OHJLX9 Dec 08 17:02:01 to the point where almost nothing gets in ;-) at least not without a non-trivial amount of effort Dec 08 17:02:33 paulbarker: haha, true Dec 08 17:03:00 https://newsthump.com/2020/12/08/first-vaccine-patient-margaret-keenan-strangely-compelled-into-shopping-spree-for-microsoft-products Dec 08 17:03:05 anyway, my point is, that "no" becomes more common, and it's a good thing :-) Dec 08 17:03:12 paulbarker: love a bit of scarfolk Dec 08 17:03:13 apparently OE developers get the urge to use WSL2 and vscode Dec 08 17:03:23 so beware of the jab! Dec 08 17:03:44 zeddii: I've been using vscode for months. Someone must have jabbed me in secret Dec 08 17:04:01 (that's satire, in case anyone is not aware) Dec 08 17:04:09 * zeddii doesn't want to get cancelled :P Dec 08 17:04:10 zeddii: haha Dec 08 17:04:26 rburton: I did wonder how well a scarfolk poster would translate for the non-Brits Dec 08 17:05:33 YPTM: Here now, sorry I'm late Dec 08 17:05:55 rburton: it's on topic, but didn't notice the Scarfolk thing Dec 08 17:05:59 fray: You missed us Dec 08 17:06:02 fray: already done! Dec 08 17:06:03 fray: haha, done! you'll have to read the notes Dec 08 17:06:11 fray: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit Dec 08 17:06:20 :P Dec 08 17:06:21 I like fray's technique though. miss the whole thing, and pretend like you planned to attend. Dec 08 17:06:25 well done! Dec 08 17:06:37 "it's the thought that matters" Dec 08 17:07:51 6 minute meetings are good meetings Dec 08 17:08:17 however, 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? Dec 08 18:03:28 Do my image recipes belong in ${LAYERDIR}/recipe-core/images/ or ${LAYERDIR}/images/ ? Dec 08 18:17:23 v0n: There's no specific requirement on where to put image recipes. Just make sure the paths are in BBFILES in your layer.conf file Dec 08 18:18:06 Most layers have `${LAYERDIR}/recipes-*/*/*.bb` in BBFILES so placing them in `${LAYERDIR}/images/` wouldn't work without modification Dec 08 18:25:20 yeah it seems more conventional to have a simple line BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend" without extra patterns in the layer.conf file Dec 08 18:38:41 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 ? Dec 08 18:38:58 Project have lakhs of lines code Dec 08 18:39:22 and it is based on cmake Dec 08 18:39:36 Anyone please Dec 08 18:45:33 yes, 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. Dec 08 18:46:38 Mr_Singh_: There's plenty of examples of cmake usage. I recommend checking out the poky and meta-openembedded repositories and doing a search Dec 08 19:02:58 Thank you so much Dec 08 19:03:20 So it does not matter how project is large right Dec 08 19:03:41 any project we can move to yocto Dec 08 19:04:11 My plan is make my project to part of linux os with minimal drivers and apis Dec 08 19:54:20 * LetoThe2nd recommends Mr_Singh_ to spend some time with https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Dec 08 19:54:39 One of the sessions even covers C++/cmake :) Dec 08 20:43:04 huh. 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 :) Dec 08 20:43:06 * kergoth adds to his list Dec 08 21:28:20 Hello, how do I know the list (sequence) in which packages are installed in rootfs Dec 08 22:22:54 kergoth: that sounds like the kind of bug we should fix :) Dec 08 22:54:38 Hi 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? Dec 08 23:11:51 codyps: if the image is otherwise identical, I'd vote just building both devicetrees into it and picking the appropriate dtb via bootloader config Dec 08 23:14:29 smurray: 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) Dec 08 23:15:28 and building 2 different u-boots seems to imply 2 different machines. (it seems that yocto normally switches u-boot on a MACHINE level). Dec 08 23:15:33 codyps: set a uboot env variable at mfg time, perhaps? Dec 08 23:17:47 Is there a way to package the whole repo content in the src.rpm. Currently the src rpm only contains header and C file. Dec 08 23:18:08 codyps: 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 see Dec 08 23:20:26 codyps: 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 them Dec 08 23:22:06 codyps: err, meant s/can set/cannot set/ above Dec 08 23:25:32 smurray: 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 the Dec 08 23:25:34 images I'm creating. Dec 08 23:28:33 codyps: 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 dtb Dec 08 23:28:53 codyps: that's probably easy to prototype Dec 08 23:38:12 smurray: 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. Dec 08 23:39:28 my 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) Dec 08 23:54:35 codyps: there's a case to be made for either. Doing it with 2 images is the path to the least amount of building Dec 08 23:56:22 codyps: probably, I'm willing to believe I'm wrong ;) Dec 08 23:56:48 I'm certainly hoping to limit the amount of building :) Dec 09 00:03:31 Need some guidance. I want to use the src rpm package to create a debugFS. But the source RPM only contains subset of files. Is there any way I could pull in the whole content including Makefile.am and other C,header file. This will allow our designer to point their IDE to a DEBUGFS directory where all the src -rpm are installed. Kind of a source Dec 09 00:03:31 level snapshot of all packages. Any help will be appreciated. **** ENDING LOGGING AT Wed Dec 09 02:59:56 2020