**** BEGIN LOGGING AT Fri Oct 13 03:00:03 2017 Oct 13 07:50:23 good morning Oct 13 14:35:15 If I add a patch to a SRC_URI and also use a machine override, does the package automatically become machine specific? Oct 13 14:41:37 no Oct 13 14:41:59 experiment confirms this Oct 13 14:42:08 I thought that was the case, but wanted to double check Oct 13 14:51:19 and no way to have a package be only MACHINE_ACRH when there is a bbappend with an override Oct 13 14:53:17 Crofton|work: maybe PACKAGE_ARCH_ = ... ? Oct 13 14:53:25 in your bbappend Oct 13 14:53:31 hmmm Oct 13 14:54:10 makes sense Oct 13 14:54:46 * Crofton|work greps Oct 13 14:57:27 rburton, from the mega manual: SRC_URI_OVERRIDES_PACKAGE_ARCH¶ Oct 13 14:57:27 By default, the OpenEmbedded build system automatically detects whether SRC_URI contains files that are machine-specific. If so, the build system automatically changes PACKAGE_ARCH. Setting this variable to "0" disables this behavior. Oct 13 14:58:09 huh Oct 13 14:58:12 well there you go Oct 13 15:00:24 Crofton|work: that looks like it only works when the SRC_URI refers to a patch that is included from a override filepath, not if src_uri is set via a override Oct 13 15:01:10 yeah you can do file://foo and have a files/qemux86/foo Oct 13 15:01:16 i guess that is what it picks up Oct 13 15:01:36 I wish I had a faster recipe to test with :) Oct 13 15:07:59 interesting it works that way Oct 13 15:11:56 so is it bad form to have the QEMU definitions in you machine file so that a single kernel can boot both? Oct 13 15:13:01 probably :) Oct 13 15:15:19 yeah, that is what my gut is telling me but there seems to no BSP rules addressing this Oct 13 15:16:02 * armpit loop holes Oct 13 15:16:23 yet Oct 13 15:16:31 run the holy script Oct 13 15:20:50 i have been and I have clean a few of my layers up with it. I will test qemu thing next Oct 13 15:22:13 good results? Oct 13 15:22:26 * kergoth yawns Oct 13 15:39:27 Crofton|work, just testes with qemu vars in machine file and it passes.. Oct 13 17:15:23 Crofton|work: any use of MACHINE overrides in your recipe will end up making it machine specific which is right Oct 13 17:16:15 but look slike you need to set PACKAGE_ARCH manually Oct 13 17:18:36 Dont think so unless you want to override the behavior of not making it machine specific in feeds Oct 13 17:19:35 hmm Oct 13 17:20:04 this isn't anything super importnat, but I need to try on an easier test case :) Oct 13 18:42:21 * armpit sigh.. nothing like a bitbake DoS Oct 13 19:24:07 armpit: ? the initial parsing? Oct 13 19:57:04 vmeson, think so.. it happened twice Oct 13 19:57:58 first time happened when I as installing our product ( java based installer) so I think it starved resources Oct 13 19:58:36 second time bitbake was running by it self Oct 13 19:59:02 it has not happened in a while Oct 13 19:59:12 bitbake has become self aware Oct 13 19:59:44 no, either Unionized or Socialist Oct 13 20:31:04 * vmeson suggests a nice, big Intel server upgrade to armpit :) Oct 13 20:31:39 (or limiting both java and bitbake's access to cores...) Oct 14 00:10:33 Yeah, so it looks like dnf may be the problem here. It appears to be checking the space available on / instead of the space available at the volume specified in the --installroot argument. Oct 14 01:28:31 kergoth: So I solved my problem by switching to ipk format. This is looking like it might be a bug in dnf, or something is wrong with the way dnf is used. I am still tracing dnf python code to see whitch. Oct 14 01:48:25 cap3: ah! intteresting, nicely done in nailing that down **** ENDING LOGGING AT Sat Oct 14 03:00:00 2017