**** BEGIN LOGGING AT Tue Dec 22 03:00:27 2020 Dec 22 05:14:00 morning, or perhaps still night Dec 22 07:06:22 yo dudX Dec 22 07:51:15 good morning Dec 22 07:51:19 hi LetoThe2nd Dec 22 07:52:21 howdy mckoan Dec 22 09:16:31 greetings Dec 22 09:50:36 mornings Dec 22 10:10:04 halstead: hello there. Was wondering if you ware aware of https://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core not working? (with an additional trailing /, it works)? Dec 22 11:57:07 hi there folks! Dec 22 11:59:30 nopunchman: hi Dec 22 13:22:06 qschulz, I believe that is intentional. Where did you find a link without the trailing / present? Lets get that updated. Dec 22 13:22:49 halstead: why is this intentional? Dec 22 13:23:36 halstead: just aiming for consistency in yocto-docs and having the trailing slash isn't very neat :) Dec 22 13:24:35 qschulz, I'm not sure why. What I mean is the behavior it isn't due to misconfiguration. Dec 22 13:25:42 qschulz, I can catch it at the webserver and redirect if it makes the docs cleaner. Dec 22 13:25:46 halstead: ok :/ at least I tried :) Dec 22 13:26:07 halstead: I mean, to be discussed with ndec/RP obviously but why not? Dec 22 13:27:22 halstead: so basically we have extlinks in Sphinx which are just a way to build links, e.g. 'oe_git': ('https://git.openembedded.org%s', None), with :oe_git:`/meh` will output https://git.openembedded.org/meh Dec 22 13:27:45 qschulz, Nobody has asked and as far as I know there were no links that didn't conform. Dec 22 13:28:57 we have a leading slash already which isn;'t the best but not the question Dec 22 13:29:38 https://lists.yoctoproject.org/g/docs/topic/patch_v2_2_6_documentation/79145982 but now we have this Dec 22 13:29:41 (soon) Dec 22 13:29:51 'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None), Dec 22 13:30:14 which means if we want to point to meta-qt5 for example, we need to have both a leading space (for now) and a trailing space Dec 22 13:30:18 which is different from the others Dec 22 13:31:45 we could technically have 'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s/', None), instead actually... Dec 22 13:32:18 but the day we remove the leading space (which we probably aim for with ndec?), then we'd have 'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer/%s/', None), Dec 22 13:32:44 which looks quite nice to me, no? Dec 22 13:32:46 and then the "empty" link for pointing to the layer tab in the layerindex and not pointing to a layer directly, would have two slashes Dec 22 13:33:05 ah, right. Dec 22 13:33:40 I mean, it's nitpicking right but if there;s an easy fix server-side, why not? Dec 22 13:35:20 i agree.. there is no reason why the server would "require" a leading slash to work.. Dec 22 13:35:39 it's uncommon to have such a limitation. Dec 22 13:36:25 qschulz, I just set https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-APPEND_SLASH True and the behavior is the same. Hrm. I can make nginx do it instead, Dec 22 13:41:31 it's True by default according to the docs so not surprised :/ Dec 22 13:45:14 qschulz, I'm added a rewrite that will cover all the layers. Dec 22 13:46:08 qschulz, I don't know if it's worth opening a bug about the CommonMiddleware APPEND_SLASH not working. Dec 22 13:46:26 qschulz, Glad to help with cleaner docs :) Dec 22 13:48:30 halstead: thanks :) Dec 22 13:50:34 halstead: wait :D Dec 22 13:50:48 never mind Dec 22 14:03:43 halstead: not sure how picky we want to be but https://layers.openembedded.org/layerindex/layer/xxx does not work but https://layers.openembedded.org/layerindex/layer/xxx/ does. And probably we want the same mechanisms for machines, distros, and classes? basically, probably append a trailing slash to all URLs starting with https://layers.openembedded.org/layerindex? Dec 22 14:04:36 (and layers) Dec 22 14:20:16 ndec: probably want to comment when you have some time on my answer to paul (specifically the TL;DR at least). no hurry though but don't want to make him do changes you disagree with Dec 22 14:26:04 ndec: https://lists.yoctoproject.org/g/docs/message/791 (forgot to give context :) ) Dec 22 14:26:51 looking now.. Dec 22 14:31:46 qschulz: argh.. i have the feeling we are making things more difficult than they should ;) Dec 22 14:32:35 yes, that was my feeling too.. BUT CONSISTENCY, so my brain picked the more difficult thing :) Dec 22 14:32:44 even using branch/master in the extlinks definition might not be good.. we might want (sometimes) to use branch/VERSION instead! Dec 22 14:33:08 ndec: indeed Dec 22 14:33:33 we've to settle for something now I think so we don't make it too hard on Paul and then we can take some time to make it neater later on? Dec 22 14:33:47 yes. i agree. Dec 22 14:33:49 but obviously , this opens the possibility that we won't have a look at it later Dec 22 14:34:29 yes, of course. this is how things work ;) Dec 22 14:34:58 if we open a BZ about it, then at least we will get an annoying reminder Dec 22 14:35:11 ah right, I always forget about BZ Dec 22 14:35:45 shooting for :oe_layer:`meta-foo` is a good thing. Dec 22 14:35:47 well, then let's tell Paul we go for the TL;DR to have something working at least :) Dec 22 14:36:04 yes, i am going to reply that. Dec 22 14:36:05 :oe_layer:`/` needs to be fixed anyway Dec 22 14:36:25 :oe_layer:`<>` too, well what I wrote in the TL;DR :) Dec 22 14:36:34 ndec: thx for having a look so quickly! Dec 22 14:37:25 another option would be to leave layer/ out of extlinks. so that we can do layer/meta-goo or layers or recipe/xxx Dec 22 14:37:57 mmm.... not bad of an idea Dec 22 14:38:12 we still need the branch though Dec 22 14:38:21 (that's another topic anyway) Dec 22 14:38:43 but yeah, that's better I think. nice suggestion and much easier to maintain Dec 22 14:38:49 and understand Dec 22 14:39:09 but, as we said, let's unblock paul for now. Dec 22 14:39:54 👍 Dec 22 15:10:02 * paulbarker reads what ndec & qschulz said above Dec 22 15:11:01 qschulz, ndec: All sounds good. I'll send a v3 Dec 22 15:20:21 paulbarker: it'll teach me to suggest things without testing first :) thx for the patches and your patience Dec 22 15:23:24 qschulz: No problem :) Dec 22 15:25:31 qschulz: Just re-running linkcheck now and making sure everything is as clean as it can be Dec 22 15:31:19 v3 sent Dec 22 15:31:34 One bug left to go then I'm done until new year Dec 22 15:35:25 paulbarker: happy holidays then :) Dec 22 15:43:46 i'll be talking about multiconfigs in about 17 minutes: https://www.twitch.tv/theyoctojester Dec 22 15:43:47 16:43 find yourself a drink and get comfy Dec 22 15:45:11 will you have a drink? Dec 22 15:46:48 of course. Dec 22 15:47:54 rburton: there hasn't been a single live coding session where id didn't have a drink. Dec 22 15:48:00 awesome Dec 22 15:48:03 * LetoThe2nd feels mightily proud Dec 22 15:49:23 it's important to have some constant values in your life. Dec 22 15:55:02 just to confirm there is no weekly call today? Dec 22 15:55:07 correct Dec 22 15:55:27 cool, maybe i'll see what this twitch thing is… Dec 22 15:55:37 hehe means you can all watch me screw things up and drink. Dec 22 15:57:52 hurry up now! click here -> https://www.twitch.tv/theyoctojester <- click here Dec 22 15:58:39 i'm so excited Dec 22 15:58:55 want me to find you the lordi version of it again? Dec 22 15:59:55 https://youtu.be/fVrl_bYIna0 Dec 22 16:08:43 https://github.com/raspbernetes/k8s-cluster-installation Dec 22 16:08:48 hi all Dec 22 16:08:49 interesting Dec 22 16:17:32 hello, i have managed to totally baffle myself and i'm not even sure where to start looking to figure out how to fix my issue so i am here hoping someone can give me a clue :) Dec 22 16:18:47 i am building a poky derivative using crops/poky and when i run it on my workstation it builds fine but when i try and run it on my CI server my build fails at the very end trying to do "write_pixbuf_cache" for all my images Dec 22 16:19:56 when i dig into the logs, it looks like for a local build it does not even try to do this, but on the CI server, it always tries to do this for all images Dec 22 16:21:30 exact error is: /work/build/tmp/work/raspberrypi4_64-bantha-linux/bantha-initramfs-image/1.0-r0/intercept_scripts-0858c5d68b427e6a74413dd2b7ab9415d0b032ee6bcd7b213f3843bdc9d83346/update_pixbuf_cache: line 11: Dec 22 16:21:30 /work/build/tmp/work/raspberrypi4_64-bantha-linux/bantha-initramfs-image/1.0-r0/rootfs/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/../loaders.cache: No such file or directory Dec 22 16:22:55 my images do not contain gdk-pixbuf, nor do they contain any other graphical components - i tried doing `bitbake -e my-image` on both places and diffing the result, didn't see anything other than path/timestamp differences, permissions all look good, running the same docker-compose.yml at both places so tooling/environment should be the same, don't Dec 22 16:22:56 know what to poke at next Dec 22 16:25:51 The eSDK allows to ship an SDK to the customer so that they can build their own application, without having to rebuild the bootloader and kernel for example, correct? Dec 22 16:25:59 tried totally dumping all my caches and downloads even, happens consistently on the CI server even on a fresh build - i have total control of the CI server so i can do whatever's needful Dec 22 16:32:01 ok hmm, inside my intercepts_scripts directory, locally everything is -x, on the CI server everything is +x Dec 22 16:32:26 same scripts in both but they're not executable in the environment that works Dec 22 16:38:08 interesting, same in poky/scripts/postinst-intercepts in my checkout, all 0755 on the failing machine and 0644 on the one where it runs correctly Dec 22 16:39:27 in fact it seems like EVERYTHING in the checkout on the CI server is +x, i think i found the problem... Dec 22 16:54:55 ok, i think i fixed it, thanks for listening :D Dec 22 17:22:04 Hey, I seem to have an issue with u-boot. I'm using an Orangepi Zero here and when I pull the plug from the device and repower it, the bootload hangs. https://pastebin.com/PmhdrW53 Dec 22 17:23:28 It says "Loading Environment from MMC... OK" which is a little strange given that the device does not come with eMMC. Or can MMC also mean SD card? Dec 22 18:24:08 i want a FILES_${PN} directive to be optional based on a value in DISTRO_FEATURES Dec 22 18:26:04 do i do some sort of ${@bb.utils.??()} in the string? Dec 22 18:26:40 FILES_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'feature', ...)}" ? Dec 22 18:27:13 or do i do some sort of do_package_append() ? Dec 22 18:31:24 hmm conversely, if the objects in a FILES_${PN} don't exist, bitbake doesn't complain Dec 22 18:31:53 so i guess that's a form of conditional processing Dec 22 18:39:27 armpit: i see meta-odroid supports the N2, any idea of that applies to the N2+ as well? Dec 22 18:52:19 armpit: nevermind, i see linux-stable has a dts file for the n2-plus, so support shouldn't be too hard to add, and it would be separate Dec 22 19:51:50 tlwoerner, I hope so. I just got the N2+ Dec 22 19:52:06 u-boot is more on a issue Dec 22 19:54:59 armpit: cool! i *just* ordered the N2+, looking forward to trying out that Mali-G52 with panfrost ;-) Dec 22 21:00:42 hi Dec 22 21:01:46 I'm looking for a way to make a separate yocto base image, with an overlay image with selected packages (and their dependencies that are not included in the base image) Dec 22 21:02:23 so that the overlay image can be mount ontop of the base image with overlayfs, extending it Dec 22 21:02:38 is there a standard or otherwise "nice" way to do it? Dec 22 21:15:13 I have an idea to use rootfs from the "base" image during do_rootfs of the "extended" image, with overlayfs already mounted with empty writable upperdir Dec 22 21:15:50 so that the things that are changed will be properly handled by the overlayfs itself Dec 22 21:16:32 that however requires root privileges to mount the overlayfs during build Dec 22 21:17:51 and also I'm not quite sure if the rootfs will always be enough to tell the package manager that the "base" packages are already present (if the image is build without internal package management, for example) Dec 22 21:39:04 another idea would be to build both "base" and "extended" image separately, then, maybe outside of the yocto build process, overlay mount the base image and use a tool like rsync to apply the differences to the mount Dec 23 00:28:01 https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/00-README says, I should talk to linux-yocto@yoctoproject.org but the page seems outdated Dec 23 00:28:37 I want to add y patches to yocto-kernel-cache... which mailing list should I post to? **** ENDING LOGGING AT Wed Dec 23 02:59:56 2020