**** BEGIN LOGGING AT Mon Nov 13 03:00:02 2017 Nov 13 04:17:42 RP, great then; these 2 commits are fixing the same bug for me as in the description (aufs-util compile problem) when I build for the Intel Edison Nov 13 04:18:16 and besides aufs-utils, get the same stack smash protection compile bug with docker Nov 13 07:34:05 good morning Nov 13 09:20:14 morning Nov 13 09:55:46 anyone there? I want to clean the build directory, I'm using bitbake -c clean but it is not removing all the build images and related stuff... Nov 13 09:56:36 xtron: thats because the clean command does not delete stuff, but only invalidate the tasks Nov 13 09:57:07 xtron: you can try cleanall for a given target, otherwise just remove the tmp directory. that gives you the big rebuild Nov 13 10:01:58 LetoThe2nd: so it will clean core-image-minimal for all platforms like qemuarm, qemux86 and qemux86-64 (only minimal image) rigth? Nov 13 10:03:38 xtron: well what do you mean by "clean" Nov 13 10:04:34 xtron: the definition of "clean" in the context of bitbake is "not available anymore, will be recreated if needed again" Nov 13 10:04:35 removing compiled images Nov 13 10:05:55 xtron: so your intent is to remove them from the disk Nov 13 10:06:24 yes Nov 13 10:06:52 the just remove whatever you don't want anymore from the tmp/deploy directory Nov 13 10:07:04 LetoThe2nd: I want to make backup of poky so I case I need it later, Nov 13 10:08:05 why would i make a backup of poky? git clone git://git.yoctoproject.org/poky.git as many times as i want Nov 13 10:09:42 LetoThe2nd: isn't it will download poky again? Nov 13 10:10:02 that will always give me a fresh download of poky, yes. Nov 13 10:10:19 which is actually a very good thing to always test against a clean, untinkered version Nov 13 10:11:26 yes it is, but I want backup for when I'm not connected or can't download. anyway I got your point Nov 13 10:11:46 then just tar it up. Nov 13 10:13:27 LetoThe2nd: yup exactly, that's my plan.. so I can copy on different computers (where I can't download or don't want to) Nov 13 10:16:16 xtron: technically thats no problem. if you don't want or need the full git history, you can also use git archive Nov 13 10:17:59 LetoThe2nd: will look into what this git archive is... that can be an option Nov 13 10:24:47 xtron: actually, i guess your build is *inside* the poky dir? Nov 13 10:25:16 xtron: thats another best practise: create your own layers and the build directory *outside* of poky. Nov 13 10:26:21 xtron: i recommend this layout: https://gist.github.com/anonymous/2492b169c29530794ba0e423b6ab6968 Nov 13 10:29:46 LetoThe2nd: yup, I did that mistake in start.. I should keep my build and download directories outside poky Nov 13 10:30:25 xtron: especially the build dir. by default the download dir is in the build dir, but of course you can share that one across different builds Nov 13 10:33:49 LetoThe2nd: yup it take some time to be confident for such changes, :) I'm still understanding the yocto dir-tree, variables and basic build Nov 13 11:58:12 clear Nov 13 12:00:32 tront_: can you propose them on the mailing list please? Nov 13 12:08:29 RP, I knocked out power to a disk enclosure at the datacenter. The NAS is offline for a bit. I'll update soon. Nov 13 12:12:21 halstead: ok, np Nov 13 12:12:53 halstead: thanks for the warning Nov 13 12:19:09 is there anyway we can find the value of variables available in yocto, for example I want to know where LAYERDIR is pointing? OR WORKDIR, BBPATH etc Nov 13 12:29:02 xtron: bitbake -e [recipe] Nov 13 12:29:20 RP, just did https://lists.yoctoproject.org/pipermail/poky/2017-November/011154.html Nov 13 12:35:03 hi all Nov 13 12:35:15 I'm trying to fetch rocko from : http://downloads.yoctoproject.org/releases/yocto/yocto-2.4/poky-rocko-18.0.0.tar.bz2 but it's not working Nov 13 12:35:18 getting timeouts Nov 13 12:35:27 wget http://downloads.yoctoproject.org/releases/yocto/yocto-2.4/poky-rocko-18.0.0.tar.bz2 Nov 13 12:35:28 --2017-11-13 13:34:08-- http://downloads.yoctoproject.org/releases/yocto/yocto-2.4/poky-rocko-18.0.0.tar.bz2 Nov 13 12:35:28 Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... 198.145.29.63 Nov 13 12:35:28 Connecting to downloads.yoctoproject.org (downloads.yoctoproject.org)|198.145.29.63|:80... Nov 13 12:36:34 open-nandra: why don't you use git clone method? Nov 13 12:36:54 xtron: well we have script which will clone official reelase not git clone Nov 13 12:37:03 I just bumped versions and it's not working Nov 13 12:41:07 open-nandra: yup yocto server not responding... Nov 13 12:41:13 open-nandra, We are currently recovering from a storage failure. Nov 13 12:41:25 halstead: ok thanks Nov 13 12:41:28 I'll wait Nov 13 12:41:34 open-nandra, xtron I'll notifiy as soon as we are back online. Nov 13 12:41:45 halstead: thanks a lot Nov 13 12:41:50 halstead: no worries Nov 13 12:44:07 tront_: you need to actually do the backporting and send patches, I think :) Nov 13 12:44:08 New news from stackoverflow: Unable to fetch from git.ti.com? Nov 13 12:46:47 open-nandra, xtron RP back online. Initial checks show no data loss. Nov 13 12:47:17 <_julian> Hey, is there a way to list all tasks that would be executed for a given target? Nov 13 12:47:28 _julian: would be, in the meaning of? Nov 13 12:48:10 _julian: --dry-run? Nov 13 12:48:33 halstead: thanks! Nov 13 12:49:18 I'll count this as a successful practice session. Nov 13 12:50:05 halstead: yup its working fine now... Nov 13 12:50:34 Excellent. Nov 13 12:51:30 halstead: Nov 13 12:51:40 lol Nov 13 12:52:13 not ? Nov 13 12:52:29 nope. Nov 13 12:53:22 <_julian> rburton: dry-run is not exactly what I want. I'd like to see a list of all tasks that will be executed. With dry-run I see how many tasks would have to be executed in the sammary, but not a list of them Nov 13 12:55:10 kanavin, I have seen this kind of request on the ml so I went for the faster way :); I'll add the patches then Nov 13 13:01:36 <_julian> different questions: Is there some source-location override mechanism? For development I'd like to build a linux kernel from a local tree, with potentially non-commited changes. It would be very handy if I could point bitbake to it somehow. Nov 13 13:03:03 _julian: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#building-software-from-an-external-source Nov 13 13:03:19 _julian: or devtool, a bit depending on your exact usecase/setup Nov 13 13:04:41 no write access to poky-contrib ...... Nov 13 13:04:48 <_julian> LetoThe2nd: externalsrc seems to be what I want. Thanks Nov 13 13:08:50 _julian: see the cooker log, or pipe bitbake to a file Nov 13 13:09:28 _julian: ah i guess if you've already built the target then it won't help. is that the problem? Nov 13 13:09:39 you want to see all tasks that will be considered, not that need to be ran Nov 13 13:10:14 <_julian> rburton: I built the target, changed one package and would like to know what other packages will be rebuilt because of the changed package Nov 13 13:10:22 then dry-run is exactly what you want Nov 13 13:10:54 default bitbake ui won't show the log but if you pipe bitbake to a file (or even just |cat) then youll see the task list Nov 13 13:11:10 <_julian> rburton: piping the output might do the trick indeed. Nov 13 13:11:13 <_julian> thanks Nov 13 13:11:40 (bitbake switches UI depending on stdout being interactive) Nov 13 13:11:49 <_julian> ok, understood Nov 13 13:13:34 <_julian> so when using externalsrc, what would be the best approach to trigger a rebuild? bitbake -c clean package && bitbake target-image will work, but would always do a full clean rebuild. I'd rather only rebuild what has changed in the package, is that possible? Nov 13 13:18:55 bitbake targetimage should work as externalrc will look for changes afaik Nov 13 13:19:07 <_julian> ah, neat. let me try :) Nov 13 13:21:21 rburton: just going through the list of fails in my mega-patchset - is this actually related to anything in it? http://errors.yoctoproject.org/Errors/Details/158286/ Nov 13 13:21:39 no Nov 13 13:21:44 thats a kernel race Nov 13 13:22:10 cheers Nov 13 13:22:11 i was blaming the dnf packaging fails and gstreamer build fails on the series Nov 13 13:22:20 yep, those I reproduced Nov 13 13:22:25 awesoe Nov 13 13:23:08 gstreamer might take a while - "libgthread-2.0.so.0: ELF file data encoding not little-endian" isn't obvious Nov 13 13:23:47 can't recall now, was that on specific machines? Nov 13 13:23:56 rburton: mips64 Nov 13 13:24:11 rburton: | qemu-mips64: error while loading shared libraries: /home/ak/development/poky/build-mips64/tmp/work/mips64-poky-linux/gstreamer1.0-plugins-base/1.12.3-r0/recipe-sysroot/usr/lib/libgthread-2.0.so.0: ELF file data encoding not little-endian Nov 13 13:24:13 maybe something is confused about endian in mips64? Nov 13 13:25:00 rburton: my best guess is that somechange in glib broke endiannness Nov 13 13:25:07 yeah Nov 13 13:25:51 rburton: also, dwarfsrcfiles recipe isn't likely to change much - I can set up a variable, but I think it's fine as it is too Nov 13 13:26:07 it's just one source file bundled with the recipe Nov 13 13:27:30 rburton: oh, but the AB error was "/bin/sh: error while loading shared libraries: TOPDIR/tmp/work/mips64-poky-linux/gstreamer1.0-plugins-base/1.12.3-r0/recipe-sysroot/usr/lib/libreadline.so.7: ELF file data encoding not little-endian" Nov 13 13:27:39 odd Nov 13 13:28:06 well, first step would be to verify that the endian of those files is right :) Nov 13 13:28:32 rburton: how? :) Nov 13 13:29:25 file Nov 13 13:32:56 what's also odd is that base gstreamer package is fine, even though it too has introspection Nov 13 13:35:10 yes Nov 13 13:36:20 "/home/ak/development/poky/build-mips64/tmp/work/mips64-poky-linux/gstreamer1.0-plugins-base/1.12.3-r0/recipe-sysroot/usr/lib/libgthread-2.0.so.0.5400.1: ELF 64-bit MSB shared object, MIPS, MIPS64 version 1 (SYSV), dynamically linked, BuildID[sha1]=f67ccec6082f755a1d5cd686d1f64fa4166fa964, stripped" Nov 13 13:36:44 MSB == big-endian? Nov 13 13:36:48 then at least that is correct Nov 13 13:40:39 so why does the loader or whatever is making that line appear want little endian Nov 13 13:43:47 maybe some kind of bizarre host contamination? Nov 13 13:46:49 hello Nov 13 13:47:04 does anyone know what provides "BWidget"? Nov 13 13:48:55 ok found some recipes Nov 13 13:50:20 rburton: bisection points to the first bad commit being " gobject-introspection: update to 1.54.1" Nov 13 13:50:47 kanavin: not a huge surprise. Nov 13 13:51:39 rburton: which comes after the glib update, so I guess glib is not to blame Nov 13 13:54:01 rburton: plenty of suspicious commits here https://git.gnome.org/browse/gobject-introspection/log/ Nov 13 13:54:08 I guess I could bisect those as well Nov 13 13:55:01 kanavin: bisecting the development release might be worth it and trivial enough Nov 13 13:55:26 my hunch would be something is looking at the host endian instead of target? Nov 13 13:55:35 rburton: not so trivial, as each step of the way we need to apply our custom patches Nov 13 13:55:42 good point :/ Nov 13 13:58:01 kanavin: https://git.gnome.org/browse/gobject-introspection/commit/?id=5d4cd25292b8ed2c7a821ebe19fc5ab5d447db1a looks like something i'd try reverting Nov 13 13:58:59 "does not work for all of its supported compilers (Visual Studio is an example)" grrrrrrrr Nov 13 14:09:12 rburton: revert is failing to apply, I guess I can carefully compare the linking command before and after instead Nov 13 14:12:33 I executed a command as now I'm getting error that doesn't exist, how can I fix this? Nov 13 14:17:16 thats not how oe-init-build-env should be called Nov 13 14:17:30 don't pass the machine name Nov 13 14:18:17 rburton: so how to fix it? Nov 13 14:18:52 go to the top folder again and run . oe-init-build-env test-build Nov 13 14:19:13 rburton: not working ... tried Nov 13 14:19:37 (second argument is the path to bitbake which is why it isn't working) Nov 13 14:19:52 you'll probab;y have to delete test-build as you've generated files in it which point to the wrong paths Nov 13 14:20:15 already deleted Nov 13 14:21:21 rburton: same error, need to reset the environment Nov 13 14:22:17 probably for the best, close and open a new terminal Nov 13 14:22:33 error message = Please ensure a copy of bitbake exists at this location or specify an alternative path on the command line Nov 13 14:23:04 can i ask why you were passing qemux86-64 to oe-init-build-env? whatever told you do to that is very wrong Nov 13 14:23:25 rburton: most lame solution ..... Worked! Nov 13 14:23:44 easier than pruning the environment :) Nov 13 14:24:38 rburton: actually I've another custom setup where I can pass machine as parameter... Nov 13 14:25:05 hello, I want to generate a single image that can be used both on SD card and eMMC with Yocto project tools ... the problem is that on i.MX6 the mmc device number used to boot Linux changes depending on whether I am booting from SD card (mmcblk1) or eMMC (mmcblk2) Nov 13 14:25:23 and script handle stuff related to machine like update machine in conf/layer.conf Nov 13 14:25:45 how can I configure the u-boot environment in such a way that it figures out whether it is located on SD card or eMMC automatically? Nov 13 14:25:46 xtron: ah, well oe-core setup script args are build directory and bitbake directory (both optional) Nov 13 14:26:04 rburton: Nov 13 14:26:10 yup Nov 13 14:27:16 eduardas_m: reset the environment Nov 13 14:31:26 xtron: not sure what you mean... I just want to write image to eMMC and u-boot has to figure out it was written to eMMC and not SD card and set the root partition for Linux on the correct device Nov 13 14:32:17 because mmcblk1p2 is valid for SD card and mmcblk2p2 is valid for eMMC in my case Nov 13 14:32:50 if I hardcode either one in my u-boot environment, it is inappropriate Nov 13 14:33:51 nrossi: For some reason, in u-boot, the "modeboot" environment variable doesn't get set when I'm booting from QSPI. Everything works fine when booting over JTAG. It's the same u-boot.elf I'm loading on both cases. If do some other changes to the environment variables I've set, they are reflected in both cases, but for some reason, it just doesn't seem to run the board_late_init() which sets the modebood environment variable. Nov 13 14:34:08 nrossi: Ever come across something like that? Nov 13 14:35:00 eduardas_m: how will you put Linux image on eMMC ? Nov 13 14:36:05 JoiF: nope not seen that, sure your mio strapping is right? shove a printf into the u-boot code that checks the register, see if it is what is expected Nov 13 14:38:04 xtron: tar -xOvzf /mnt/testing-image-var-som-mx6-20171109143316.rootfs.wic.tar.gz | dd of=/dev/mmcblk2 bs=16M status=progress Nov 13 14:38:29 this is executed from sdcard Nov 13 14:38:51 the only purpose for the scdard is to be able to write to eMMC with dd Nov 13 14:39:04 then it is removed and I reboot from eMMC Nov 13 14:39:23 there is a hardware switch to select booting from eMMC Nov 13 14:41:38 eduardas_m: so first you run Linux on i.MX6 from SD card also put a Linux image on SD card and then flash that image from SD card to eMMC using i.MX6 target, right? Nov 13 14:44:27 eduardas_m: actually that should just be clever u-boot scripting Nov 13 14:44:29 xtron: yes Nov 13 14:45:02 LetoThe2nd: yes, I assume so, but not sure what variables actually do what I want Nov 13 14:45:53 eduardas_m: neither do i. i guess you have to read some system registers to find out which boot path triggered. Nov 13 14:46:31 LetoThe2nd: mmcinfo kinda gives me what I want, but not sure how I pass it on to a script Nov 13 14:47:10 eduardas_m: are you sure that image is properly flashed on eMMC, like did you umount the eMMC before flashing the image? Nov 13 14:48:00 eduardas_m: agreed, the u-boot scripts are sometimes picky Nov 13 14:48:57 xtron: yes, I am sure it is properly flashed, as it actually boots after I change the rootfs partition number manually Nov 13 14:49:49 does anyone know why i'm getting ths error from a 3 year old recipe? : "autotools_copy_aclocal: not found" Nov 13 14:50:12 https://github.com/thgerner/meta-mkit/blob/a6f5b1d34fe19beb52c3e4e1dc0ddb7aa0cadfff/recipes-support/tkimg/tkimg_1.4.2.bb Nov 13 14:50:17 recipe in question Nov 13 14:50:54 3 or 4 Nov 13 14:50:56 :) Nov 13 14:51:08 LetoThe2nd: so you are not aware of how to pass the output of mmcinfo to a script in u-boot ant parse it somehow for example? Nov 13 14:52:43 I would kinda hate to have to generate a separate image just so that it has a slightly modified u-boot environment for booting from eMMC Nov 13 14:53:23 eduardas_m: i am not in particular. i personally probably would just patch uboot to add a specific command that tells me exactly what i need to know, and return that as a boolean value Nov 13 14:53:46 eduardas_m: as this is exactly what we do here, when we have to do boot time decicions :) Nov 13 14:54:37 as you have to patch it anyways to inject your particular machine/config, theres little magic involved in the end Nov 13 14:55:30 Hey is there a way to enable symlinks for busybox apps in my image? Nov 13 14:56:52 LetoThe2nd: yes, my colleague is currently looking at the u-boot source and apparently patching u-boot looks to be the only way right now... thank you for your advice Nov 13 14:57:30 eduardas_m: np, good luck Nov 13 14:57:35 nrossi: Will do. Thanks. Nov 13 15:06:56 nrossi: And I know I'm *really* pushing it when I'm asking you those questions that aren't really about Yocto or meta-xilinx per se... And I'm very grateful that you still respond to me at all ;) Nov 13 15:15:03 nrossi: Well, everything is actually fine .. it's just that the switch-statement in board/xilinx/zynq/board.c doesn't support all the available boot-modes defined in arch/arm/mach-zynq/include/mach/hardware.h Nov 13 15:15:15 nrossi: I guess I should submit a patch. Nov 13 15:15:24 JoiF: sounds like a good plan :) Nov 13 15:15:35 eduardas_m: did you try bmode command on u-boot Nov 13 15:16:48 nrossi: I was (wrongfully) assuming that the "norboot" mode in that switch-statement was supposed to be a sort of catch-all for any sort of onboard-flash-boot .. and that if I was booting from QSPI, the "modeboot" would be set to "norboot" Nov 13 15:44:48 New news from stackoverflow: Netbeans C++ project with existing Makefile hpp headers Nov 13 16:03:49 do contributions to poky now have to go through the poky-contrib approach? Nov 13 16:05:01 first, contributions to "poky" need to go to the right repository in the end. oe-core to oe-core, bitbake to bitbake, meta-poky to the meta-yocto repo, etc. whether you use poky-contrib or oe-core-contrib or your own repo isn't as big of a deal Nov 13 16:05:16 the poky repo is just an integration of components from other repositories Nov 13 16:06:45 I'm targeting a backport on the pyro branch of poky Nov 13 16:07:53 for such a case should I use poky-contrib or the contrib for the specific component? Nov 13 16:10:09 you'd send them to the pyro branch of the individual component repositories. Nov 13 16:10:36 what repo you put your commits in really doesn't matter, as long as you get them sent to the list, either as individual patches or as a pull request with the appropriate info on url and branch Nov 13 16:11:20 zeddii: berton and I are looking at pypi fetch errors; they need to use https now Nov 13 16:11:33 zeddii: the problem is that the error goes up to krogoth. Nov 13 16:11:47 zeddii: we are seeing it on krogoth here and newer releases Nov 13 16:11:59 zeddii: is it possible for us to provide a backport for it? Nov 13 16:16:08 Does anyone know where the name "Poky" originated? I know it came out of OpenHand, but I'm wondering if there's some significance behind it. My Google-fu is failing me. I even used Wayback Machine on OpenHand's site to see if it said anything there. Nov 13 16:16:48 Wondering if "Poky" is named after a food, someone's dog, or what. Nov 13 16:27:14 can I deploy image of qemux86-64 on PC ? Nov 13 16:30:18 GreenDude: corruption of a japanese sweet (which was pokey, iirc) Nov 13 16:30:21 rburton: going slightly mad here - gstvideo library does not have this issue, it's specific to just gstaudio lib Nov 13 16:30:42 xtron: best to use a proper machine such as intel-corei7-64 as the qemu machine is tuned for virtual environments Nov 13 16:30:53 rburton: thinking of disabling introspection on mips64 gst-plugins-base outright, and moving on Nov 13 16:31:12 tront_: patches *have* to go through the list, a repo is convenient Nov 13 16:33:27 rburton: Thanks. Nov 13 16:33:52 rburton: so I can deploy, can I make an .iso image from images generated by yocto system? Nov 13 16:34:48 xtron: set NOISO=0 and you'll get a .iso that boots an installer or live image. isos are rubbish so dont set that and you'll get a hddimg which is the same thing for USB sticks. Nov 13 16:39:31 rburton: what configuration I've to modify to get hddimg? Nov 13 16:42:25 well strictly speaking you want IMAGE_FSTYPES to contain hddimg, but thats the default for most proper x86 BSPs Nov 13 16:43:21 sounds like genericx86 or genericx86-64 might be a better bet than the qemu machines, perhaps? Nov 13 16:45:33 rburton: how? where is this IMAGE_FSTYPES defined? Nov 13 16:45:49 in the core metadata, which BSPs can change, and you can override in local.conf Nov 13 17:20:24 yocto seems very complex,,, trying to upgrate jethro to glibc 2.x is almost impossible ? Nov 13 17:24:35 "just" upgrading glibc is non-trivial Nov 13 17:28:11 rburton, if I understand correctly, each yocto version (jethro, morty, etc), has its own dependency "complex" tree between packages, that's why it is complex to start from a given version and try to modify a package version like glibc or gstreamer. Right ? Nov 13 17:29:39 Is that a correct way to view the complexity of yocto ? I thought that a build system (any, not only yocto) should try to make this dependency issue simpler to work with, but seems that I was wrong :( Nov 13 17:30:12 it's not magic. Nov 13 17:33:05 Thanks, I just wanted to be sure I am not missing something (I actually thought at first that there is a magic, but now that I now a bit more, I am awake to reality) Nov 13 17:33:08 upgrading gstreamer is much less of a problem than glibc, glib as the system C library is much closer to the root of the dependency graph, whereas gstreamer is a leaf with far fewer connected edges Nov 13 17:37:09 ranran: ewll, its complex to upgrade glibc because upgrading glibc is complex Nov 13 17:37:26 like, upgrade glibc and boom lots of stuff that used to work now breaks Nov 13 17:37:32 yay glibc upgrades, so much fun Nov 13 17:37:40 almost as fun as a new gcc Nov 13 17:38:21 Thank you all for the comments ! Nov 13 18:04:59 Hi I am using Yocto Pyro where in libepoxy does not build, it says EGL requirements not met and fails, although I have proper EGL binaries Nov 13 18:14:16 Mads__: that sounds sticky Nov 13 19:15:31 New news from stackoverflow: Unable to fetch from git.ti.com? [on hold] Nov 13 19:20:27 Hmm, we get lots of questions being marked off topic. I kind of agree with reasons, but it is annoying non experts in "Yocto" are making the call Nov 13 19:20:48 and yes, I know that the use of Yocto in the that statement is absurd Nov 13 19:26:58 Hi I m using yocto pyro, wherein cairo failes at do_package_qa ""ERROR: cairo-1.14.10-r0 do_package_qa: QA Issue: /usr/lib/libcairo-gobject.so.2.11400.10 contained in package cairo-gobject requires libMali.so.7()(64bit), but no providers found in RDEPENDS_cairo-gobject? [file-rdeps]"" Nov 13 20:44:16 How do I get the `work-shared` folder with `kernel-source` to show up after a bitbake? Nov 13 20:44:38 I want to see if my kernel was correctly patched Nov 13 21:10:02 Nevermind, I figured it out Nov 13 21:10:03 bitbake -c patch virtual/kernel Nov 13 21:14:29 Hi, I am building cairo in yocto pairo, it failes at do_package_qa:QA Issue: /usr/lib/libcairo.so.2.11400.10 contained in package cairo requires libMali.so.7()(64bit), but no providers found in RDEPENDS_cairo? [file-rdeps] Nov 13 21:14:38 ERROR: cairo-1.14.10-r0 do_package_qa: QA Issue: /usr/lib/libcairo-script-interpreter.so.2.11400.10 contained in package cairo-script-interpreter requires libMali.so.7()(64bit), but no providers found in RDEPENDS_cairo-script-interpreter? [file-rdeps] Nov 13 21:17:42 Mads_: see https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217 for possible work arounds Nov 13 21:17:43 Bug 9217: normal, Medium, 2.5, Martin.Jansa, ACCEPTED , Many unsolveable QA warnings from build-deps and file-rdeps Nov 13 22:16:04 New news from stackoverflow: add one more source to the repo manifest || A bb recipe to add file to both initramfs and root Nov 13 22:26:45 is there a point of diminishing returns on CPU cores / RAM? Nov 13 22:27:14 IE, over 16GB RAM, or greater than 8 cores, doesn't have a big effect? Nov 13 22:27:29 I feel like I read something like that somewhere once, and now I am having trouble finding that info Nov 13 22:28:06 trying to spec out a build server for a client, not going for the Cadillac here but maybe the Hyundai Genesis or something lol Nov 13 22:31:45 bodangly: https://wiki.yoctoproject.org/wiki/Build_Performance Nov 13 22:32:48 That mentions the 8-core 'limit' Nov 13 22:33:55 ah yes that must have been where I saw that Nov 13 22:34:31 thanks Nov 13 22:34:37 np Nov 13 22:34:39 thats ooold Nov 13 22:35:12 bulk of the page comes from 2012 Nov 13 22:36:11 best approach is plenty of everything. 32gb of ram, dual processors that can go fast. Nov 13 22:39:58 I'll keep that in mind too, thanks rburton Nov 14 02:26:30 RP, about the gcc ssp backporting to pyro; is this any good? http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144283.html Nov 14 02:29:05 I mixed the 2 commits into 1 and submitted the final patch; there was no point to send both as the second one contained fixes to the first one **** ENDING LOGGING AT Tue Nov 14 03:00:01 2017