**** BEGIN LOGGING AT Wed Jul 31 02:59:56 2019 Jul 31 05:46:53 aehs29: i can confirm that. Jul 31 06:01:59 New news from stackoverflow: Embedded Linux distro for Android hardware Jul 31 06:32:04 New news from stackoverflow: How to specify linker option to not use a particular address space while generating the vmlinux kernel Image? || Embedded Linux distro for Android hardware [on hold] Jul 31 06:49:30 good morning Jul 31 06:51:32 mckoan: good morning to you too Jul 31 07:43:24 ugh, yocto 2.8 will be called 3.0. managers will freak out :) Jul 31 07:44:46 mcfrisk: just tell them we have decide to switch over to base-9 encoding for version numbers. :) Jul 31 07:46:35 I think will not even mention the version number change. hide it, maybe they will not even notice... Jul 31 08:02:38 Looking forward to using "Yocto for Workgroups". Jul 31 08:29:24 aehs29: no personal experience then? :) Jul 31 08:32:33 RP: nothing like riddling over code written while being drunk, which works but you totally can't understand why. Jul 31 08:53:36 LetoThe2nd: you've looked at runqueue?! :) Jul 31 09:00:24 RP: no, but equivalents of my own. back in the time. Jul 31 09:03:16 Hello everyone! Jul 31 09:03:16 I am starting to use Yocto Project. Can you recommend a good book? Jul 31 09:04:45 LyzV: i can recommend the video series on youtube, the first one is a rundown af the getting started tutorial. and i can recommend joining me on twitch on Aug 13th, 17:00 Eurpo/Berlin time for a session covering the very same topics. Jul 31 09:04:49 :) Jul 31 09:05:11 LyzV: plus, rudi streifs book is probably the one to be recommneded these days. Jul 31 09:08:47 Thanks for the book. Can you give a link to the video? Jul 31 09:09:18 should be https://www.youtube.com/watch?v=EfKLrSxA_H8 Jul 31 09:11:51 Thank you very much. I will study Jul 31 09:12:37 hi guys Jul 31 09:13:23 I'm going to add host Wifi AP functionality to my OrangePi board Jul 31 09:13:34 how can I do that? Jul 31 09:14:09 looks like I should add "hostapd" layer to my configuration Jul 31 09:14:13 Ded_Zerom: probably by adding something like hostapd http://layers.openembedded.org/layerindex/recipe/28409/ Jul 31 09:14:16 am I right? Jul 31 09:14:22 Ded_Zerom: and then cofiguring it accordingly Jul 31 09:14:34 ok, thanks Jul 31 09:15:09 * alessioigor waves all Jul 31 09:15:13 Could you pinpoint me to appropriate docs about using qemu shipped with the SDK generated with populate_sdk? Jul 31 09:15:16 Thanks! Jul 31 10:50:25 mario-goulart: Yocto NT? Jul 31 11:34:47 hey guys, I am trying to have so ipk signed by gpg. I keep having error where gpg fails. I think this is because we are attempting to sign too many packages at once. I have no problem signing individual packages. From a little google i found that there should be a variable to set the number of packages signed at once.(sign_chunk?) I cant find thou Jul 31 11:34:48 gh the name of this variable. Anyone have a clue about it? Jul 31 11:57:25 sign_chunk is an internal argument when signing RPMs Jul 31 11:58:20 ipkg is signed as they're generated Jul 31 11:58:47 (package_ipk.bbclass, search for sign_ipk) Jul 31 12:23:13 RP: is there a reason that buildertorepos only contains a subset of the builders? Jul 31 12:30:56 tgoodwin: it has a default ? Jul 31 12:35:16 RP: Yeah, that was a poorly-worded question. I'm trying to understand the duplication of data between config.py and config.json so I can come up with a strategy for setting up new builds. Jul 31 12:37:12 RP: RP: where I suppose I'm confused is the a-quick trigger build for example seems to contain a superset of repo dependencies for all the triggered builds rather than those triggered builds having their own independent relationships. Jul 31 12:38:35 tgoodwin: a-quick does a checkout of the repos up front so it has to know which repos they use Jul 31 12:39:43 tgoodwin: I think it has safe fallback in that any extra repos would just be cloned if not central though Jul 31 12:40:02 tgoodwin: it does mean all the different builders get the same revision Jul 31 12:44:59 RP: alright I think I followed you on that one. And it looks like repo-defaults is only really used by the janitor. Jul 31 12:55:03 RP: Do you have a recommendation for how to define builders that only build against tagged poky releases? Jul 31 12:55:48 The way it looks to me is I would have to have thing-a-thud, thing-a-warrior, etc. as builders that share a common template and then use overrides to manipulate the source revs. Jul 31 12:58:53 tgoodwin: why not just select that in the force scheduler? Jul 31 12:59:09 tgoodwin: you want to have targets which pre-select the release? Jul 31 13:02:37 RP: I forget where I saw this recommendation in the mega manual, but it implied that if you want to create an sstate cache and downloads mirror for a team, you should stick with tagged releases. And from a training event last year, we should/could not re-use the same sstate cache location for multiple releases of poky. Jul 31 13:03:09 tgoodwin: I don't know who is saying that but reusing the same sstate cache location is fine Jul 31 13:03:22 RP: I wish I could remember the trainer's name. Jul 31 13:03:28 tgoodwin: the only potential downside is knowing when to clean up files which is why you may want a separate dir Jul 31 13:04:11 the reason for sticking with tagged releases is just to try and control cache size Jul 31 13:04:20 its not a hard/fast rule Jul 31 13:04:58 RP: alright, thanks. If I were to force a build to a tagged release, would I need to mark that build itself as a release in that panel? Jul 31 13:05:44 tgoodwin: no, that is about generating a release, not building one Jul 31 13:06:00 that is something we as the project need to do to publish one Jul 31 13:07:55 Alright Jul 31 13:33:13 New news from stackoverflow: Yocto OpenCV w/ GStreamer installation issues Jul 31 13:44:19 RP: Do you have a suggestion for a situation where a certain branch of a repo has different layers to add? Example, meta-xilinx's transition from sumo to thud added meta-xilinx-standalone, so a builder defined to add that layer in will fail on earlier revisions. Jul 31 14:01:24 tgoodwin: not offhand Jul 31 14:26:00 Hey everyone, I am bitbaking my image and do_rootfs is failing with dnf saying packages need more space on the filesystem I've already configured IMAGE_ROOTFS_EXTRA_SPACE to be big enough. Any thoughts? Jul 31 14:29:24 frog_gy: which image type is it supposed to be? Jul 31 14:30:06 It's a custom image, i'm not using core-minimal or anything like that Jul 31 14:30:19 image fstype, i mean. Jul 31 14:30:28 how can I check? Jul 31 14:30:55 well you hopefully chose it somewhere. if not explicitly, then implicitly with a machine config. Jul 31 14:31:13 grep for IMAGE_FSTYPE in bitbake -e of your failing build Jul 31 14:32:16 looks like it's tar.gz Jul 31 14:33:33 RP: Any ideas why force build defaults to master branches even though in config.py I've changed all branches to thud? I'm having a hard time finding where this is coming from. Jul 31 14:34:30 never mind -- schedulers. Jul 31 14:34:42 frog_gy: strange, tar.gz should not be space restricted in any way as far as i know. can you check if its not accidentally your hard drive filling up? Jul 31 14:35:29 frog_gy: so rpm has a bug where it looks at the wrong file system Jul 31 14:35:35 frog_gy: what release are you using? Jul 31 14:36:31 yeah 500 GB remaining, I snooped through our base-image.inc and we seem to IMAGE_FSTYPES_remove = " ext4", how about that? Jul 31 14:36:40 actually that doesn't seem to be it. :-/ Jul 31 14:36:55 rburton: yocto rocko Jul 31 14:39:22 hm can't seem to find the relevant fixes, i bet kanavin can remember where the fix for rpm/dnf saying the filesystem was full is Jul 31 14:40:14 I've confirmed there's a limitation somewhere, I've removed some layers yesterday to make space and it built just fine. Jul 31 14:45:09 tgoodwin: repos table in config.py? Jul 31 14:46:02 tgoodwin: default=config.repos[reponame][0] ? Jul 31 14:46:03 Yes, that was it. I skipped one. Jul 31 14:46:15 (in config.py) Jul 31 14:49:15 ERROR: Nothing RPROVIDES 'systemd-analyze' (but /home/dev/Documents/yocto/poky/meta-gumstix-extras/recipes-images/gumstix/gumstix-console-image.bb RDEPENDS on or otherwise requires it)NOTE: Runtime target 'systemd-analyze' is unbuildable, removing...Missing or unbuildable dependency chain was: ['systemd-analyze']ERROR: Required build target 'gumsti Jul 31 14:49:15 x-console-image' has no buildable providers.Missing or unbuildable dependency chain was: ['gumstix-console-image', 'systemd-analyze'] Jul 31 14:49:25 oops - sorry for adding that without context Jul 31 14:50:14 I am trying to build a minimal image - bitbake gumstix-console-image - for the gumstix poblano board and i keep getting the above errors. Any pointers on where i can look to resolve those? Jul 31 14:52:38 FailDev: It looks like your missing a recipe for 'systemd-analyze' Jul 31 14:56:41 FailDev: are you sure that the layer versions are coherent? Jul 31 14:59:18 frog_gy Thanks - I wonder how i missed that recipe. LetoThe2nd when i pulled the repo i used the meta gumstix manifest guide and used repo to check out the rocko branch. Also nice videos on YT Jul 31 14:59:29 FailDev: systemd-analyze is built by systemd Jul 31 15:00:24 FailDev: so sounds like you need to use systemd Jul 31 15:01:14 rburton: if they offer a specific layer combination then i'd actually expect the distro to properly configure that. Jul 31 15:01:28 you'd expect that yes Jul 31 15:01:32 maybe they don't offer a distro Jul 31 15:03:39 that i would expect when they only offer a bsp layer. but for a coherent stack, it should be part of the deal. Jul 31 15:16:08 I tried changed the IMAGE_FSTYPE from tar.gz to tar.bz2, dnf still throws an error Jul 31 15:33:34 New news from stackoverflow: Failure while compiling apt - Yocto Jul 31 16:08:05 rburton, frog_gy this was reported several times, but no one actually digged down to the bottom of the issue, and I have never seen it locally or on the autobuilders Jul 31 16:08:14 we have an open bug for it Jul 31 16:08:15 hm Jul 31 16:08:27 Just finished trying with ext4 IMAGE_FSTYPE, dnf still needs more space. I'm starting to think it's not the IMAGE_FSTYPE Jul 31 16:08:31 that would be why i couldnt' find the patch Jul 31 16:08:33 frog_gy: its not Jul 31 16:09:01 aha Jul 31 16:09:02 https://bugzilla.yoctoproject.org/show_bug.cgi?id=12439 Jul 31 16:09:03 Bug 12439: major, Medium, 2.99, mingli.yu, ACCEPTED , do_rootfs fails with disc space (dnf) although there's enough space left Jul 31 16:09:23 frog_gy, it's dnf and/or rpm being confused about how much space there is on your host machine (which is likely using multiple partitions, and some of them may be nfs) Jul 31 16:09:36 the bug should have suggestions for debugging Jul 31 16:10:39 possibly its fixed in master due to a rpm/dnf fix that sneaked in Jul 31 16:10:50 which would explain why eg mingli can't reproduce Jul 31 16:38:04 If using a .wks.in file, it would seem we could re-generate things with wic, if the finalized .wks file was written to the deploy directory. Jul 31 16:39:58 I am not sure that wic searches the deploy directory for the wks files today, but it might be nice when using a wks.in file that has been generated to have it in the list of images for "wic list images" Jul 31 16:48:03 RP: If using ADDLAYER in a template, does it need to be within a step? I'm having an odd issue where I end up with parsing errors when add-layer is run even though those layers are fine. Jul 31 16:49:36 I also have another weird issue where it sometimes only adds one of the layers out of the list. Jul 31 16:50:48 tgoodwin: I think its designed only for the top level and not per step but I don't remember exactly Jul 31 16:52:18 The example ones in the config.json they're all in steps but given the structure of templates vs. overrides and defaults, it seemed like it would work at the top level. I'm getting the same result either way, where the add layer fails when trying to get BBFILE_COLLECTIONS. Jul 31 17:09:27 This is so weird. The stdio error log indicates that it failed to add any of the layers but my bblayers.conf file shows at least one of them passed. Jul 31 18:05:32 RP: I've tried scaling it back to how y'all have the meta-oe but I get the same error. I think the reason this error would not show up in that config is meta-openembedded isn't in the repo-defaults of the JSON. Jul 31 18:20:48 RP: I figured it out. It looks like if I add a layer with dependencies to NEEDREPOS, it breaks any ADDLAYER calls that satisfy those dependencies. Jul 31 18:21:57 tgoodwin: hmm, sounds like a bug somewhere? :/ Jul 31 18:22:57 The only work-around is to use no-layer-add even though the behavior of NEEDREPOS layer-config would have worked. It's like this mechanism was meant for repos that contain several layers. Jul 31 18:27:23 That or disable/remove that feature from the layer-config script (last 4 lines) so that ADDLAYER has the sole responsibility for calling "bitbake add-layer" Jul 31 18:29:53 RP: Reminder: Respond to the reproducible build email Jul 31 18:31:37 how do i stop systemd from creating etc/systemd/system/getty.target.wants/getty@tty1.service ? Jul 31 18:31:44 USE_VT = 0 ? Jul 31 18:32:05 khem: how is libedit needed if i'm building llvm without it? Jul 31 18:33:33 rburton:its needed for option processing Jul 31 18:34:13 it might only make use for llvm-native for now Jul 31 18:34:33 but there are many uses of libedit within oe-core I See and are currently using packagconfig to disable it Jul 31 18:35:18 and there are uses in meta-oe and meta-networking as well Jul 31 18:35:36 ok Jul 31 18:35:41 this library certainly is a good candidate for oe-core regardless of llvm Jul 31 18:36:05 llvm/clang 9.x work is tipping point for me to propose it. I have avoided it so far Jul 31 18:36:12 but cant no more Jul 31 18:37:41 ah is it a requirement instead of optional for the new llvm? Jul 31 18:51:47 behanw: you around? Jul 31 18:52:44 RP: my experience is mostly with whisky tbh, especially after Edinburgh haha Jul 31 18:55:28 RP: Would you be open to a modification of layer-config (NEEDREPOS) behavior that would handle names in that list having a /? For example, a build would have meta-openembedded/meta-oe. The layer-config would copy over meta-openembedded and then do the add-layer against the full name. Jul 31 19:59:38 tgoodwin: I just had to look at the code to refresh my memory but yes, we probably need to do something. I'm a little puzzled about how meta-openembedded works at all currently Jul 31 20:05:39 How can I build and deploy two different git repos in a single bb recipe? Jul 31 20:06:45 An example would be great/ Jul 31 20:09:29 put both git URLs in SRC_URI Jul 31 20:10:18 with destsuffix set so they both don't try to clone into git/ Jul 31 20:10:48 ie vulkan-demos in oe-core: Jul 31 20:10:49 SRC_URI = "git://github.com/SaschaWillems/Vulkan.git \ Jul 31 20:10:50 git://github.com/g-truc/glm;destsuffix=git/external/glm;name=glm \ Jul 31 20:10:50 git://github.com/g-truc/gli;destsuffix=git/external/gli;name=gli \ Aug 01 00:04:55 New news from stackoverflow: How do I include boost/beast/core.hpp in my bitbake recipe? I used DEPENDS = "boost" which works for many boost libraries, but not beast **** ENDING LOGGING AT Thu Aug 01 03:00:25 2019