**** BEGIN LOGGING AT Fri Apr 02 02:59:57 2021 Apr 02 13:40:12 if I have 2 machines that is really the same machine, but with some variations like what device overlays to load and some config.txt settings, what is the correct approach? machine B requires most of machine A, but script files related to the machine are common. should I just symlink the files in question? Apr 02 13:42:31 Ad0: can you detect at runtime which device overlays should be loaded? Apr 02 13:42:43 e.g. do you have a way to tell at runtime if it's machine A or machine B? Apr 02 13:43:20 it's raspberry pi 3b both of them but they will have different hats , thus different overlays, thus different "machines" Apr 02 13:43:52 isn't the right thing to do to have them as separate machines? Apr 02 13:44:10 they will have 2 different functions as machines as well Apr 02 13:45:16 I also have a compute module with completely different hardware etc so that's also a separate machine. but these in question are common hardware and script wise, mostly Apr 02 13:46:11 I just don't want to maintain 2 different sets of systemd services that are really the same, could you specify yocto dir search hints in the machine perhaps hehe Apr 02 14:18:04 Ad0: use MACHINEOVERRIDES to add machineA in machineB or vice-versa Apr 02 14:18:16 nice Apr 02 14:18:35 BUT, you have to know that this will make it impossible to have something specific to machineA but not machineB Apr 02 14:19:05 so, this works only if machineA is a subset of machineB Apr 02 14:20:30 or, you make a machineincAB if you want and add this to both machines' MACHINEOVERRIDES Apr 02 14:20:53 in which case machineincAB is the common denominator Apr 02 14:22:38 ok so I rename the directories that are common to machineAB from old A, and add MACHINEOVERRIDES =. "machineAB" to both A and B machine files Apr 02 14:24:12 and in the install scripts I rename do_install_append_machineA to do_install_append_machineAB Apr 02 14:24:48 that solves all my problems! Apr 02 14:24:52 thanks a lot Apr 02 14:33:23 "this will make it impossible to have something specific to machineA but not machineB" - hm that might be a problem Apr 02 14:33:54 I think machineAB is the best Apr 02 14:34:36 does machineAB have to exist in the machines dir? Apr 02 14:37:20 poky/meta/conf/machine/include/qemu.inc:MACHINEOVERRIDES =. "qemuall:" Apr 02 14:38:09 seems like it doesn't have to be an actual machine Apr 02 15:02:36 it does not have to be no Apr 02 15:02:53 don't forget the `:` character in MACHINEOVERRIDES Apr 02 15:20:17 done. thanks qschulz this worked Apr 02 15:38:23 Ad0: very welcome Apr 02 16:48:00 I'm trying to understand why http://sstate.yoctoproject.org/3.1.6/ mirror is only matched for 2% of sstate-cache on Ubuntu 16.04/20.04 for core-image-minimal for qemuarm64? only poky 3.1.6 is cloned, no dirty git Apr 02 16:52:10 is qemuarm64 built on AB? 2% could be just the native bits Apr 02 17:08:15 qschulz, yocto impresses me by it's flexibility Apr 02 17:11:41 JaMa: don't know, how am I supposed to know :p ? Apr 02 17:12:02 s/how am I supposed to know/how can I check/ ? Apr 02 17:13:21 JaMa, yes qemuarm64 is built in various configuration on the AB Apr 02 17:13:53 qschulz: I've asked the same a while ago in https://www.yoctoproject.org/pipermail/yocto/2019-June/045670.html Apr 02 17:14:22 how much of a match would we expect if glibc or gcc change? Apr 02 17:15:14 Shouldn't that be handled by uninative? (still trying to wrap my head around what this uninative thing is really doing) Apr 02 17:15:52 I don't expect any match with my builds, that's why I don't use it :) Apr 02 17:20:13 in which case is this sstate-cache mirror actually useful if even a vanilla poky does not match a good amount of it? (long story short, preparing a company training and wanted to make use of this sstate-cache mirror to quicken the setup) Apr 02 17:20:54 anyway, gotta go, discussion for next week :) happy easter to those celebrating, nice week-end to all :) Apr 02 19:05:04 * paulg wasn't going to send a patch series on April 1st. Apr 02 19:52:18 paulg, you should have Apr 02 19:54:22 People probably already have a hard enough time taking me serious as it is. :-P Apr 02 20:58:11 hi, what's proper step to rebuild for a different MACHINE ? do i have to -c cleansstate ? Apr 02 23:16:13 paulg: I'm sorry to say I don't really like those patches :/ Apr 02 23:29:00 paulg: I think in trying to avoid changing the fetcher "too much", its hurting the implementation. I think it should be possible to do this in a way which initially looks more invasive but in reality is less so... Apr 02 23:47:14 RP, ok -- well my availability will be spotty over the next few days, but I'll try and at least keep up with e-mails. Apr 02 23:50:52 fetcher specifics aside, are you at least OK with the general concept of how to share stuff? Apr 02 23:51:12 (i.e. fetch-only meta pkgs) Apr 02 23:51:24 paulg: I agree we need to share stuff. How (and if) we expose that to the user is the question Apr 02 23:51:56 paulg: the fetch only meta pkgs actually make me sad, I don't like them at all Apr 02 23:52:39 paulg: the user shouldn't need to know/care about that Apr 03 00:06:36 well, like I said in the 0/22 - until I see/hear of something better that can be made to work, this is what we've got. Apr 03 00:06:51 so I'm all ears wrt. to hearing about a better way. Apr 03 00:29:21 I was able to trace my raspberrypi4-64 accelerated graphics driver issue down to a failing IOCTL, that likely throws a permission denied in chrome Apr 03 00:29:31 it's absolutely throwing a permission denied in kmscube Apr 03 00:30:06 DRM_IOCTL_PRIME_HANDLE_TO_FD Apr 03 00:30:50 I am quickly approaching the "dog chasing the ice-cream truck" scenario where I don't know what to do with this once I've gotten here... Apr 03 00:31:42 would someone who's done slightly more kernel development than my astounding 0 hours step in, and point me in the right direction to dig into kernel source to figure out what this IOCTL is up to? Apr 03 00:33:48 I'm not really sure how to phrase my question... I think I'm just trying to figure out what this IOCTL does... and I don't really know how to find what this does in whatever version of the kernel that comes with my machine here... Apr 03 02:06:51 oh here we go! dmesg had a bunch of useful output that I hadn't caught wind of yet: https://github.com/raspberrypi/linux/issues/3416 Apr 03 02:06:57 vc4-drm gpu: swiotlb buffer is full Apr 03 02:07:56 This sounds like a thing for monday Spooster Apr 03 02:39:49 rburton: http://jenkins.nas-admin.org/view/OE/ is all red due to https://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/commit/?id=77ac2875187c285005026cdd806275914e2e873d **** ENDING LOGGING AT Sat Apr 03 02:59:57 2021