**** BEGIN LOGGING AT Fri Feb 26 03:02:01 2021 Feb 26 03:06:02 Guest873383: https://pastebin.com/35ik3tT9 Feb 26 03:10:40 So you are right it does not have the soname encoded. The way its working is there are a few libraries softlinked to this one libMali.so Feb 26 03:11:12 All precompiled blobs to me Feb 26 03:18:05 But I don't understand why copying libMali.so -> libgbm.so would work but ln -s libMali.so libgbm.so does not. Feb 26 03:21:51 yeah soname is missing Feb 26 03:22:13 so yocto shlibs resolver will be confused because this library can not be found in dependency manager as a result Feb 26 03:23:24 yeah symlinks are not used as names it will resolve to real .so Feb 26 05:37:41 Okay. It looks like just creating a new *empty) libgm.so (with proper soname) linked against the libmali.so is making yocto happy. Feb 26 07:29:45 hi i have an external layer that is providing a patch that is already in an other external layer how do i remove one in my layer Feb 26 07:30:15 two diverend layers both do a bbappend with the same patchfile Feb 26 07:44:00 hello guys ! I've noticed that some recipes build directory are in -poky-linux and some other ones are in all-poky-linux. Why is this happenning ? how do I put a recipe build dir in -poky-linux ? Thanks ! Feb 26 07:45:05 thekappe: all-poky-linux are for recipes that generate package that are not machine dependent Feb 26 07:45:16 e.g python scripts Feb 26 07:50:12 @abelloni, I have a recipe that builds a binary file and since it's related to a specific machine I want that recipe build folder being put in -poky-linux. How can I do that ? I've added "COMPATIBLE_MACHINE=" but it doesn't work Feb 26 07:52:50 good morning Feb 26 07:59:12 thekappe: PACKAGE_ARCH = "${MACHINE_ARCH}" Feb 26 08:00:03 abelloni, thanks man Feb 26 08:32:40 yo dudX Feb 26 08:40:51 hi LetoThe2nd Feb 26 09:07:53 hello Feb 26 10:05:33 good morning Feb 26 10:06:48 working from a docker container, I cannot create the final wic file due to limitation of the overlay fs, has anyone found a way around that? Feb 26 10:07:28 good thing about new build infrastructure: moar power. bad thign about new infrastructure: much starwalking and physical access until everything works. Feb 26 10:10:31 LetoThe2nd: starwalking/walk of fame? Feb 26 10:10:39 stairwalking. Feb 26 10:10:43 hihi Feb 26 10:10:54 server housing is on production floor. Feb 26 10:11:16 but then i'll compile the s**t out of everything!!! Feb 26 10:11:23 intera91: have you heard about pyrex by any chance? Feb 26 10:12:14 qschulz: apart from the plates which can go in the oven:  no Feb 26 10:12:41 intera91: https://github.com/garmin/pyrex Feb 26 10:12:42 mh... oven... Feb 26 10:12:56 might help you with getting started with containers Feb 26 10:13:04 haven't used yet but some cool kids here do Feb 26 10:13:24 JPEW: might want to pay me for marketing soon ;) Feb 26 10:14:33 @qschulz: everuthjing compiles fine and its just that last stage creating tye wic file as the python script wants to know the filesystem block size and that is a fail as overlayfs doesn't support that  system call Feb 26 10:18:33 LetoThe2nd: I prefer the idea of starwalking Feb 26 10:20:25 RP: as Ronnie James Dio told us, real metal heads can either go stargazing or, space trucking. no starwalking allowed. Feb 26 10:23:34 LetoThe2nd: but what to do if your star needs walking? Feb 26 10:31:35 RP: it will take me a lifetime to get that picture out of my head again. Feb 26 10:45:18 Hallo Yocto Wizards ! Is it possible to override variable set in machine.conf from image recipe ? Feb 26 10:47:41 NiniC0c0: possible, yes. I suspect what you're trying to change is something not capable of being changed in an image though. Which variable? Feb 26 10:48:17 NiniC0c0: you can override it, but only for the rest of the recipe. Feb 26 10:48:30 for all other cases, see yocto chant #1 Feb 26 10:48:38 e.g. trying to change the libc from within an image wouldn't make sense as much more than just the image is affected by it Feb 26 10:50:18 Hi RP, currently i'm using a custom bbclass to build FIT image. To configure this recipe I have set some variables inside machine.conf (kernel source/device-tree...) but I would like to override this configuration depending the image Feb 26 10:50:33 and i'm not sure about the right way Feb 26 10:51:24 NiniC0c0: the challenge is that the kernel is already built by the time the image recipe is processed so the image recipe can't change the kernel configuration Feb 26 10:52:35 NiniC0c0: you can definitely do things like that but you need to think a little differently about what you're doing, for example they might be separate machines (inheriting one machine from another and tweaking it is cheap) Feb 26 10:52:51 assuming you really do need different kernels Feb 26 10:53:51 RP understand ! Thank you for your time :) Feb 26 10:55:09 NiniC0c0: for the device tree, just ship more device trees in your fitimage, or make use of overlays, or both. Provided you can detect which variant you want to boot from u-boot (or a conf file, such as uExt.conf (not sure it's named this way) that you would create per image) Feb 26 10:56:07 for the kernel, just make a superset of everything you need and that should b enough (if you need a driver in one image but don't need it in the other image, just have it for both or compile it as a module and include it ony in the image you want to use it in) Feb 26 10:56:13 qschulz Are you saying that u-boot is able to set overlay before starting kernel ? Interesting, I need to double check that Feb 26 10:56:24 NiniC0c0: yup, fdt command lets you do that Feb 26 10:56:42 qschulz I will check, you made my day Feb 26 10:56:44 again ;) Feb 26 10:56:46 (and actually... u-boot is already doing that for the memory DT node, it's implicitely done Feb 26 10:57:07 Hello community, anybody here with experience with npm recipe generation? I fail generating the cute-files demo from the Yocto wiki (https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM) on Zeus release. Feb 26 10:57:18 NiniC0c0: and I THINK bootm actually supports applying device tree overlays directly without using fdt command Feb 26 10:57:39 like, bootm 0x4678764654#dtb#dtbo#dtbo, etc... Feb 26 11:02:32 MartinH90: zeus is not exactly a good place to start out unfortunately... maybe try with either dunfell, gatesgarth or master, and if you run into problems then please provide a full problem description/log Feb 26 11:05:06 LetoThe2nd thanks! Maybe I can backport the recipes then. Here an error log: ERROR: cute-files-1.0.2-r0 do_compile: Execution of '/home/martin/workspace-npm/build/tmp/work/aarch64-my-project/cute-files/1.0.2-r0/temp/run.do_compile.2479040' failed with exit code 1: Feb 26 11:05:07 npm WARN using --force I sure hope you know what you are doing. Feb 26 11:05:07 npm ERR! Cannot read property 'replace' of null Feb 26 11:06:26 MartinH90: last edit of this page was almost three years ago Feb 26 11:06:29 MartinH90: a) is that on a maintened release also? b) that doesn't look like a full og (pastebin, please) Feb 26 11:06:41 (this page = this page in the wiki) Feb 26 11:06:59 qschulz: yes, i noticed too, but i wouldn't really blame it as the npm fetcher at least should be maintained. Feb 26 11:07:00 the wiki isn't actively maintained, unlike docs.yoctoproject.org Feb 26 11:07:17 LetoThe2nd: npm has seen major changes in the last few years IIRC Feb 26 11:07:27 +bbclass/fetcher Feb 26 11:07:31 qschulz: it has! Feb 26 11:10:58 LetoThe2nd qschulz: Here is the pastebin: https://pastebin.com/nNYwrrtv Feb 26 11:13:11 MartinH90: sounds like there is your explanation, ain't it? the package doesn't even compiole properly in itself. Feb 26 11:14:27 LetoThe2nd I tried with different npm packages and all produce the same error message. I was hoping this is a known bug and there is a fix already available ;-) Feb 26 11:14:51 MartinH90: TypeError: Cannot read property 'replace' of null Feb 26 11:15:14 ah wait. maybe that package has no shrinkwrap file? Feb 26 11:15:31 then its indeed known behaviour. go check the ml Feb 26 11:21:22 LetoThe2nd a shrinkwrap file was not generated, there was an error in devtool add. A package-lock.json was generated. See pastebin: https://pastebin.com/JQjviscd Feb 26 11:24:20 does anyone use pyrex? following the instructions only results in Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /tmp/tmpgzhcag55 Feb 26 11:25:07 does anyone use pyrex? following the instructions only results in Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /tmp/tmpgzhcag55 Feb 26 11:26:22 there is a python script which tries to create a temporary dir and file with a raqndomly generated name and that fails spectacularly Feb 26 11:29:27 MartinH90: nah thats not what i meant. the npm bbclass behaves unexpectedly/badly when there is no shrinkwrap file supplied. there has been a thread and also a workaround patch on the ml Feb 26 11:32:35 LetoThe2nd great, thanks! Feb 26 11:54:41 Hi all. what is the best/easiest way to set the DL_DIR from environment. I would like to avoid putting it in the local.conf. Feb 26 11:57:20 hthiery[m]: DL_DIR= :) Feb 26 12:06:22 LetoThe2nd: you mean just setting DL_DIR as env before starting bitbake? Feb 26 12:06:49 LetoThe2nd: here this seems not to works the downloads still land in the value from local.conf Feb 26 12:12:05 hthiery[m]: don't set it in the local.conf? Feb 26 12:12:54 LetoThe2nd: isnt there a way to override that? Feb 26 12:14:26 hthiery[m]: it depends on which order the files/env is parsed. It seems local.conf is parsed after the environment, therefore if you have a DL_DIR= in your local.conf, this one will override whatever you pass from the env Feb 26 12:14:46 hthiery[m]: no i mean, just do DL_DIR=.... bitbake whatever. Feb 26 12:15:02 hthiery[m]: also, I vaguely recall that passing vars like this does not work on all shells Feb 26 12:15:10 ah. sure, if you have a "=" assignment in your local conf.... Feb 26 12:17:56 LetoThe2nd: qschulz I have to admit that I'm new to yocto and I use a present configuration/setup. With setting this up there is a local.conf that has the DL_DIR set but I would like to use another location for downloads Feb 26 12:18:30 hthiery[m]: try changing the assignment in local.conf for a ?= Feb 26 12:26:10 LetoThe2nd: this is in the local.conf DL_DIR ?= "${BSPDIR}/downloads/" and when I now run DL_DIR=~/yocto-dl bitbake is is still downloaded to the location specified in local.con Feb 26 12:34:27 hthiery[m]: BSPDIR is not canonical, hence my guess it that your build setup has seom hidden magic somewhere. Feb 26 12:38:41 LetoThe2nd: hmmm .. the environment I use seems to be based on https://github.com/Freescale/fsl-community-bsp-base/blob/master/setup-environment#L166 Feb 26 12:41:16 LetoThe2nd: in this the BSPDIR is used Feb 26 12:41:46 hthiery[m]: i'm not sure DL_DIR is picked up from the environment by default, try `BB_ENV_EXTRAWHITE=DL_DIR DL_DIR=... bitbake`. you can check with bitbake -e if it's picked up or not. Feb 26 12:43:59 zibri: this seems to do the trick Feb 26 12:44:30 cool! :) Feb 26 12:54:42 zibri: is this somewhere documented in the manual? Feb 26 12:59:06 hthiery[m]: yes, it's a bitbake variable (starts with BB_) (as opposed to layer variables) and is documented with bitbake; see bitbake-user-manual-metadata.rst and bitbake-user-manual-ref-variables.rst in bitbake/doc/bitbake-user-manual/ Feb 26 13:00:03 i suppose DL_DIR also is a bitbake variable, but it's only a convention :) Feb 26 13:00:45 (when i say bitbake variable in this context, i mean it's a variable use internally by the tool itself.) Feb 26 13:02:53 Hi Feb 26 13:02:54 Does anyone know how to add a kernel parameter in yocto? Feb 26 13:02:54 I tried to add it in /etc/sysctl.conf but it didn't seem to work. I'm trying to enable the memory cgroup Feb 26 13:02:54 hthiery[m]: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_ENV_EXTRAWHITE Feb 26 13:03:13 Lyghtnox: for which board? Feb 26 13:03:42 qschulz Raspberry pi 2 Feb 26 13:04:33 There is a way inside Yocto to "auto-load" overlay (without any init-script or hack:)  ) maybe like the raspberry with a config file ? Feb 26 13:04:52 Lyghtnox: either in cmdline.txt in boot partition or in bootargs environment variable in u-boot Feb 26 13:06:22 zibri: interesting, thanks! i didn't even think about the possibility that DL_DIR isn't whitelisted. Feb 26 13:06:49 NiniC0c0: look in U-Boot sources for boards using uEnv.txt Feb 26 13:07:26 uEnv.txt is just a file to be put in some partition accessible to u-boot. Then it's up to you to modify uEnv.txt how you want Feb 26 13:07:32 qschulz is it the only way isn't it ? i'm listing all possibilities before start coding the solution :) Feb 26 13:07:49 letothe2nd: you add it to extrawhite once and then forget about it :) Feb 26 13:08:20 NiniC0c0: it has nothing to do with Yocto. If you want to use DT overlays in U-Boot, then it's a UBoot "problem". Feb 26 13:09:24 qschulz I wasn't aware of the cmdline file. Thanks! Feb 26 13:09:51 qschulz Sure! sorry for asking. My bad Feb 26 13:09:51 you could technically have a second u-boot environment in some partition that you then import with `env import`, it has its security challenges though (there's an allowlist now, so you can import only the variables you want from that second env) Feb 26 13:10:15 NiniC0c0: no no, don't you worry, I was just trying to highlight that we might not be the best support for this particular issue :) Feb 26 13:10:54 qschulz Your are always the best support ;) Feb 26 13:18:25 on dunfell, after do_compile() failed, and I've modified SRC_URI with a patch, should bitbake apply the patch automatically without manually calling clean() task in between? Feb 26 13:22:50 mcfrisk: yes, except if devtool is used Feb 26 13:27:12 mcfrisk: yes, it should rerun fetch/unpack/patch as SRC_URI changed Feb 26 13:30:49 RP: I'll poke at perf more today. If you've got a few mins at some point for that reproducibility crash course. I'll take you up on the offer. Feb 26 13:31:44 qschulz RP: thanks, then either my setup or BSP's are breaking things.. Feb 26 13:36:30 zibri: qschulz thank you for pointing to that Feb 26 14:06:32 qschulz: I'll give you a hefty discount on using Pyrex ;) Feb 26 14:12:57 JPEW: deal Feb 26 14:25:04 zeddii, JPEW: I've just realised we could make a change to the selftest which might make things easier for people Feb 26 14:25:06 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=33d27ee65135613597f68dd1a60dbf4bcf59512a Feb 26 14:26:15 zeddii: so in your case you'd change targets to ['perf'] and sstate_targets to ['virtual/kernel'] and then run oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds Feb 26 14:26:35 zeddii: that should rebuild near enough just perf using sstate for the rest Feb 26 14:26:42 ahaha. gotcha. I'll grab that proposed patch and try that. Feb 26 14:27:17 zeddii: if you run OEQA_DEBUGGING_SAVED_OUTPUT=/tmp/perf-diffoscope oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds it should dump diffoscope output into said directory too Feb 26 14:27:54 zeddii: I was trying to think about the easiest way to explain this and its easiest with that patch :) Feb 26 14:28:22 Agreed. I've been there as well. A patch is easier than re-explaining or even a doc, since it is live in the code. Feb 26 14:29:16 zeddii: happy to take any other questions on reproducibility but I think this and simply running "strings /usr/bin/perf | grep " is probably enough for you to get started with Feb 26 14:29:41 hi all. Feb 26 14:29:41 any of u might have created a yocto recipe for installing python app on virtualenv ? Feb 26 14:29:42 meaning i don't want to just install cetrain pip modules. i want the recipe to create virtualenv, install modules on it using pip so the main code could run as : `source venv/bin/activate && python3 my-code.py` Feb 26 14:29:49 RP: that should be enough. I'll run with it. Feb 26 14:30:06 zeddii: I've not tested that patch but I'm sure you can figure out it and let me know if it works :) Feb 26 14:30:25 absolutely. Feb 26 14:30:26 easier than trying to explain running two builds with partial sstate overlap etc Feb 26 14:36:59 RP: Ah very good! Feb 26 14:38:34 I don't know if anyone is inheriting the class and overriding it for their own tests, but if so you might have the keep the "images" variable Feb 26 14:38:45 vmeson: Would be most likely? Feb 26 14:40:31 RP: you could do: `bitbake(' '.join(getattr(self, 'images', self.targets)))` to make it look for the old name first and use the new name if it's not found Feb 26 14:49:54 JPEW: ok, will tweak Feb 26 14:51:45 sorry to repeat was afk, is anyone using the pyrex project? Feb 26 14:52:20 green reproducibility: https://autobuilder.yoctoproject.org/typhoon/#/builders/118/builds/43 - only 45 exclusions and working rpm :) Feb 26 14:52:32 dl9pf: ^^^, finally :) Feb 26 14:54:32 intera91: I'm the maintainer of Pyrex Feb 26 15:23:07 hello guys ! Feb 26 15:23:21 one question.. If I want to add an udev rules Feb 26 15:23:32 which is the best recipe to use ? Feb 26 15:26:47 thekappe: I don't think there's anything specific to it, I've been adding the files manually to /etc/udev/{rules,scripts} in handcrafted recipes Feb 26 15:27:00 it's a simple install ${WORKDIR} ${D} Feb 26 16:05:09 I'm blanking, it thought there was a bitbake target that would populate someplace under the TMPDIR with the native packages. (I'm trying to run QEMU directly, not via runqemu).. any clue you can give me? Feb 26 16:12:43 bitbake -c addto_recipe_sysroot qemu-native ? Feb 26 16:13:15 where does it get stuffed then? Feb 26 16:13:23 khem: I played wanted to try plymouth on our musl enabled distro and saw that it fails building. As it needs rpmatch(), I added the external rpmatch-musl package as recipe and a patch to plymouth using it. Is that something you want feed back into meta-oe or somewhere else? Feb 26 16:13:47 fray: RECIPE_SYSROOT_NATIVE Feb 26 16:13:56 There's a script to do this for you.... Feb 26 16:13:56 khem: and why do I find you here and not on #oe as well :D Feb 26 16:14:18 khem: btw, long time no see. The conferences kept us connected :-) Feb 26 16:14:31 fray: oe-run-native and oe-find-native-sysroot Feb 26 16:14:32 RP: YAY !! Feb 26 16:14:48 dl9pf: I've merged it Feb 26 16:15:01 RP, dl9pf: \o/ Feb 26 16:15:11 * RP is pleased to finally have some of those patches into master, its been a horrible patchset Feb 26 16:15:46 some bits were well-hidden Feb 26 16:16:16 I'm trying it now.. thanks Feb 26 16:16:18 fray: build-sysroots recipe too Feb 26 16:16:50 fray: depends whether you want a specific set of dependencies or everything that was previously built Feb 26 16:17:04 build-sysroots is a horrible hack and I'd expect can break in interesting ways Feb 26 16:18:03 problem is that I can't 'runqemu' cause ther eis no qemu file.. so someone game me a magic line, which Ic an't run directly, since the libraries can't be found.. it's a never ending cycle of failure Feb 26 16:18:26 the scripting 'seems' to be working for the most part.. I just hate this magic stuff because nobody bothered to add the right qemu vars to this machine.conf Feb 26 16:18:51 "but the reproducer is easier this way".. no doorknob.. it's not.. ARGH Feb 26 16:19:17 RP: build-sysroots looks like some deep magic.... I can't quite grok how it actually puts anything in the sysroot :) Feb 26 16:19:32 Or more specifically how it puts everything in the sysroot Feb 26 16:20:15 JPEW: From memory, I think it would likely just walk the sstate manifests Feb 26 16:20:40 so if you've built two things with overlapping files for example, tough luck... Feb 26 16:23:10 and their reproducer instructions don't reproduce the problem.. I hate this crap Feb 26 16:26:05 Hi, I'm trying to use different version of lib boost in the same build. Is there someone that know how to achieve this? I'm using PREFERRED_VERSION_pn-boost to set one version, but don't find info to bind boost version to a specific recipe. Feb 26 16:28:09 @thanks qschulz! Feb 26 16:33:09 dakhouya: you need two recipes named slightly different so that they are different to the eyes of bitbake Feb 26 16:33:42 dakhouya: basically what was done for openssl 1.0 and 1.1 "cohabitation" Feb 26 16:38:12 Thanks for the tip Feb 26 16:38:19 I'll try that! Feb 26 16:50:19 zeddii: RP seeing some kernel error msgs on qemuarm https://errors.yoctoproject.org/Errors/Details/572577/ Feb 26 16:50:30 this is latest master-next Feb 26 16:50:42 demand a refund! Feb 26 16:51:52 I saw that in early January as well. Tried to fix it with the kernel command line, and it didn't take for all cases. Didn't have more time to muck around with it, so I moved on. Feb 26 16:52:47 reminds me of some pci horrors zeddii and I dealt with on arm versatile like 10y ago - nobody was quite sure what the qemu should do (even rmk) since the hardware was all dead and buried. Feb 26 16:53:23 actually, I lie. My patch to try and address it has been in tree since December 28th Feb 26 16:54:27 khem: I've not see that... Feb 26 16:54:47 @JPEW: sorry was afk Feb 26 16:55:52 @JPEW: installed on vanilla ubuntu 20.04 as working on warrior branch for an AMD bsp. followed instructions to the letter Feb 26 16:56:54 @JPEW: and it fails to create the temporary /tmp/tmp and stops there Feb 26 16:57:26 * JPEW looks at some code Feb 26 16:57:35 Is /tmp writeable for your user? Feb 26 16:57:48 @JPEW: yes Feb 26 16:59:11 Any other output? Feb 26 16:59:48 @JPEW: going to pastebin the output just a sec Feb 26 17:00:40 intera91: If you can send your pyrex.ini file, that would be helpful also Feb 26 17:00:59 * JPEW has to step away for a little bit, but I'll be back Feb 26 17:04:36 @JPEW: https://pastebin.com/YhdyZ5S3 Feb 26 17:07:44 RP: I have upcoming gcc 11 too so perhaps thats related Feb 26 17:08:07 but I have seen similar errors for qemuppc64 last week which was not gcc 11 Feb 26 17:08:56 RP: https://errors.yoctoproject.org/Errors/Build/117464/ first pass on my world build with gcc 11 Feb 26 17:08:59 not so bad Feb 26 17:11:01 @jpew: the pyrex.ini is unchanged from generated by meta-pyrex/mkconfig > ./pyrex.ini Feb 26 17:14:07 khem: not bad, we've definitely seen worse Feb 26 17:14:53 khem: did you see the glibc disable isa patch on the list? Feb 26 17:15:00 thats like 50k tasks just oe core has 5 recipes I think Feb 26 17:16:28 yeah I have not checked my emails yet been on phone ever since I woke up Feb 26 17:16:33 but now I see, Feb 26 17:16:58 yeah i think its ok to disable it. we use manual tunes so there is no need for this for us Feb 26 17:17:09 but real fix is something else Feb 26 17:18:10 its a good feature actually for x86 maybe we need to have more tunes Feb 26 17:27:14 khem: I'm wondering why its showing up for them but not in our automated tests Feb 26 17:27:33 Does somebody use connman around here? Seems dead, I can't get accepted to the mailing list. I thought it was more lightweight than network-manager, but maybe I should stick to nm? What do you guys use? Feb 26 17:30:07 I think its poking at build machine Feb 26 17:31:10 atleast thats how the checks are Feb 26 17:31:15 for this isa level stuff, they were not done for cross builds in mind :) Feb 26 17:32:20 stefan-schmidt: Feb 26 17:33:18 khem: if its looking at the build machine that would break reproducibility? :/ Feb 26 17:33:20 howdy, yes long time I am rusted in my den here I wish the world was normal sooner yes rpmatch-musl is right approach you took and I would certainly like to have that Feb 26 17:34:08 stefan-schmidt: perhaps we can have this library in oe-core along with other musl helpers Feb 26 17:35:19 stefan-schmidt: re oe irc, I switched to using matrix and am using IRC bridge and lazily just joined one channel since I was experimenting but you remind me of joining it Feb 26 17:36:07 RP: yes I know there was a fix that HJ sent for this but it seems thats not enough, atleast it solved the issues I was seeing Feb 26 17:37:54 RP: you are not yet running into 8M size limit issue on core-image-minimal in -ctestimage ? Feb 26 17:40:42 khem: no, I'm wondering why Feb 26 17:41:02 JPEW: I think I understand the slowness in the repro selftest - its the sync calls Feb 26 17:41:09 JPEW: happen between every cmp call Feb 26 17:41:21 @JPEW: have you seen the pastebin? Feb 26 17:41:36 intera91: Ya, that's bizzare Feb 26 17:41:54 @jpew: tell me about it Feb 26 17:42:04 It seems like a permission problem... can you try `export TMPDIR=/some/other/path` ? Feb 26 17:42:14 RP: the `cmp` command calls sync? Feb 26 17:43:03 JPEW: it was an attempt to try and ensure we didn't have IO backlog on the workers Feb 26 17:43:49 JPEW: in oeqa/utils/commands.py Feb 26 17:44:39 Ah, needs sync=False Feb 26 17:44:52 JPEW: yes, nice easy fix for that one Feb 26 17:45:09 Perhaps the default on that should be False :) Feb 26 17:45:53 @JPEW: maybe moving forward: docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /tmp/ssh-xNiHN8B2DYbr/agent.2428. Feb 26 17:46:27 JPEW: that would remove the benefit elsewhere :/ Feb 26 17:46:46 JPEW: we don't often run thousands of short commands Feb 26 17:47:39 RP: Fair enough Feb 26 17:48:26 JPEW: I've fast track merged that so watch it break somehow.... Feb 26 17:48:48 JPEW: watching a running build in top is painful Feb 26 17:50:20 intera91: Ya, it looks like (for some reason) the docker daemon can't access your /tmp Feb 26 17:50:54 * RP moves sync out the way to get the build to finish Feb 26 17:50:59 @jpew:  ls -lah / | grep tmp Feb 26 17:50:59 drwxrwxrwt 25 root root 124K Feb 26 17:50 tmp Feb 26 17:51:23 what am i missing here Feb 26 17:53:13 intera91: can you try `mkdir /tmp/foo; docker run -it --rm --mount type=bind,source=/tmp/foo,target=/tmp/foo busybox` Feb 26 17:53:39 That will tell of if it's docker in general, or pyrex in particular Feb 26 17:53:46 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/119/builds/45/steps/13/logs/stdio - compare the speed of rpm vs ipk :) Feb 26 17:53:53 mkdir /tmp/foo; docker run -it --rm --mount type=bind,source=/tmp/foo,target=/tmp/foo busybox Feb 26 17:53:54 docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /tmp/foo. Feb 26 17:53:54 See 'docker run --help'@jpew: Feb 26 17:54:15 foo exists Feb 26 17:56:10 sakoman: you really want that patch! Feb 26 17:56:44 RP: Sheesh. Indeed! Feb 26 17:56:52 intera91: Are you running the docker snap? Feb 26 17:57:03 @jpew yes Feb 26 17:57:06 JPEW: over two hours vs less than two minutes :) Feb 26 17:57:12 intera91: Ah, that would do it! Feb 26 17:57:18 JPEW: I think I found the bottleneck that has been bugging me! Feb 26 17:57:53 RP: Cool.... that explains why we never see it locally either... the sync doens't matter so much when you aren't doing multiple builds at once Feb 26 17:57:59 should I delete docker and resintall another way? Feb 26 17:58:05 reinstall rather Feb 26 17:58:30 JPEW: right, there is an mlocatedb update happening on that machine which is why it was so slow Feb 26 17:59:01 intera91: Ya, I think it's just `apt install docker.io` Feb 26 17:59:03 halstead: I do have to wonder if we really want/need mlocate doing that kind of thing... Feb 26 17:59:06 I'll update the readme Feb 26 17:59:18 ok trying that Feb 26 17:59:23 RP: Or at least exclude the build directories Feb 26 17:59:31 didn't know snap apps had these kind of limitations Feb 26 17:59:58 intera91: Ya, they run in confinement themselves, so they don't have access to the entire filesystem Feb 26 18:00:14 Most of the time, this doesn't matter, but when you do bind mounts it does Feb 26 18:00:17 what  a wate of time am so sorry Feb 26 18:00:43 intera91: It's OK. I didn't even know docker snap was a thing. Now I can warn others :) Feb 26 18:01:14 well there's you silver lining Feb 26 18:02:55 intera91: Do you have a GitHub username? Feb 26 18:03:31 intera91 Feb 26 18:05:03 RP: I haven't enabled the reproducible stuff in dunfell yet due to the load they put on the autobuilder. I have the patches in a branch and do run builds with them on occasion. Maybe this improves things enough that I can enable it by default. Feb 26 18:05:47 sakoman: you still run some basic reproducibility tests though? Feb 26 18:06:00 this will help those too Feb 26 18:06:13 Yes, I do Feb 26 18:06:14 wow, 1h vs 2min is significant Feb 26 18:06:21 RP, mlocate should be disabled. Something to improve there. Feb 26 18:07:04 and possibly opens the path for repro in dunfell ;) Feb 26 18:07:11 halstead: I'll leave that one with you Feb 26 18:07:28 I'm sure we do have basic reproducibility testing in dunfell, just not world Feb 26 18:08:12 * RP heads afk Feb 26 18:13:24 intera91: https://github.com/garmin/pyrex#requirements :) Feb 26 18:14:35 @jpew: excellent ;-) Feb 26 18:48:15 RP: bitbake master-next today is unhappy http://sprunge.us/Ar9tXz Feb 26 18:49:23 RP: I am seeing less space on core-image-minimal is there a place where buildhistory for AB is available ? I can quickly compare Feb 26 18:50:23 RP: I have EXTRA_IMAGE_FEATURES_append = " package-management ssh-server-dropbear" Feb 26 18:50:23 I wonder if thats causing it Feb 26 18:50:55 perhaps yes because dropbear pulls in pam etc if distro features have pam so it could be it Feb 26 19:31:02 does anyone know if the Linux on mars that landed recently is yocto project based ? Feb 26 19:33:13 khem: I gather they're using this board https://medium.com/@chuck.ward/qualcomms-snapdragon-flight-board-b1914dea9796 based on what I've heard so far. If that's true and they're using the vendor stuff provided it would be linaro linux. Maybe they've put something else on it though. Feb 26 19:33:38 georgem_home: for helicopter yes Feb 26 19:34:02 for anything other than that I don't know Feb 26 19:34:17 main cpu is Powerpc 750@200mhz Feb 26 19:34:37 https://mars.nasa.gov/mars2020/spacecraft/rover/brains/ Feb 26 19:34:37 ah ok. cool Feb 26 19:35:12 so Snapdragon maybe running yocto ? Feb 26 19:35:56 Is there anything wrong with using Ubuntu Server as the distro for an Atom embedded system? Feb 26 19:36:12 Sorry I know it's off-topic, but I'm specifically weighing Ubuntu Server vs Yocto Feb 26 19:37:16 I benchmarked my app and it runs like a dream on Ubuntu. I'm asking from a stability POV, or any other POV I'm missing. Feb 26 19:37:19 rangergord: its ok I guess, you have to know your requirements and then weigh in what matters to you and you will make a good decision Feb 26 19:37:28 rangergord: ubuntu is a linux distribution, yocto helps you build your own distritibutio. Its not comparable and it depends on your requirements Feb 26 19:38:01 my requirements are having Postgres, having Qt libraries, letting me easily add dependencies, and being rock solid Feb 26 19:38:32 Is there anything innately inferior about using a server distro on an embedded system? Like some shortcoming I'm not thinking of? Feb 26 19:38:52 It boils down to whether or not you're going to spend more time clobbering Ubuntu server to get what you need or building something custom with Yocto. Feb 26 19:39:18 rangergord:https://www.youtube.com/watch?v=iDllXa8SzUg Feb 26 19:39:20 for sure Ubuntu would be faster for me. I use it daily. And I use Ubuntu Server on my home server. Feb 26 19:39:43 rabbit9911: thanks! gonna watch this Feb 26 19:39:46 yocto produces an image file for you, which you could flash or upgrade... Feb 26 19:39:51 rangergord: depends... if you have to customize the heck out of it for your application it still might be more of a pain in the long run. Just depends what you're doing. Feb 26 19:40:36 and yeah a sane update solution would be part of what you'd need to customize on Ubuntu Feb 26 19:40:38 what sort of customizations are you referring to? Other than the boot logo/printout Feb 26 19:40:44 So if you are trying to built something like a router it will be more suitable Feb 26 19:41:07 nah it's a touchscreen device. meant to be on 24/7. gets rebooted during maintenance. Feb 26 19:41:48 rangergord: that dosnt matter. customitazion means, build one package with an build configuration Feb 26 19:42:00 not really easy to change this in ubuntu Feb 26 19:42:03 ah...no, no customizations. it's the same base image for everything. Feb 26 19:42:27 and same hardware Feb 26 19:42:33 same for me, i have the same base image for every device. And same hardware. Feb 26 19:42:41 But i still need customizations Feb 26 19:42:45 e.g. special kernel Feb 26 19:42:50 what if you want to run with a read-only root and store your user settings in a different partition... this kind of thing Feb 26 19:43:01 or in en EEPROM :-D Feb 26 19:43:05 yeah Feb 26 19:43:16 Maybe you want to have 2 partitions and failsafe upgrade... Feb 26 19:43:24 yup. that's what we do Feb 26 19:43:29 (pointing to rauc) Feb 26 19:43:52 same here, i guess that would be PITA to realize with ubuntu Feb 26 19:43:52 ah, I see what you mean Feb 26 19:44:15 its fine to run ubuntu on such a machine, if its working for you Feb 26 19:44:15 you just have to weigh your needs and see which way ends up taking more time in the long run Feb 26 19:44:18 if you want end to end control and also care for compliance and maintain it for long time yocto might be better and its bottom up approach means you only build what you need. Desktop distros start with a larger featureset and sometimes you start removing stuff and that does not work as well as bottom up Feb 26 19:44:49 khem: also correct. My image is 25 Mb - and its big :-D Feb 26 19:44:54 khem: I would be starting with the server distro though, then adding x11 Feb 26 19:45:15 the systems all have 120GB SSDs and 2GB of RAM. I hesitate to call it embedded Feb 26 19:45:21 I have seen cases where someone started with some desktop/server binary distro but then moved to use something custom because they realized thats best for them Feb 26 19:45:31 coming from a 256MB system running Busybox and a 12yo kernel :) Feb 26 19:46:00 its not about just how much resources you have anymore Feb 26 19:46:13 people are using yocto to build their servers and containers Feb 26 19:46:42 its just a way to customize every aspect of your image. Maybe you could compare it more with Gentoo Feb 26 19:46:48 its how much you want to allow the overhead to be Feb 26 19:46:57 thing is, I'm on my own working on this. Literally the only "software" guy. I'm a decent Linux user, but I wouldn't be able to troubleshoot kernel issues on my own for example. So delegating to Ubuntu here seems safer. Feb 26 19:47:16 and my 25M are really huge, it got big when i added systemd :) Feb 26 19:47:27 yeah community support is a big aspect Feb 26 19:48:03 rangergord: yes, true. Maybe just start there Feb 26 19:48:05 and this community is quite helpful I reckon :) Feb 26 19:48:06 rangergord: You could think of poky as equiv to ubuntu server. You can use it as is w/o much customization if you want. Feb 26 19:48:44 But it leaves the option open to massive customization if you need it Feb 26 19:49:57 What most people do is put poky in its own read-only directory and tweak what they need in their own custom layer. Then upgrading means just checking out the newer version of poky. Feb 26 19:49:59 rangergord: I would recommend to do some research and perhaps that will help e.g. https://medium.com/@zertsekel/yocto-vs-ubuntu-for-embedded-e6b13d583e05 Feb 26 19:50:22 what rabbit9911 says is exactly what we do... Feb 26 19:50:36 Its really nice, i nightly built that image on jenkins Feb 26 19:51:10 upgrade is done via rauc Feb 26 19:51:14 thanks. I'm gonna read that article then watch rabbit's 30 min youtube video Feb 26 19:52:02 Working on products with yocto/buildroot/openwrt and also one with redhat.. I would for sure say yocto is the best solution right now. Feb 26 19:52:29 Its worth the upfront investment Feb 26 19:52:38 georgem_home: so it seems the helicopter runs linux Feb 26 19:52:38 it's easy to say "Debian is just for prototyping" but you guys mentioned specific scenarios where it's harder, like the "two partitions with fallback" thing Feb 26 19:53:36 khem: yeah, hard to say if they used what comes with that dev kit or replaced it with something else Feb 26 19:53:57 so there is one planet where there are more systems running linux than windows :) Feb 26 19:54:21 well here too if you count Android Feb 26 19:54:55 I'll tell you one concern that's making me wary of another "custom distro". My previous system, was an old ARM, with Busybox. In addition to having to build my own packages (instead of something tested by Ubuntu/Debian ), I could never get reliable stack traces in core dumps. Like it was a total crapshoot whether a core dump would tell me what happened. I don't expect ever to have this issue on x64 Feb 26 19:54:57 server distro. Feb 26 19:55:16 So for an intermediate-level (and perhaps by the standard of this channel, novice) user, Ubuntu seems a safer choice Feb 26 19:56:07 rangergord: yeah that sort of thing would probably be easier in Ubuntu. You can do it with yocto but I won't tell you I've never run into issues before. Feb 26 19:56:08 although, that issue might have been related to the ARM processor, so perhaps Poki would never have similar issues on x64 Feb 26 19:56:29 well also... to be clear... Feb 26 19:56:43 I was cross debugging. With ubuntu you'd probably debug on the target. Feb 26 19:57:06 that's just easier in general Feb 26 19:57:48 I would totally include gcc/gdb in my custom distro, if only for convenience :) Feb 26 19:59:28 Another consideration. Yocto is nice for tracking license and CVEs. So if you ever want to add secure boot (which is almost a must now a days) You will have to make sure you dont include GPLv3 libraries/apps in your image. Yocto can do this. Feb 26 20:01:47 Also once you enable secure boot on target you lose the ability to use the package manager on target unless you have an overlayfs. Feb 26 20:01:55 georgem_home: Feb 26 20:02:08 I doubt they will use soc vendor SDK :) Feb 26 20:02:18 that's good to know, although my systems are open. Users have shell access and root password. Feb 26 20:03:00 Also as soon as your company grows and you make a product that uses a super cheap arm64 or risc-v processor you will bet super hard up trying to get debian working on it. Feb 26 20:03:09 RP: yeah the problem is including ssh server in minimal image and it tips over that df check Feb 26 20:07:30 khem: I will have a look to update what I have here to oe-core master (we are on dunfell here) and prepare patches early next week. Feb 26 20:07:55 stefan-schmidt: Feb 26 20:07:56 ok Feb 26 20:08:24 khem: folks here also looking at llvm/clang as default toolchain. In combination with musl. Thought that might interest you :-) Feb 26 20:12:03 stefan-schmidt[m: You are looking to add llvm/clang+musl as a default toolchain to poky? Feb 26 20:12:24 do some layers which are publicly available for yocto source code from the linaro project? Feb 26 20:12:29 rabbit9911: not poky itself but based on it Feb 26 20:12:53 s/do/are/ Feb 26 20:13:35  stefan-schmidt[m: As a layer then? Feb 26 20:14:27 rabbit9911: well, patches should go into the normal oe layers, but we plan to use it as default for our OpenHarmony distro Feb 26 20:14:48 so far we only switched to musl though, move to llvm/clang is on the agenda Feb 26 20:25:01 stefan-schmidt[m: poky-tiny I believe uses musl as the default today. Is this just expanding support to more packages perhaps? Feb 26 20:27:52 rabbit9911: not sure what you mean. OE/yocto does have musl support for a long time now. And a llvm/clang layer as well Feb 26 20:28:20 rabbit9911: I just thought that khem would be interested to know that we are planning to take this for our distro in production Feb 26 20:28:41 nd sure, if we see problems we get the packages fixed. Like for plymouth. Feb 26 20:29:06 is anyone here using .NET Core on Yocto? Feb 26 20:58:38 RP: clearly I'm not going to be able to do the reproducible tests locally on my home builder. It's been running for 4 hours now. And that's with your patch. Feb 26 20:58:44 rabbit9911: finished the video, great stuff. Although, thanks to one of the people in the Q&A at the end let me find the debos project, which creates a Debian rootfs from a recipe you give it (apt files to instal,overlay fs, etc), AND it integrates ostree. I'm gonna look into that as a compromise. Feb 26 20:58:50 * zeddii calls it a day Feb 26 20:59:36 so a lot of "Debian golden master" shortcomings are negated with this Feb 26 21:00:40 I think if I was still using a legit embedded system instead of an Atom system I would have gone with Yocto for sure Feb 26 21:04:12 is there a "reference" yocto project available for playing around / learning? e.g., something like the raspberry pi? Feb 26 21:04:18 debos is based on debootstrap which is one of the tools the speaker recommended to build a robust/reproducible Debian if you're gonna insist on it Feb 26 21:15:34 rangergord: Yep I heard that too. I would just be nervous if you ever think you would use a board that's not supported by debian out of the box. Usually the bean counters come in at some point and find they can save millions by using a cheap SBC based on some cellphone product. Usually what happens though is in 5 years if you still need to support Feb 26 21:15:34 your old product you start running out of disk space. Most of our yocto recipe mods are to remove features we dont need to save flash space. And when you A/B upgrade you run out of space fast. Feb 26 21:17:24 I have been looking at NixOS on the side too. I don't think its ready to do what Yocto does.. but it's interesting. Feb 26 21:17:31 rabbit9911: no chance of that happening. we sell a handful of devices a year only. Any savings on hardware would have to be spent by increasing the size of the dev team, or me falling behind Feb 26 21:21:16 stefan-schmidt: yes, meta-clang is your way to glory 🙂 we use it here as well. Now working on using it default for everything earlier we only used it for certain large components like browser Feb 26 21:22:19 one of these days I am thinking of creating meta-bsd and bring some BSD alternatives from OpebBSD/NetBSD/FreeBSD to yocto world as well dont know when though Feb 26 21:23:36 stefan-schmidt: building a clang based toolchain needs quite a bit of compute but once you have it built then it compiles other larger C++ files quite quickly compared to gcc Feb 26 21:24:05 so Webkit or Chromium devs are happy Feb 26 21:25:25 yates: meta-96boards perhaps ? Feb 26 21:26:18 rangergord: I know mono is well maintained in yocto world look at meta-mono https://git.yoctoproject.org/cgit/cgit.cgi/meta-mono Feb 26 21:26:53 thanks but would be crazy to use Mono today. It's probably gonna be gone next year when the grand unification is complete. Feb 26 21:27:00 khem: yup, meta-clang is what we are planning to use. A lot of things to sort out though next to the OE work. Keeping latest upstream find a way to reabse patches from an in house compiler team and last but not least we have meta-zephyr and meta-freertos on our agenda Feb 26 21:27:17 khem: lots of things to juggle, but we will get there eventually. Feb 26 21:27:21 OK it's not going anywhere, but new development will only be on .NET Core Feb 26 21:27:40 * stefan-schmidt[m is happy that he is not doing the toolchain work though ;-) Feb 26 21:28:21 stefan-schmidt: cool, I think you can easily plugin your own fork of llvm-repo into meta-clang if you like, I think I have left way for that Feb 26 21:28:27 rangergord: Sounds like its worth a try then! Just from my POV I have been at 3 companies now that have moved to yocto from various other solutions and its always super painful because it happens after you they have 10+ products and 10 years cruft that needs to be duplicated or changed at risk of thousands of products in the field. Feb 26 21:28:48 although I would love if folks maintain their changes as patches and work on upstreaming them Feb 26 21:29:27 khem: the aim from our OSTC side is really upstream and push our compiler team to rebase on latest and hopefully even submit upstream Feb 26 21:29:35 we will see how that goes :-) Feb 26 21:29:58 good deal Feb 26 21:30:27 as of now we can do everything we do with gcc in oe-core with clang too Feb 26 21:30:37 It feels good to work with OE again after so many years Feb 26 21:30:38 you can build eSDKs too Feb 26 21:30:58 You still need gcc for kernel though right? Feb 26 21:31:08 that's cool and likely to be interesting for our SDK work at some point Feb 26 21:31:09 good to hear stefan-schmidt Feb 26 21:31:25 rabbit9911: quite a bit of it does not need gcc anymore Feb 26 21:31:40 rabbit9911: sort of, I have run a clang compiled kernel on rpi4 though Feb 26 21:31:43 depends on your config, maybe some drivers Feb 26 21:32:02 glibc is another key piece which is joined at hip with gcc Feb 26 21:32:30 u-boot works with clang Feb 26 21:32:37 busybox does too Feb 26 21:32:58 so essentially if you are ok with musl then your base system is set Feb 26 21:33:33 kernel for x86/arm/arch64/riscv64 is getting better with time Feb 26 21:33:36 with clang Feb 26 21:34:13 For me the usage of both musl and clang for everything feels like a bold move. But our toolchain expert is in favour of it and I can clearly see the benefits Feb 26 21:34:46 We need to validate quite a bit though. Say musl with systemd :-) Feb 26 21:34:56 yes it is bold move but musl is everywhere now and so is clang so perhaps not a bad time to start Feb 26 21:35:06 jup Feb 26 21:35:19 yeah musl+systemd is a PITA and will remain so, I have given up on that Feb 26 21:35:26 I keep wanting to try s6-init in place of systemd :) which does support musl Feb 26 21:35:35 and for us an intersting part is how musl plays with zephyr and freertos and maybe orther RTOS systems Feb 26 21:35:43 infact for many systems I care for systemd is not as appealing anyway Feb 26 21:36:21 musl has FDPIC port ( nommu ) for cortex-M Feb 26 21:36:27 so you will be well serverd Feb 26 21:36:37 I get why systemd is supported in yocto but at the same time is feels like a bad fit for embedded devices. Feb 26 21:36:57 its convenient for sue Feb 26 21:37:02 sure Feb 26 21:37:25 rabbit9911: everbody defines embedded differntly. Do we talk 512kb flash or 8GB? Feb 26 21:38:03 khem: we will see how this pans out. We start bold and make plans with the best judgement we have and we will see if we hit walls :-) Feb 26 21:38:08 stefan-schmidt: yeah its getting there, we have issues on systems with 1G of RAM Feb 26 21:38:18 storage really does not matter Feb 26 21:38:31 everything is competeing for compute and RAM Feb 26 21:38:42 Then you add glib and dbus. Feb 26 21:38:50 so one has to know how much journald can thrash Feb 26 21:38:57 yeah, so "embedded" can be everything from 64KB to 6G :-) Feb 26 21:39:27 depending on who talks about it Feb 26 21:39:34 if you have range of products then having a common profile matters for scale Feb 26 21:40:10 that is the idea yes, a wide range actually. Thus the RTOS kernel part next to Linux Feb 26 21:40:29 even at 6G.. The less on the device the less you have to maintain Feb 26 21:41:06 i downloaded yocto. shouldn't i be able to build poky by just running "make"? http://paste.ubuntu.com/p/zyR744BwRz/ Feb 26 21:41:07 I have learnt that starting small at platform level is key Feb 26 21:41:34 yates: Feb 26 21:42:25 i downloaded like this: git clone -b gatesgarth git://git.yoctoproject.org/poky.git Feb 26 21:42:37 khem: Feb 26 21:43:07 this is under lubuntu 18.04.5 Feb 26 21:43:36 try https://github.com/yoedistro/yoe-distro Feb 26 21:43:57 10 steps - https://github.com/yoedistro/yoe-distro#workspace-setup Feb 26 21:46:10 stefan-schmidt: thats a good approach, remember its not the platform or tools which your products will differentiate on, but the services and apps, so OS is kind of a necessary evil, ideally if I could say the apps with minimum OS overhead that is preferred Feb 26 21:51:49 khem: I got that memo a long time ago. It has the nice benefit that its way easier to collaborate on these "uninteresting" pieces. I like that a lot. :-) Feb 26 21:52:05 khem: +1  Its always tempting to take the new thing and all of the extra stuff you dont need because its easy. The hidden cost of security/stability/general maintenance are usually an after thought. Feb 26 22:01:56 zeddii: was that in the initial build? Hopefully better once sstate is populated? Feb 26 22:03:33 yah. it just completed. Feb 26 22:03:38 but I see no mention of perf :D Feb 26 22:03:48 even with me putting it in as the target Feb 26 22:03:56 I'll investigate on Monday Feb 26 22:04:12 https://pastebin.com/nD6htMie Feb 26 22:28:55 yates: see https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#yocto-project-quick-build Feb 26 22:31:42 zeddii: did you remove perf from the exclusions list? Feb 26 22:32:01 zeddii: I had forgotten you might need to do that :/ Feb 26 22:32:08 obvious in hindsight Feb 26 22:32:23 zeddii: now you have hot sstate it should be faster Feb 26 22:32:43 zeddii: I'm guessing "different_excluded=1" was perf Feb 26 22:33:00 hum I still get this "No IMAGE_CMD defined for IMAGE_FSTYPES entry 'container'" :-( Feb 26 22:35:40 JPEW: diffoscope upstream have fixed the html diff size "hang" :) Feb 26 22:38:49 smurray: thanks! **** ENDING LOGGING AT Sat Feb 27 03:00:25 2021