**** BEGIN LOGGING AT Fri Feb 08 02:59:56 2019 Feb 08 09:22:03 kanavin: any objection if I squash a few of your python patches together and move it back to python instead of python-sanity ? Feb 08 09:31:55 Hi, I have a problem regarding sstate and rebuilds of images. When I change my recipe PV, which currently just does do_install and do_deploy a ASCII file, the ipk and deploy step is done correctly and all files are updated. But the image including this recipe does not rebuild and uses the old version. https://pastebin.com/4rxX0Fhq is an example how this was done. Does someone have an idea, what to do, to make the image update itself? Feb 08 09:50:39 evotion: how is the image depending on this recipe? Feb 08 09:51:04 evotion: also, how is PV in the recipe set? Feb 08 09:55:05 RP: PV is set via the recipe file name. The package is in PACKAGE_INSTALL of the image. Feb 08 09:55:41 so all the deploy stuff is redundant? Feb 08 10:05:21 evotion: why PACKAGE_INSTALL and not IMAGE_INSTALL? Feb 08 10:13:09 RP: Because its a custom image that is used on another partition than the actual rootfs. But I tried it on another image using IMAGE_INSTALL and had the same problem. Feb 08 10:15:15 evotion: there are signs something odd is going on since your do_deploy excludes DATETIME yet you don't reference it anywhere. If DATETIME was a key part of the PV and you disable it, that would stop it rebuilding. Feb 08 10:15:23 evotion: its also odd to have do_deploy and use the ipk Feb 08 10:15:32 aehs29, it was easier to work on the update that way, I do not like having it all mixed up with other recipes in the same folder Feb 08 10:15:35 evotion: so things don't quite add up but its hard to say why Feb 08 10:15:58 RP: I don't object, although I have a preference for keeping it in its own folder separate from other recipes Feb 08 10:16:28 kanavin: python-sanity isn't a good choice of name for that :/ Feb 08 10:16:55 RP: we should probably do the same for perl then, there is a perl-sanity folder currently Feb 08 10:17:11 kanavin: yes, that is also something I'm planning to change Feb 08 10:19:38 hi Feb 08 10:34:17 RP: The DATETIME is excluded for do_deploy. Running bitbake with the recipe for the package, the do_install and do_deploy is rerun and the ipks are rebuilt. Building directly the image or after rebuilding the package, does not refresh the image. Doing this with another package, leeds to a rebuild of the image. Feb 08 10:45:43 evotion: you mean "bitbake " does nothing or that the image rebuilds but doesn't contain the new firmware? Feb 08 10:46:10 evotion: *why* is DATETIME excluded for do_deploy? Feb 08 10:46:25 evotion: why do you even need do_deploy if the fimware is in the image? Feb 08 10:47:08 evotion: This feels like we've only got part of the story. What you say doesn't make sense and the there are several things which clearly don't add up. Not sure how we can help given that :( Feb 08 10:54:36 RP: Running bitbake does trigger a rebuild of the package. The ipk has the correct version of the package, but the file in the image does not get updated. Running bitbake -v i see do_populate_sysroot_setscene, do_deploy_setscene, do_package_write_ipk_setscene and do_packagedata_setscene. Feb 08 10:58:25 evotion: does "bitbake -e | grep PACKAGE_INSTALL=" show you the entry you think it does? Feb 08 10:58:54 evotion: does "bitbake -g" and looking at task-depends.dot show a dependency on your firmware recipe from the image do_rootfs ? Feb 08 11:00:10 RP: Both show the dependency to the firmware. Feb 08 11:00:55 RP: bitbake -g shows a runtime depends Feb 08 11:58:48 New news from stackoverflow: spi slave on imx8qmlpddr4arm2 board using yocto Feb 08 12:02:57 evotion: should work then Feb 08 12:07:54 RP: I thought it could be some missing sstate dependency missing, that does not retrigger the image build. Doing a cleansstate works also Feb 08 12:23:19 evotion: something doesn't make sense here :( Feb 08 12:24:51 i'd start by deleting all the deploy bits Feb 08 12:34:53 rburton: I tried this, but does not make any difference Feb 08 12:36:59 whats't the recipe without the deploy bits in? Feb 08 12:38:39 rburton: This is the new recipe https://pastebin.com/rMi21CBw Feb 08 12:46:35 does the PV strictly increase? Feb 08 12:46:48 also no need for pakagearch=all if you inherit allarch Feb 08 12:47:09 FILES should be /firmware/${HEX_INSTALL_NAME} Feb 08 12:49:10 * psaavedra[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/AKZcASWSAWypLEqJELbimAEv > Feb 08 13:04:25 rburton: The PV can also decrease especcially when testing. Feb 08 13:04:53 rburton: Normaly it increases only. Feb 08 13:06:26 so does it not rebuild the image when asked, or does it rebuild with the wrong content Feb 08 13:06:51 It does rebuild the package, but does not change the content in the image Feb 08 13:07:24 I'll try to only increase the package Feb 08 13:07:48 and when that happens you did ask bitbake to rebuild the image too right Feb 08 13:08:11 (just building the firmware recipe won't rebuild everything that depends on it) Feb 08 13:08:23 ie you're doing bitbake myimage (which depends on the firmware) Feb 08 13:08:45 Yes I just run bitbake and that leeds to a rebuild of the firmware Feb 08 13:09:17 check deploy dir and verify the right package is in there Feb 08 13:09:26 (with the right content) Feb 08 13:09:49 images are built from package, so check the packages and see what is happening Feb 08 13:10:09 if the package if fine then you know its rootfs construction that is not doing what you expect Feb 08 13:15:42 rburton: rootfs is not retriggered when running bitbake , the ipk package is rebuilt and the content is also correct. Feb 08 13:16:44 evotion: Either the sstate checksum of the do_package_write_ipk task didn't change (in which case it wouldn't rebuild), or the rootfs isn't depending on it Feb 08 13:17:43 evotion: you've stated it does change and the rootfs does depend on it. So either we don't understand the system, bitbake is broken, or one of these things isn't true Feb 08 13:19:12 RP: The ipk changes, the content of the image does not, but the dependency is there (it also gets rebuild). Feb 08 13:19:46 evotion: so bitbake is broken or I don't understand the system Feb 08 13:20:58 evotion: keep in mind nobody else is seeing such a problem and I was the author for large parts of sstate Feb 08 13:21:52 RP: Indeed the do_package_write_ipk checksum in stamps does not change between the two builds Feb 08 13:22:21 RP: We have to use krogoth, was there any bug you know about? Feb 08 13:22:25 evotion: right, so there is some problem in the firmware recipe rather than the rootfs code Feb 08 13:22:46 evotion: krogoth had lots of bugs :( Feb 08 13:22:53 evotion: We've moved on a lot since then Feb 08 13:23:42 evotion: are you using any other varpdeps* flags you're not telling us about? Feb 08 13:24:28 RP: No, this is the complete recipe. Feb 08 13:25:20 evotion: have you tried setting PV automatically, PV = "X.X+svn${SRCPV}" ? Feb 08 13:25:39 evotion: you're using autorev but haven't tied the PV to the automatic revisions Feb 08 13:25:47 RP: I'll try to build just that image with sumo, to check if it is a bug. Feb 08 13:26:38 evotion: I suspect this is something to do with how you're setting PV and that it isn't rebuilding Feb 08 13:27:01 Hi, I want to print out the yocto documentation, is there any kind of PDF format? Feb 08 13:27:47 sb79a: the docs Makefile used to be able to generate a pdf at least... Feb 08 13:27:57 sb79a: its docbook based so I'm sure it can be generated Feb 08 13:28:12 ok thanks, I will do it in this case Feb 08 13:32:20 RP: Is the recipes filename version used to determine PV or SRCPV? Feb 08 13:32:33 evotion: filename by default Feb 08 13:32:43 evotion: you have to set it to use SRCPV Feb 08 13:32:47 Hello all, someone here knows the syntax for arithmetic operation on Yocto variable ? (eg. BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count() / 2 }" Feb 08 13:34:25 PinkSnake: its python Feb 08 13:34:56 BB_NUMBER_THREADS ?= "${@ }" Feb 08 13:36:59 RP: ok thx i will take a look thx Feb 08 14:17:00 RP: Thanks for your help. I'll give it a try. Feb 08 14:18:29 * zeddii has to remember to make zeddii_home -> zedii later today. Feb 08 14:25:12 zeddii: switching machines around was a nightmare for me :/ Feb 08 14:25:35 RP: I compared build times for core-image-minimal (no sstate) with and without virgl/gtk - it does go up from 28 to 32 minutes Feb 08 14:26:13 kanavin: ah, that is useful to know thanks. I was going to try and test this on the autobuilder too! Feb 08 14:26:25 kanavin: just have to fix the scripts first Feb 08 14:27:43 RP: you're welcome. I really tried super-hard to make the current sdl frontend work, but it either crashes, or shows a blank screen. Not sure why this hasn't been noticed upstream. Feb 08 14:28:10 RP: indeed. I did my last set of patches from my new machines, to see what I had missed .. and did find a few things! Feb 08 14:28:17 kanavin: I guess its something which just doesn't get tested :( Feb 08 14:28:19 RP: I also tested with qemu provided by fedora and opensuse, and they both have the same 'blank screen' problem as our qemu, when using sdl Feb 08 14:28:59 gtk on the other hand is fine Feb 08 14:29:14 kanavin: should we report it to them? Feb 08 14:30:28 kanavin: I do want ross to look this one over so we're waiting on him having time for that Feb 08 14:30:50 RP: I'm not sure I would have time to follow up on the bug report to be honest Feb 08 14:31:45 kanavin: ok, fair enough Feb 08 14:32:46 I've trouble to package a recipe I wrote with a DEPENDS as another recipe I wrote Feb 08 14:33:08 the dependence is a C library Feb 08 14:33:40 I get this error: "vesta-app-2.0.0-r0 do_package_qa: QA Issue: /home/root/VestaApp/VestaApp contained in package vesta-app requires libmonocypher.so, but no providers found in RDEPENDS_vesta-app? [file-rdeps]" Feb 08 14:34:12 I've DEPENDS = "monocypher" in vesta-app_2.0.0.bb Feb 08 14:34:47 and this recipe as monocypher_2.0.5.bb: https://paste.ofcode.org/fAq8HWKHG3Z5MiEazHxGxb Feb 08 14:37:31 what's wrong with it? Feb 08 14:38:36 didile: you had to set FILES? that suggests the library layout isn't standard? Feb 08 14:39:38 didile: it may be the auto library dependency code isn't handling that and hence you need to set RDEPENDS_vesta-app manually? Feb 08 14:41:26 RP: I've added FILES_${PN} = "${libdir}/*.so*" and INSANE_SKIP_${PN} = "ldflags" (see my recipe here: https://paste.ofcode.org/fAq8HWKHG3Z5MiEazHxGxb) Feb 08 14:47:28 didile_: I know, that why I commented on it Feb 08 14:47:46 didile_: I'm wondering why the default FILES didn't work Feb 08 14:53:22 RP: I'm on sumo Feb 08 14:55:22 RP: maybe this is a confusion between $prefix and $libdir? Feb 08 14:56:32 didile_: FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} is the default (from bitbake.conf) Feb 08 14:56:39 SOLIBS = ".so.*" Feb 08 14:57:20 didile_: so I stand by what I said, it seems your versioning in this recipe is different and its likely confusing the automatic dependency generation code Feb 08 14:57:33 didile_: have you tried adding an RDEPENDS manually? Feb 08 14:58:02 RP: yes I've tried RDPENDS with "monocypher" or "libmonocypher" Feb 08 14:58:16 RP: but no luck :( Feb 08 14:58:37 RP: maybe I need to use FILES += instead if FILE = ? Feb 08 14:58:49 RDEPENDS_vesta-app += "monocypher" ? Feb 08 14:59:32 RP: RDEPENDS_${PN} += "monocypher" Feb 08 15:00:07 I have DEPENDS = "qtwebengine qtwebchannel monocypher" actually Feb 08 15:00:20 only monocypher gives me this error Feb 08 15:00:31 because it's probably a bad recipe (it's mine) Feb 08 15:00:43 didile_: check that the monocypher packages have the correct contents I guess Feb 08 15:01:10 didile_: I tend to worry when you have to deviate from the defaults like FILES Feb 08 15:02:05 RP: what's the way to check that? Feb 08 15:02:11 bitbake -c devshell monocypher ? Feb 08 15:02:47 didile_: look at the contents of the ipk files it generates? (or the packages-split directories in workdir) Feb 08 15:02:48 RP: maybe there is a way to look at the generated sysroot? Feb 08 15:04:09 RP: where are packages-split directories? Feb 08 15:05:38 RP: I've found only 3 packages-split directories in work/ directory but none for monocypher Feb 08 15:11:10 didile_: rm_work enabled? Feb 08 15:11:13 RP: if I run a find command in the tmp directory I get this output: (https://paste.ofcode.org/syKtWgUbav7hrHULB7qC7p) Feb 08 15:11:23 RP: yes it is Feb 08 15:11:47 didile_: it'll have cleaned up those files then Feb 08 15:12:02 RP: ok Feb 08 15:12:14 didile_: I come back to the question, why you need that FILES line. The lib names don't look that unusual Feb 08 15:12:31 RP: I removed it Feb 08 15:12:49 RP: just now Feb 08 15:14:14 RP: it's not responsible for this error Feb 08 15:14:30 didile_: clearly not, but helps to rule it out and clean up your recipe Feb 08 15:14:49 RP: right Feb 08 15:15:30 didile_: you skip the ldflags warning. I wonder if there is are flags in there you need Feb 08 15:17:01 RP: I removed it to see what happen Feb 08 15:17:56 RP: without it I have another error at some point but it doesn't change the current error Feb 08 15:19:43 didile_: if "bitbake monocypher" doesn't build cleanly without warnings, sort that out first Feb 08 15:19:59 didile_: we add these warnings for reasons Feb 08 15:20:20 what do i delete from a build directory to leave the configuration intact in case i want to rebuild it later? just rm -rf cache tmp? Feb 08 15:21:14 my sstate-cache and downloads are in a separate dir and i always leave those unless i'm desperate for space... Feb 08 15:21:32 RP: I get: "monocypher-2.0.5-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 'tmp/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/packages-split/monocypher/usr/lib/libmonocypher.so.2' [ldflags]" Feb 08 15:22:07 RP: the line INSANE_SKIP_${PN} = "ldflags" fixes it Feb 08 15:24:11 didile_: it doesn't fix it, it hides the warning Feb 08 15:24:45 didile_: I'm wondering if the lack of ldflags means the binary is in a form which the dependency code isn't understanding Feb 08 15:25:49 fury: tmp is the large one and safe to remove. cache isn't large but is usually safe unless you have prserv data in there Feb 08 15:26:32 RP: thanks! Feb 08 15:27:37 RP: I don't see the need for ldflags in the Makefile Feb 08 15:27:43 RP: I have got LTO working for llvm but it really takes loooong time to compile llvm however, the runtime gains are almost double speed Feb 08 15:28:16 even Thin-LTO the compile time for llvm is 2.5times :) Feb 08 15:28:22 i have a 512 gig SSD and i keep needing to trim old builds, usually i just delete the whole build directory because i've not customized the config at all, but this one's unique (suppose that means i should script the config mods so i can safely delete the whole build dir :P) Feb 08 15:29:21 fury: usually deleting tmp/ and then running openembedded-core/scripts/sstate-cache-management.sh -d -y --cache-dir=$OE_BASE/build/sstate-cache Feb 08 15:29:23 helps Feb 08 15:29:33 to keep the disk-size in check Feb 08 15:30:07 I have 500G SSD as well, it lasts me a week, but I do crazy things which is not normal Feb 08 15:30:54 Maybe I should use gold to link llvm always hmmm Feb 08 15:33:47 that's a neat script! my sstate-cache dir is about 120 gigs by now, wonder what the script will do to it... (running now, but prolly a bad idea as i'm also building a new image for beaglebone :P) Feb 08 15:34:08 RP: I followed this article: https://www.lynxbee.com/how-to-fix-error-do_package_qa-qa-issue-no-gnu_hash-in-the-elf-binary/ Feb 08 15:35:39 RP: and the like TARGET_CC_ARCH += "${LDFLAGS}" solved this specific issue Feb 08 15:35:42 i'm asking santa and/or the IT department for a new 500 gig drive so i don't have to delete so much - since i'm playing with so many images/boards, i inevitably have to rebuild one i deleted 3 or 4 trims ago, so if i had one more drive to put them on, i wouldn't need to rebuild so much Feb 08 15:35:51 RP: the line* Feb 08 15:36:04 RP: bitbake monocypher works Feb 08 15:36:24 RP: but I still have the REDEPENDS_vesta-app error Feb 08 15:45:35 didile_: for the GNU_HASH issue, add ${LDFLAGS} to the $CC command ;) Feb 08 15:46:20 RP: I think that TARGET_CC_ARCH += "${LDFLAGS}" does that Feb 08 15:46:31 PinkSnake: I think that TARGET_CC_ARCH += "${LDFLAGS}" does that Feb 08 15:46:57 didile_: I have tested also and both seems to work, you're right Feb 08 15:48:20 didile_: If you make it RDEPEND on monocypher-dev does it "solve" the warning? Feb 08 15:48:50 didile_: I'm wondering if its linking against the unversioned .so instead of the versioned one Feb 08 15:50:09 RP: I added monocypher-dev to RDEPENDS_${PN} without success :( Feb 08 15:50:21 RP: this is not a warning but an error: "ERROR: vesta-app-2.0.0-r0 do_package_qa: QA Issue: /home/root/vesta-app/vesta-app contained in package vesta-app requires libmonocypher.so, but no providers found in RDEPENDS_vesta-app? [file-rdeps]" Feb 08 15:51:07 I changed VestaApp for vesta-app because of this post: https://forums.xilinx.com/t5/Embedded-Linux/Missing-libc-so-6/m-p/858464/highlight/true#M26242 Feb 08 15:53:11 RP: maybe the "-" character is also forbidden like the uppercase characters... Feb 08 15:59:12 didile_: its no Feb 08 15:59:14 not Feb 08 15:59:29 RP: yes that's right (I tried) Feb 08 16:00:21 didile_: if you install vesta-app into bindir do you see this error? Feb 08 16:01:14 didile_: there is something odd about your case as the dependency code usually works but quite what is wrong I don't know Feb 08 16:01:53 RP: ok Feb 08 16:04:17 didile_: you could also try looking at (and/or sharing) the do_package logs for both the app and the lib. there are lines in there like LIBNAMES: and the section "calculating shlib requirements" Feb 08 16:09:52 RP: same if I install vesta-app into bindir: "ERROR: vesta-app-2.0.0-r0 do_package_qa: QA Issue: /usr/bin/VestaApp contained in package vesta-app requires libmonocypher.so, but no providers found in RDEPENDS_vesta-app? [file-rdeps]" Feb 08 16:11:29 RP: the logs of the do_package_qa task: https://paste.ofcode.org/Gxz9dEhK5Xd4PRbipGfwPp Feb 08 16:13:45 didile_: I said do_package, not package_qa Feb 08 16:13:46 RP: the logs of the do_package task of monocypher: https://paste.ofcode.org/5SUbJMnFcETdnNWETf4Lm8 Feb 08 16:14:38 didile_: arm-poky-linux-gnueabi-objdump: 'poky/build-neo/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/packages-split/monocypher-dev/usr/lib/libmonocypher.so': No such file Feb 08 16:14:43 RP: the logs of do_package for vesta-app: https://paste.ofcode.org/Zry2jfuTQwmfG6YpGCMkKk Feb 08 16:14:44 didile_: that looks bad Feb 08 16:14:51 RP: yes Feb 08 16:15:10 didile_: probably a bad symlink, try fixing that Feb 08 16:16:41 RP: in the makefile: https://github.com/LoupVaillant/Monocypher/blob/master/makefile Feb 08 16:17:49 RP: I guess this line "ln -s $$(basename $<) $@" Feb 08 16:18:11 RP: for the rule lib/libmonocypher.so Feb 08 16:21:01 didile_: first question, is the symlink bad? Feb 08 16:24:54 RP: I don't known if it's "bad": https://paste.ofcode.org/aTmCiuXXbUuQybhkKZyyrH Feb 08 16:28:40 RP: there is only libmonocypher.so and a pkgconfig directory inside /monocypher-dev/usr/lib/ Feb 08 16:37:34 RP: the logs of monocypher do_compile: https://paste.ofcode.org/5qqmR3eNhx8PvAigH9tTYQ Feb 08 16:40:59 didile_: so where is libmonocypher.so.2 ? Feb 08 16:42:02 RP: in the sources dir (git/lib/monocypher.so) Feb 08 16:42:12 didile_: ah, you mean libmonocypher.so.2 is in /monocypher/usr/lib/ ? Feb 08 16:42:14 hi, how do I fetch/write recipes for git lfs based project Feb 08 16:42:52 RP: I'm wrong you said libmonocypher.so.2 sorry Feb 08 16:43:21 RP: it's in /packages-split/monocypher/usr/lib/libmonocypher.so.2 Feb 08 16:43:47 RP: and libmonocypher.so is only in /packages-split/monocypher-dev/usr/lib/libmonocypher.so Feb 08 16:44:13 didile_: what does ls -la tmp/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/image/usr/lib show ? Feb 08 16:45:11 https://paste.ofcode.org/fmKybrzJ5wbAxHDuV77WRr Feb 08 16:46:01 didile_: it looks ok to me, that error is almost certainly the problem, just a question of why Feb 08 16:46:15 RP: ok Feb 08 16:46:35 RP: I'll investigate on monday Feb 08 16:46:44 RP: thanks for your help :) Feb 08 16:54:06 Noob here, trying to use devtool to update python recipe. See error about "Task do_create_manifest ... depends on non-existent task do_patch ..." Feb 08 16:54:21 when running `devtool build` Feb 08 16:55:00 the example `nano` devtool workflow works okay, but obviously doesn't have any patches being applied in the recipe Feb 08 16:59:48 hello, how to fetch git lfs based package. Appreciate help Feb 08 17:03:55 sray: python is *hard* to upgrade, don't bother basicall Feb 08 17:04:09 there's patches on the list right now to update to 3.7 Feb 08 17:04:24 rburton: already in master \0/ Feb 08 17:05:28 Ah thanks :) I was seeing what was possible with devtool, I do have those 3.7 patches. I'll go that route instead. Thank you. Feb 08 17:08:33 Do you know if this is just a general issue with devtool, that it doesn't support recipies with patches in them? Feb 08 17:12:12 no, it's not a general issue Feb 08 17:12:20 devtool was designed to work with patches Feb 08 17:12:44 of course, there's no guarantee they'll all apply after the upgrade, but taht's true whether you use devtool for the upgrade or not Feb 08 17:13:07 Hrm.. so why does it fail to find the do_patch method? It looks like there is a missing include/lib or something like that Feb 08 17:13:30 do_create_manifest is the issue, which doesn't exist anywhere else Feb 08 17:13:39 that's python specific Feb 08 17:15:34 Okay, good to know. I appreciate the help! Feb 08 17:22:05 Is it terrible to use the tip of master for developing against now? Assuming we pin the commit etc, until the next release with Python 3.7.x is out? I'm not sure how stable it is and what other pain points that might cause Feb 08 17:23:34 sray, that's a question that can only be answered by trying it out Feb 08 17:23:46 master does get tested Feb 08 17:23:51 Ignore that question :) I wasn't thinking about the layer name dependencies for third party layers etc. Feb 08 17:31:01 Do you know when the `thud-next` tag gets updated? Feb 08 17:31:56 whenever the thud maintainer updates it :) Feb 08 17:34:53 Ha! that is fair :) Feb 08 18:18:18 hmm, all our do_package logs are filled with those file not found messages :( Feb 08 18:32:27 RP, AB maintenance is complete and ready for work. Feb 08 18:41:30 fray, yet another gitsm issue found Feb 08 18:42:29 we have a broken recipe here which lists multiple gitsm uris in SRC_URI and doesn't set SRCREV_FORMAT Feb 08 18:42:55 then SRCPV fails to expand, and this isn't properly caught by the unpack task Feb 08 18:43:12 which results in a generic unhelpful failure Feb 08 18:43:19 I sent a patch to bitbake-devel for this Feb 08 19:04:09 halstead: thanks, I'll fire a -next build Feb 08 19:04:19 :) Feb 08 19:06:29 halstead: I held off earlier :) Its running now Feb 08 19:06:40 kanavin: do we need a new test case? Feb 08 19:07:21 RP, Thank you. I went to execute the graceful shutdown we talked about but it was already idle. :) Feb 08 20:00:32 New news from stackoverflow: How do I generate an ordered lists of the executed tasks when bitbaking a package? Feb 08 20:23:20 RP: do we use xz for sstate now ? or still gzip Feb 08 20:23:51 I see tar -czS -f being called Feb 08 22:34:04 khem: gzip for speed iirc Feb 08 22:34:21 khem: parallel gzip is a lot faster Feb 08 22:36:00 RP: ok, so we use parallel gzip ? Feb 08 22:36:25 RP: I am seeing xz eating up memory since it threads too much :) Feb 08 22:36:52 on machines with 16cores/15GB ram xz gives up on some monsterous recipes Feb 08 22:37:03 16GB I mean Feb 08 22:39:35 khem: it uses pigz if available Feb 08 22:48:32 hi - khem: Would you mind to add multilib on your autobuilder? Feb 08 22:50:10 schnitzeltony: I think thats a good idea, I could do it for x86_64 build, but I am afraid it will end up with failures that no one will fix and will fall on to me Feb 08 22:51:39 You'll have me on your side :) - most fixes are simple Feb 08 22:53:55 I think the problem is people are not aware - for example ${PN} in SRC_URI Feb 08 22:56:25 schnitzeltony: let me see what I can do Feb 08 22:56:41 RP: so pigz on build host ? or can it use pigz-native ? Feb 08 22:57:08 khem: both would work if available Feb 08 22:57:44 khem: the sstate code simply uses pigz from PATH if available Feb 08 23:03:41 khem: I know it is yet another burden put upon you: How about more details on autobuilder results e.g if a recipe fails not for 'common' I don't know: is it musl related / clang (or multilib once tested) Feb 08 23:06:36 khem: did you end up using any of the config driver code for it? I've been planning a "reproduction" tool for failing OE-Core builds using the helper repo Feb 08 23:18:56 RP: no not yet Feb 08 23:19:21 schnitzeltony: the jenkins builds use gcc/glibc/musl/system combos Feb 08 23:19:31 schnitzeltony: my own builds use clang in some cass Feb 08 23:19:43 there are so many combinations we can go nuts Feb 08 23:20:18 khem: I'm sure we're all quite nuts by now! ;-) Feb 08 23:20:29 heh Feb 08 23:21:44 RP: I think Ross also came across this in past but I was enablinh LTO and found that we need to use COMPILER_AR and COMPILER_NM and COMPILER_RANLIB Feb 08 23:22:00 khem: he did run into it, yes Feb 08 23:22:10 RP: I was wondering if we should make default AR/NM/RANLIB point to this once for all Feb 08 23:22:21 khem: he had patches but I think you weren't keen Feb 08 23:22:38 since with binutils 2.32 I dont have many concerns with that Feb 08 23:23:04 clang when compiled with lto can compile 1.5x faster Feb 08 23:23:26 I was wondering if we can enable system-wide LTO the image could get similar benefits Feb 08 23:23:31 and code is smaller too Feb 08 23:23:54 but build time is longer but thats the compromize Feb 08 23:24:51 I believe its ok to spend some time compiling the compiler which will compile the rest of system faster and compile rest of system with LTO as well and spend some time doing so, such that the resulting code will be smaller and faster which will run on targets Feb 08 23:25:09 I dont know if I made sense there but anyway thats the nuts part Feb 08 23:25:55 khem: I'd like to try our build time perf tests with this enabled Feb 08 23:26:50 thats a good idea Feb 08 23:28:47 khem: can't see ross' patch in his branches Feb 08 23:28:57 khem: he just talked about his test on list afaict Feb 08 23:29:17 khem: anyhow, if we put a branch together I can run it through our perf test on the AB Feb 08 23:29:33 khem: automatic results aren't quite there but can be done manually Feb 08 23:31:13 RP: world might not compile with lto Feb 08 23:31:30 but if we can test images I think that will be a good start Feb 08 23:36:54 khem: core-image-sato is our timing test target Feb 08 23:38:22 khem: btw, I'd tweaked the space in that glibc-locale patch. I only just read you had other tweaks after I'd merged the other one :/ Feb 08 23:39:25 * RP -> Zzzz Feb 08 23:40:04 RP: not to that recipe but other oe-core changes Feb 08 23:40:14 like libunwind patch Feb 08 23:40:19 I sent just now **** ENDING LOGGING AT Sat Feb 09 02:59:57 2019