**** BEGIN LOGGING AT Thu Jun 06 02:59:57 2019 Jun 06 06:51:42 I'm hitting issues with do_package_write_rpm: Function failed: sign_rpm. Getting gpg: signing failed: Cannot allocate memory. Jun 06 06:52:42 I've tried both gnupg1 and gnupg2. Looks like there were some issues way back https://patchwork.openembedded.org/patch/142916/. Jun 06 08:50:55 halstead: this happens periodically with several of the builders Jun 06 08:51:21 halstead: this is reproducible with f30? Jun 06 08:52:23 RP, Seems to be. Check out the last 4 bringup failures. Jun 06 08:53:14 halstead: I still have http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=6357c352fcdd1b59af2d7597ba7a12cf82a4df51 around from working on this last time Jun 06 08:53:22 halstead: perhaps we'll need to do that Jun 06 08:54:14 halstead: I'm a bit surprised we can run these machines "out of memory" though Jun 06 08:54:46 RP, It's not general memory as far as I can tell. I think it's some reserved memory in the gpg-agent. Jun 06 08:56:42 halstead: I'll see if I can reproduce it by hand and then debug Jun 06 09:21:36 Name: rpmbuild.real Jun 06 09:21:36 [...] Jun 06 09:21:36 VmPeak: 84958232 kB Jun 06 09:21:43 That seems a touch high Jun 06 09:22:17 kanavin_: do you remember anything more about this signing memory issue? :/ Jun 06 09:22:34 halstead: it seems it really is general memory, not locked Jun 06 09:24:06 Oops. Okay. Jun 06 09:25:03 RP, These do have less memory than some of the workers but the same amount or more than several. Jun 06 09:27:24 halstead: I wonder if the failures we see correlate with the amount of memory in the workers Jun 06 09:27:47 halstead: we could perhaps prove this by setting the overcommit ratio on this new worker higher and see if the selftest passes Jun 06 09:27:58 * RP suspects rpm doesn't actually use all this memory Jun 06 09:28:24 RP, Yeah, I can investigate more knowing that. Hopefully 128GiB is still plenty. Jun 06 09:29:16 halstead: it can't be using 85GB Jun 06 09:31:31 halstead: echo 1 > /proc/sys/vm/overcommit_memory (just as a test, wouldn't want to run with it) Jun 06 09:31:44 halstead: I can test this in a buld quickly as I have one on the machine Jun 06 09:38:54 halstead: trying it Jun 06 09:39:13 is there a guide on how to structure your custom project for git so multiple people can use it on their local installations, by this I mean where to put the git directories of the meta modules. should they be in the poky main dir, or under your local build? should the poky be a subdir of your own project which is in git etc Jun 06 09:40:48 halstead: failed even with overcommit Jun 06 09:48:12 * RP tries turning off the compression parallelism Jun 06 09:49:11 Ad0: nothing in poky. Everything that is not yours, you don't touch it. This includes cloning layers into upstream layers that you previously cloned. Jun 06 09:51:32 still dies Jun 06 09:51:56 Ad0: If you need a way to have an easy setup process, you can have a look at repo from Google for example or maybe git submodules I guess Jun 06 09:54:10 thanks Jun 06 09:54:33 qschulz, when I look at tutorials etc, 99% of them clone inside the poky dir Jun 06 10:13:52 Ad0: they're wrong. Jun 06 10:14:06 thanks, I thought I was insane Jun 06 10:14:26 Ad0: using repo/submodules/whatever clone bitbake, oe-core, and whatever other layers you want. Jun 06 10:15:28 thanks. want to find a git repo I can look at Jun 06 10:15:37 some have the poky outside, some have poky as one of the subdir Jun 06 10:16:05 some have it as a layer, some have it as a "project" Jun 06 10:16:36 Ad0: https://github.com/rossburton/customdistro Jun 06 10:16:46 thats using submodules Jun 06 10:16:54 Googlehttps://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles Jun 06 10:17:12 see? even the yocto wiki suggest adding it to the yocto main dir /home/user/yocto/poky-jethro-14.0.0/meta-example Jun 06 10:17:39 thanks rburton Jun 06 10:20:02 yeah we need to burn the wiki to the ground Jun 06 10:20:18 hahaha Jun 06 10:20:37 it's very flexible so it needs to be restructured Jun 06 10:20:48 I mean it can be structured in so many ways Jun 06 10:48:03 Hi, I am working on a custom layer for nanopi neo plus 2. I tried to activate the i2c and saw that it was "desactivated" in the devicetree. I modified the device tree inside yocto to enable it but it isn't working. Here is an abstract of my "updated" device tree: https://pastebin.com/rS4pwuSR Jun 06 10:48:41 And here is my linux-mainline_%.bbappend: https://pastebin.com/kaHsReC7 Jun 06 10:53:44 xade: patch the DTS and include that patch in SRC_URI Jun 06 10:55:45 @gshulz my way of overwriting the DTS is not correct? Jun 06 10:58:47 Not really, what happens if you update the kernel without touching this bbappend or your patched dts? Best case scenario it does not compile and you can fix it, worst case scenario, you spend hours trying to find out why the new kernel is not working or why such device should be present and is not Jun 06 10:59:58 Most of the time, you want to patch files in Yocto, it's way easier to detect possible errors when updating to newer versions Jun 06 11:01:33 OK. Understood, but with what I have, I assume that with a patch or override, it's the same stuff and as my override doesn't work, the patch will not work neither Jun 06 11:11:27 A patch would be easier for people to read and help you. Because I don't know what you changed exactly. I also don't have the original kernel sources Jun 06 11:12:23 You might have added status="okay", but it might be overriden somewhere else, or it depends on a pinctrl that is already muxed in another mode, or using a gpio that is already requested by someone else, or depending on another driver that isn't compiled/probed Jun 06 11:13:04 You can use devtool with the Linux kernel to see if it's correctly applied Jun 06 11:13:45 xade: YSe patch to dts would be preferred (I'm comaintaining meta-sunxi and we're doing it same way) Jun 06 11:13:47 it also helps to modify directly the sources without having to create patches or update the recipe, pretty helpful when in early stages Jun 06 11:19:15 @opennandra : I am using meta-sunxi to use the nanopi neo plus 2 but I am trying to make i2c (and bluetooth) work.... Jun 06 11:20:07 I unserstand that the patch is the best way. But a patch or an override are similar from a technical point of view (not maintainability). Jun 06 11:20:15 xade: yes this is fine jus twant to say if you want change dts patch is best way Jun 06 11:20:42 xade: well you want to change kernel from meta-sunxi so it's only way with bbappend Jun 06 11:21:50 @opennandra : so my bbappend to linux-mainline is correct? Do you have an idea why the i2c is not working? Jun 06 11:22:44 xade: bbappend is OK you just need to patch dts (if necessary). If you have issue pls write new issue on github meta-sunxi so we can llok Jun 06 11:24:29 @opennandra : I assumed the issue is on my side so I don't think the issue on github is the correct way :-D Jun 06 11:25:04 xade: OK but we can help if necessary Jun 06 11:26:17 I'd suggest to make sure the patch is actually applied. If it is, then head to linux-sunxi for example and debug with them the patch. You'll need the complete bootlog Jun 06 12:58:47 Can Yocto build SDK for bare-metal system (w/o operating system)? Jun 06 12:59:03 OK! thank you everybody! I will go to meta-sunxi as it is more linked to yocto build Jun 06 13:00:13 alessioigor: please describe "SDK for bare-metal system" Jun 06 13:00:16 #linux-sunxi for the kernel actually Jun 06 13:00:59 alessioigor: it has been used as the vehicle for zephyr which is basically a bare-metal system, but you probably are rather looking for something like crosstool-ng or such, then. Jun 06 13:01:06 alessioigor: and, what mckoan said :) Jun 06 13:16:03 A toolchain for generate code for an MCU or CPU which are intended to work without any operating system. Jun 06 13:17:00 you want crosstool-ng. Jun 06 13:19:47 or a Linaro toolchain Jun 06 13:20:05 which is probably generated with crosstool-ng in some form Jun 06 13:20:31 which is the same approach used by OE/Yocto Jun 06 13:22:14 yeah of course, but why 1) beat the crosstool approach into shape so it fits the larger OE approach and then 2) beat OE into shape so it resembles crosstool again, when you can just do 0) use crosstool for exactly its intended usecase? Jun 06 14:25:37 hi, can I run any kind of script when set in ROOTFS_POSTINSTALL_COMMAND variable? Jun 06 14:36:15 alessioigor: yes you can build without an os Jun 06 15:05:36 rburton: Ok thanks. Jun 06 15:28:43 dropping from bug call Jun 06 15:34:13 RP: are we still running ptest for core-image-sato and core-image-sato-sdk (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13293) ? Jun 06 15:34:13 Bug 13293: normal, Medium+, 2.8 M1, unassigned, NEW , libxml-parser-perl ptest results are inconsistent per image Jun 06 15:34:53 RP: curious if it is missing ${PN} as I suggested or missing BBCLASSEXTEND nativesdk Jun 06 15:36:12 RP: Is this title better: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13378 ? Jun 06 15:36:13 Bug 13378: normal, Medium+, 2.8 M2, JPEWhacker, NEW , native programs from RSS that alias hosttools can cause non-reproducible builds Jun 06 15:36:15 moto-timo: that is fixed now Jun 06 15:36:52 JPEW: much, thanks! Jun 06 15:44:05 moto-timo: I think the perl dependencies were the final pieces needed Jun 06 16:47:51 armpit: yup. Got it Jun 06 16:53:57 k Jun 06 17:13:13 New news from stackoverflow: Yocto for Nvidia Jetson fails because of GCC 7 - cannot compute suffix of object files **** ENDING LOGGING AT Fri Jun 07 02:59:57 2019