**** BEGIN LOGGING AT Thu May 21 02:59:57 2020 May 21 03:00:06 kergoth: it will just cause rebuilding of things between the DISTRO_FEATUREs possibly? May 21 03:09:28 alrighty May 21 09:14:00 kergoth: fair enough, thanks May 21 11:29:16 kanavin_home: around? May 21 11:33:42 kanavin_home: as soon as I asked that I managed to figure out what I was going to ask! :) May 21 12:01:21 RP: I could reproduce the sstate-cache issue between debian 10 and opensuse 15.1 from scratch May 21 12:16:59 tldr: debian has SONAME of 'libbz2.so.1.0' while suse has 'libbz2.so.1' and our very own bzip2-native has also libbz2.so.1 . May 21 12:16:59 So rpmgen fails as even with bzip2-native present, we're relying on the debian lib with the 'bad' SONAME May 21 12:52:00 dl9pf: this sounds worrying, I'm not sure I follow exactly what is happening May 21 12:52:33 dl9pf: you're saying depending on which host you build upon, SONAME is different? May 21 12:52:34 I'm writing a bugzilla entry and see if an addition to DEPENDS fixes it. May 21 12:53:02 yes. debian has a different soname here ... I need to verify why, but that is the case here. May 21 12:53:11 dl9pf: oh, I see, the lib name is different on the two hosts May 21 12:53:31 dl9pf: make sure to use DEPENDS = "bzip2-replacement-native" May 21 12:53:39 it seems to creep into the sstate-cache May 21 12:53:54 dl9pf: yes, it will :( May 21 12:54:19 dl9pf: try the DEPENDS, that should fix it as long as its the replacement version May 21 12:54:49 I'd guess our test worker doesn't have bz2-devel installed on it May 21 12:55:24 yes, I assume we miss this for file-native then May 21 12:55:24 See: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13915 May 21 12:56:14 this is where I could track the libbz2.so.1.0 down to May 21 12:57:46 dl9pf: yes, it looks like file-native needs that May 21 12:58:32 this is on dunfell, but master recipe is similar May 21 12:59:24 renamed the bug accordingly May 21 13:00:16 dl9pf: can you send a patch? :) May 21 13:00:33 I'll try my best to not screw git send-email up May 21 13:05:22 dl9pf: thanks! May 21 13:47:34 RP: you're welcome ;) May 21 14:18:33 RP: patch is there ... seems like patchwork marked the dunfell branch as v2 of the master branch patch May 21 14:20:59 https://patchwork.openembedded.org/patch/172742/ is for master May 21 14:21:05 https://patchwork.openembedded.org/patch/172743/ is for dunfell May 21 14:49:50 rburton: is bitbake -c cve_check supposed to work on fresh checkout ? ( without running do_fetch ) May 21 14:53:30 khem: i thought it should May 21 14:58:05 rburton: it seems to fail for recipes which are fetching patches May 21 14:58:07 e..g. bash May 21 14:58:11 hm May 21 14:58:21 yeah it wants to read the patches May 21 14:58:31 right so they should be downloaded May 21 14:58:33 can you add a 'after do_fetch' to the class please :) May 21 14:58:40 or unpack, or whatever May 21 14:58:48 most of patches are part of metadata so it kind of works in most cases May 21 15:02:37 rburton: does this class need access to full source tree of component ? May 21 15:02:50 no May 21 15:03:00 just the patches so it can scan them for CVE headers May 21 15:03:11 right ok then `after do_fetch ` should be enough then May 21 15:03:16 i guess it could only do that for local patches May 21 15:03:24 and if the patch is remote, assume it doesn't have our CVE tags in May 21 15:03:39 it is smart enough to trace them to downloads folder in case of downloaded ones May 21 15:03:53 its just that they need to exist there May 21 15:04:28 for completeness May 21 15:04:36 its perhaps better to run it after do_fetch May 21 15:04:41 I would thing May 21 15:04:44 think May 21 15:19:46 rburton: patch on ml May 21 15:20:47 cheers May 21 15:33:23 dl9pf: thanks! May 21 16:35:12 armpit: I'm wondering if meta-security-isfafw/classes/isafw.bbclass in meta-security is a typo, shouldn't it be in meta-security-isafw? May 21 16:36:15 RP: reading https://people.gnome.org/~federico/blog/preparing-the-bzip2-107-release.html and all distros being 50:50 wrt the SONAME i wonder why this did not show earlier. May 21 16:38:07 dl9pf: I don't know either. Its a crazy world :/ May 21 16:40:48 and it raises the question if we shoud remove bzip2-native from ASSUME_PROVIDED for consistency until distros sorted it out with the next uprev. May 21 18:10:27 postinst returned 1, marking as unpacked only, configuration required on target. May 21 18:10:50 is happens sporadically anyone has pointers on how to debug it ? May 21 18:11:06 recipe does not have postinst specifically May 21 18:20:16 do you need sudo powers to open/connect on a port <1024? May 21 18:20:32 tcp socket May 21 18:21:10 @jrdn: In general, yes May 21 18:21:45 Is there any way to set a port <1024 aside? I want to communicate on port 502 but I don't want to give root access to an application. May 21 18:22:23 Unfortunately changing port is not an option at the moment. May 21 18:23:44 There may be better ways to do it these days, but historically the way this has been done in the past is for the process to initially start as root, bind the port, and then setuid() to a non-root user. This is why you often see applications like the ssh daemon (port 22) running as a plain user "nobody" May 21 18:25:54 Yea that will work for me. Thank-you May 21 18:26:25 smurray, I would not be surprise May 21 18:28:30 armpit: the README.md in meta-security-isafw mentions the class, which suggests it should be in there. Should I send a patch? May 21 18:52:16 sure May 21 18:57:22 armpit: k, I'll add it to my todo list May 21 18:57:49 armpit: I may motivate myself to see if that class actually still works as well ;) May 21 19:22:37 Hi May 21 19:24:52 I'm using Debian Buster as Host and I try to build a BSP using warrior without success. I have seen in the doc that Buster is support by Zeus but not warrior. Is there a chance to build warrior with Buster host with few fixes? May 21 19:29:31 snorky: I suspect it might work given we still build warrior on the autobuilder May 21 19:32:50 RP: I try to build the demo image for an atmel board. Doing it on a stretch has succeed, the same on a pretty fresh Buster fails with errors during linux-glibc-header do_install. It seems pseudo complains about bad files May 21 19:36:08 snorky: shame :(. Hard to know why that would be but its also worth saying that buster didn't exist when warrior released so its hard to ensure everything works May 21 19:37:29 RP: autobuilder is running with Buster? May 21 19:37:53 snorky: yes, 3 workers run that May 21 19:38:59 RP: so there is a hope :) May 21 19:45:46 snorky: are you on the latest commits on the warrior branch from upstream? May 21 19:54:39 Hi. I'm trying to add flags to GCC so it will compile the image binaries using those flags. For instance, I use `TARGET_CPPFLAGS+=" -fcf-protection=full"`. But I get an error: *configure: error: cannot compute suffix of object files: cannot compile* - Why? May 21 19:59:25 RP: yes, I guess. I have checkout warrior branch directly yesterday: a24acf94d48d635eca668ea34598c6e5c857e3f8 May 21 20:08:01 nacknick: have a read of config.log, it usually has more details May 21 20:09:05 snorky: that isn't an oe-core or poky commit May 21 20:11:04 RP: https://pastebin.com/yxQJUZhG May 21 20:12:53 RP: https://github.com/openembedded/meta-openembedded/commit/a24acf94d48d635eca668ea34598c6e5c857e3f8 May 21 20:14:03 RP: I just hqve poky, meta-openembedded, meta-qt5 and meta-atmel May 21 20:26:41 RP: I'm on a 686 host .... I guess the autobuilder is x64 and that 686 is not a standard setup nowdays May 21 20:50:09 nacknick: right, so what does config.log say? /home/ubuntu/build-webos/BUILD/work/cortexa7hf-neon-vfpv4-webos-linux-gnueabi/libgcc-initial/8.2.0-r0/gcc-8.2.0/build.arm-webos-linux-gnueabi.arm-webos-linux-gnueabi/libgcc/config.log at a guess is the right place May 21 20:50:53 snorky: ah, right, yes. We don't test i686. Which poky revision are you on? May 21 20:50:58 RP: No such file or directory May 21 20:51:29 nacknick: have a look for a config.log somewhere around there, there should be one May 21 20:52:12 There are a lot, but I can't figure out which one is relevant May 21 20:52:40 nacknick: grep them for "cannot compute suffix of object files" May 21 21:00:04 RP: For poky: f0b1dc4816216f27c304659bf5df9019111b4e2c (last of warrior branch). I have an issue with python3-native that fails during configure for my tripplet May 21 21:00:31 i686-linux-gnu May 21 21:01:03 snorky: right, that is the correct revision. We don't test i686 sadly, all our machines have memory which needs 64 bit May 21 21:03:32 RP: I have to leave but I will investigate on that two points (linux-libc-headers and python3-native). The issue is probably more the architecture than Buster version. May 21 21:04:13 snorky: I'd agree that is most likely May 21 21:05:37 RP: I'll probably get back, I never troubleshoot such big recipes and I expect to need a lot of help! Thanks for your help and see you May 21 22:53:44 Is there a way to see what the final value of a variable is in a build? ie: KERNEL_EXTRA_FEATURES May 21 22:57:24 Something keeps enabling debugfs and debuginfo May 21 23:02:15 does bitbake {blah} -e | grep ^KERNEL_EXTRA_FEATURES show anything? are you using the YP kernel cache? May 21 23:08:30 I just tried that actually: bitbake -e linux-intel | grep KERNEL_EXTRA_FEATURES May 21 23:09:51 It looks like security.cfg is causing me pain again. It sets CONFIG_EXPERT=y, which in turn enables DEBUG_KERNEL May 21 23:11:14 It's interesting the comments in the cfg May 21 23:11:16 # Increases the low-level kernel attack surface. Disable it instead. May 21 23:11:16 # Removes the modify_ldt system call. May 21 23:11:16 CONFIG_EXPERT=y May 21 23:11:16 CONFIG_MODIFY_LDT_SYSCALL=n May 21 23:11:36 It says disable.. but it actually sets it =y May 21 23:12:37 Seems odd for a security config you would set EXPERT->DEBUG_KERNEL - I don't want symbols in kernel/modules May 21 23:15:56 https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/features/security/security.cfg May 21 23:41:11 security and expert mode go hand in hand :) May 21 23:41:45 I wish security was just in the backbone May 21 23:44:49 But EXPERT forces DEBUG_KERNEL to be enabled May 21 23:44:59 Which seems wrong to me May 21 23:46:00 menuconfig EXPERT .. select DEBUG_KERNEL May 21 23:48:18 I ended up removing security.scc from features, and making my own which has EXPERT=n.. it seems to have solved the issue of things being enabled that I was setting to disable in my fragments May 21 23:48:25 Time to test kernel still works :D May 21 23:48:48 yeah you wont lose much by removing those options May 21 23:55:29 I would think for a production kernel you don't want DEBUG_KERNEL, right? May 22 00:05:41 certainly not I would think **** ENDING LOGGING AT Fri May 22 02:59:57 2020