**** BEGIN LOGGING AT Wed Feb 06 02:59:57 2019
Feb 06 04:47:50 <yocti> New news from stackoverflow: How to install graphics drivers in Yocto output image [closed] <https://stackoverflow.com/questions/54468744/how-to-install-graphics-drivers-in-yocto-output-image>
Feb 06 06:43:29 <acrap> Hi guys!
Feb 06 06:43:57 <acrap> Can you help me? Is there way to postpone some task to the first build?
Feb 06 06:44:06 <acrap> *to the first run?
Feb 06 06:45:18 <acrap> I've tried to google it, but wasn't managed to find information. May be you can just point me where I can find it?
Feb 06 06:46:40 <acrap> Oh, I've found!
Feb 06 06:48:33 <acrap> Oh, no. It's different one. The question is still open
Feb 06 06:49:02 <acrap> I've found info about postinstall script, but it's not about the first run
Feb 06 06:51:22 <acrap> The problem I am trying to resolve is about tricky build process, that uses target binaries during the compilation process.
Feb 06 06:57:29 <LetoThe2nd> acrap: maybe try to explain what you are *ACTUALLY* trying to archieve. the "postpone" thing sounds massively like a xy problem
Feb 06 06:59:40 <acrap> I am trying to build fips-enabled openssl for 64bit target. When crossbuild it uses the special incore script in the last step to embed a signature to ELF. And this script just is limited to use only with 32bit ELF (it prints that ELF64 supported only natively)
Feb 06 07:00:20 <acrap> I can't run it "natively" cause it trying to run target's binaries during the build process
Feb 06 07:00:56 <LetoThe2nd> so you are trying to shift something from build time to run time?
Feb 06 07:01:27 <acrap> shure, because I had already tried almost all of the another ways to solve that puzzle
Feb 06 07:01:31 <LetoThe2nd> namely this script
Feb 06 07:01:36 <acrap> incore
Feb 06 07:01:46 <acrap> it's a part of openssl-fips
Feb 06 07:02:56 <LetoThe2nd> i've avoided things like that so far. well. theoretically things can be postponed, of course. but it has a lot of consequences: you need a RW fs, and all the parts needed to run that script have to be shipped
Feb 06 07:04:09 <acrap> Both parts are possible. We had an RW filesystem and there are just a couple of files we need to add
Feb 06 07:05:21 <acrap> the only one question - is there way how to do it in Yocto or it's only one way to solve it with my own bicycle invention?
Feb 06 07:05:25 <LetoThe2nd> well then split the recipe in two? the first part sets the stage and all, the second recipe RDPENDS on the first, and actually only ships the sript and the first-run logic
Feb 06 07:05:49 <acrap> ok. Got it
Feb 06 07:05:50 <LetoThe2nd> it could also be done as two packages of one recipe.
Feb 06 07:06:53 <LetoThe2nd> also, there are postinstall scripts
Feb 06 07:06:54 <LetoThe2nd> https://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#new-recipe-post-installation-scripts
Feb 06 07:07:15 <LetoThe2nd> oops, here the latest version https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#new-recipe-post-installation-scripts
Feb 06 07:07:41 <LetoThe2nd> for a simple one-shot script that might even suffice
Feb 06 07:08:28 <acrap> got it. But postinstall scripts are run on host, aren't they?
Feb 06 07:09:24 <LetoThe2nd> yep, think so
Feb 06 07:10:28 <acrap> Thanks for the clues, I think I can do something with that
Feb 06 07:10:50 <LetoThe2nd> have fun
Feb 06 07:15:28 <acrap> Thanks! And just for information - building fips-enabled openssl in Yocto is a "very special pleasure". Fortunately, no one cares about FIPS-module anymore. There is even a special layer (non-free) to build fips-enabled openssl with Yocto :)
Feb 06 07:16:01 <acrap> It's not about Yocto, it's more about just cross compilation
Feb 06 07:16:25 <LetoThe2nd> i guessed that much
Feb 06 07:22:43 <malanecora> Morning guys!
Feb 06 07:24:19 <malanecora> Sometimes, randomly, when I'm running a huge task in Yocto (e.g. sdk extraction, first build of the whole system...) my VM "restarts" (not a real restart, more like a suspend but without saving the current machine state)
Feb 06 07:24:33 <malanecora> Has someone experienced issues like this one?
Feb 06 07:25:46 <malanecora> It's driving me nuts because some tasks need to be executed again (and again...)
Feb 06 07:32:30 <ak77> how do I add my custom suffix packages? (e.g. -xyz ?) so that they can all be turned on like -dbg packages?
Feb 06 08:12:45 <acrap> malanecora: sometimes I get my DE(Gnome shell) just reboot and bitbake is killed
Feb 06 08:12:59 <acrap> seems like we have a lack of resources
Feb 06 08:13:43 <acrap> as for me - for sure. Even my mouse cursor doesn't work during the Yocto build
Feb 06 08:15:04 <acrap> I even got a separate PC and share mouse and keyboard between them two (it's more convenient than a heap of manipulators on a table)
Feb 06 08:16:01 <acrap> Let alone that I have Core i7 7700 with a 8Gb RAM(seems like it's not enough for Yocto)
Feb 06 08:16:38 <LetoThe2nd> depending on what you are running in parallel, 8gb can be tough
Feb 06 08:16:53 <acrap> Maybe it's better to limit the number of parallel Yocto tasks, cause I have 8 parallel task in my case
Feb 06 08:17:05 <LetoThe2nd> and depending on what you are trying to build. if webkit or chrome or such is involved, that might be a killer
Feb 06 08:18:20 <acrap> Hah, sometimes I got a segmentation fault from cross gcc :) I suspect it's because a lack of RAM
Feb 06 08:18:48 <nayfe> ak77: FILES-${PN}-xyz = "..."  and PACKAGES += "${PN}-xyz"
Feb 06 08:19:47 <nayfe> and optional $RDEPEND_${PN} += "${PN}-xyz"
Feb 06 08:19:53 <nayfe> oops typo
Feb 06 08:19:55 <LetoThe2nd> acrap: if you are doing a lot of stuff on your desktop simultaneously, its possible
Feb 06 08:20:04 <LetoThe2nd> -> get more RAM
Feb 06 08:20:43 <acrap> Sure, I am waiting for another 8Gb module :)
Feb 06 08:20:45 <nayfe> you can also reduce parallel jobs :
Feb 06 08:21:04 <nayfe> already said
Feb 06 08:35:30 <RP> kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/199 is more clear, one failure left
Feb 06 08:42:55 <PinkSnake> I all, i'm collecting all example recipes in a meta in order to keep some templates :) but i have some trouble with qt5 demo-app, any idea ? .bb -> https://pastebin.com/mPwFcLD4 , error -> https://pastebin.com/MuGj0gas, .pro https://pastebin.com/NdKyuEg8 Thank you :)
Feb 06 08:46:58 <malanecora> acrap: Nice to know, I'll have to upgrade my HW
Feb 06 08:48:13 <acrap> malanecora: or just limit the amount of parallel tasks
Feb 06 08:48:22 <acrap> it may help too
Feb 06 08:48:37 <malanecora> acrap: I've just 4 aprallel tasks :/
Feb 06 08:49:52 <malanecora> But mb it does the job while waiting for the upgrade
Feb 06 09:26:39 <ak77> nayfe: I know that part, I already have many -xyz packages, but would like to turn them on with a flag
Feb 06 09:26:53 <ak77> nayfe: or a IMAGE_FEATURE
Feb 06 09:27:00 <PinkSnake> someone here can provide a recipe based on qt5 form arm arch ( rapi 3) ? I'm still stuck with QMAKE_INCDIR_OPENGL issue
Feb 06 09:47:01 <malanecora> qt3d build is failing when running "bitbake meta-toolchain-qt5" in Yocto Thud
Feb 06 10:21:56 <kanavin> RP: yep, disappointed to see that .pyc files are *not* arch-independent
Feb 06 10:22:18 <acrap> malanecora: 4 may be a big number if you gave minimal resources to your VM
Feb 06 11:04:13 <PinkSnake> still no info about build qt5base on raspi3 board ? :D
Feb 06 11:05:29 <PinkSnake> i have followed tutorial --> https://doc.qt.io/QtForDeviceCreation/qtee-meta-qt5.html but i don't know which value is needed inside QMAKE_INCDIR_OPENGL[_ES2] variable ...
Feb 06 11:08:35 <mckoan> PinkSnake: what's the problem? Which Yocto version are you using?
Feb 06 13:20:03 <PinkSnake> mckoan: I was on v2018.2 branch from Xilinx repo, i'm trying to switch to the official repo and build again. It's probably the trouble source :)
Feb 06 13:24:18 <malanecora> qtwebkit build freezes at 38% when trying to build. In addition, it eats all the RAM but keeps the processor nearly idle...
Feb 06 13:31:13 <PinkSnake> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb?h=sumo failed because of the commit number doesn't exist ...
Feb 06 13:31:46 <malanecora> Yocto processes are marked as D (disk sleep)
Feb 06 13:33:32 <malanecora> Can this be due to the full RAM?
Feb 06 13:34:18 <malanecora> Swap memory is also full
Feb 06 13:34:32 <malanecora> What is strange
Feb 06 13:43:10 <kergoth> malanecora: the final link with ld in qtwebkit needs like 4 gigs of ram by itself, iirc
Feb 06 13:43:32 <malanecora> kergoth: wow, thats pretty much
Feb 06 13:43:49 <malanecora> btw I have 4GB of RAM
Feb 06 13:43:51 <kergoth> big c++ projects...
Feb 06 13:43:59 <malanecora> And the same amount assigned to swap
Feb 06 13:44:28 <malanecora> Yah...
Feb 06 13:44:32 <malanecora> Thank you for the info!
Feb 06 13:45:24 <kergoth> i often have to reduce BB_NUMBER_THREADS just during its build to make sure its the only thing building. might be able to chnage the cflags to avoid building with debug symbols to reduce the memory usage slightly
Feb 06 13:45:34 <kergoth> google it, maybe htere are other options, *shrug*
Feb 06 13:48:01 <malanecora> Yes, rigth now I'm just building it in a standalone way but just stucks
Feb 06 13:48:31 <malanecora> I'll try to google that
Feb 06 13:59:48 <PinkSnake> after updating to thud branch i got this error: ERROR: Unpack failure for URL: 'git://git.savannah.gnu.org/config.git'. No up to date source found: clone directory not available or not up to date -- any idea to fix that ?
Feb 06 14:40:03 <PinkSnake> for informatino it was dur to a mess in download dir ;)
Feb 06 14:57:13 <RP> kanavin: they're not? ouch :(
Feb 06 14:57:33 <RP> kanavin: I didn't dig into the failure
Feb 06 14:57:42 <kanavin> RP: I looked, and the difference is only the embedded timestamp of the original .py module file
Feb 06 14:58:11 <RP> kanavin: right, that makes more sense
Feb 06 14:58:21 <RP> kanavin: we may get help from the reproducible code here
Feb 06 14:58:54 <kanavin> RP: still, this means we can't really share them between multilibs, so I'm reverting to installing them in ${libdir}, which means a bit more patching
Feb 06 14:59:12 <kanavin> .py files themselves are identical
Feb 06 15:02:08 <RP> kanavin: if we enable reproducible build the timestamps should match
Feb 06 15:02:27 <RP> kanavin: we can't do that everywhere but I'm wondering if we could enable some subset
Feb 06 15:13:16 <kanavin> RP: but as far as I understand, the timestamps are written into .pyc files at do_compile by python itself, do reproducible builds have special magic for it?
Feb 06 15:13:39 <RP> kanavin: aren't the timestamps based on the source file?
Feb 06 15:13:59 <kanavin> also, those timestamps do matter, as python uses them at runtime to find out if pyc needs rebuilding
Feb 06 15:13:59 <RP> kanavin: so if you have deterministic timestamps in the source, you can get the same value in the pyc?
Feb 06 15:14:02 <yates> paging Dr. derRichard
Feb 06 15:14:27 <yates> whois derRichard
Feb 06 15:14:29 <kanavin> RP: right. I'm not sure why they differ actually
Feb 06 15:14:35 <yates> i hate it when i do that
Feb 06 15:14:54 <RP> kanavin: I'm sure the reproducible stuff handled this somehow
Feb 06 15:26:42 <malanecora> kergoth: I assigned 8GB of RAM to the VM and now qtwebkit is taking every single bit of it
Feb 06 15:26:48 <kergoth> yikes
Feb 06 15:26:53 <malanecora> Plus the swap O.o
Feb 06 15:29:15 <LetoThe2nd> i actually am not surprised.
Feb 06 15:30:22 <malanecora> Not even a bit? haha
Feb 06 15:30:49 <LetoThe2nd> not at all.
Feb 06 15:30:58 <neverpanic> RP: https://reproducible-builds.org/blog/posts/144/ /.pyc
Feb 06 15:31:18 <LetoThe2nd> 08:16 < LetoThe2nd> depending on what you are running in parallel, 8gb can be tough
Feb 06 15:31:29 <LetoThe2nd> 08:17 < LetoThe2nd> and depending on what you are trying to build. if webkit or chrome or such is involved, that might be a killer
Feb 06 15:32:01 <LetoThe2nd> malanecora: i literally told you 8 hours ago.
Feb 06 15:32:13 <RP> neverpanic: thanks, kanavin ^^^
Feb 06 15:32:18 <neverpanic> RP: you'll probably need https://github.com/distropatches/cpython/commit/9edd2239a420e92f692ac0b1eff9d9a39cfc34ef
Feb 06 15:32:50 <malanecora> Just a VMware instance (the VM itself) + Chrome (5 tabs) + IExplorer (1 tab) + Slack + Outlook are running
Feb 06 15:33:14 <malanecora> My machine has 16GB of RAM
Feb 06 15:33:27 <LetoThe2nd> malanecora: if you're building in vmware, you're basically timescrewed anyways.
Feb 06 15:35:18 <malanecora> LetoThe2nd: I agree, but it's a work imposed constraint :(
Feb 06 15:36:30 <LetoThe2nd> malanecora: i'm just pointing out that this is the source of your problems. that, and lack of RAM
Feb 06 15:36:33 <LetoThe2nd> :-)
Feb 06 15:38:44 <malanecora> LetoThe2nd: Will try again closing everything which is "closable"
Feb 06 15:39:03 <malanecora> brb with news
Feb 06 15:39:10 <kanavin> neverpanic, RP thanks, I was just looking at the same in source tree :)
Feb 06 15:39:32 <kanavin> not sure how hashing module sources on each run will affect runtime performance to be honest
Feb 06 15:40:56 <kanavin> I think we can stay on the conservative side here, and keep time-based stamps
Feb 06 15:47:33 <malanecora> Ofc it didn't work haha
Feb 06 15:58:47 <RP> kanavin: no, I was worrying about what the alternative was
Feb 06 15:58:59 <RP> kanavin: I think our reproducible code just makes the timestamps consistent
Feb 06 16:00:15 <kanavin> RP: the reproducible builds class exports a magic environment variable which tells upstreams to not do timestamp-based decisions. Python starts honoring it from 3.7.2 onwards or so, by changing to storing hashes inside pyc.
Feb 06 16:01:21 <RP> kanavin: ah, that sounds suboptimal :/
Feb 06 16:03:51 <kanavin> RP: I'm still unsure why original .py files end up having different timestamps during build/install, but let's focus on getting the upgrade done and merged
Feb 06 16:06:52 <RP> kanavin: right, I was wondering about that. But yes.
Feb 06 16:25:46 <kanavin> RP: patchset send, hopefully this is the last one :)
Feb 06 16:29:03 <RP> kanavin: lets see :)
Feb 06 16:29:19 <RP> ah, armpit beat me with a sumo
Feb 06 16:30:46 <RP> kanavin: its queued to run next
Feb 06 16:31:49 <armpit> RP ?? for what
Feb 06 16:32:53 <RP> armpit: you're running a sumo-next, its fine
Feb 06 16:33:06 <armpit> RP, sumo-nmut not next
Feb 06 16:33:10 <RP> armpit: I backported a couple of key bitbake patches to thud btw
Feb 06 16:33:18 <RP> armpit: yes, that, whatever ;-)
Feb 06 16:33:41 <armpit> I saw.. any issues with what is in thud-next ?
Feb 06 16:33:54 <RP> armpit: I didn't know there were patches
Feb 06 16:34:24 <armpit> in poky proper..
Feb 06 16:35:00 * armpit thought I sent a pull request..
Feb 06 16:36:05 <RP> armpit: I may have missed it, sorry
Feb 06 16:36:10 * armpit then poky/thud-next got updated... so confused
Feb 06 16:37:03 <RP> armpit: can you rebase stable/thud-next please? It doesn't seem quite right
Feb 06 16:37:29 <kanavin> rburton: is glmark update related to virgl by any chance? :)
Feb 06 16:37:42 <RP> armpit: ah did I merge to the wrong branch?
Feb 06 16:37:51 <rburton> kanavin: sadly not
Feb 06 16:38:04 <armpit> RP, sure I can rebase
Feb 06 16:39:13 <RP> armpit: sorry, try now
Feb 06 16:39:25 <RP> armpit: That clears our my -next tree
Feb 06 16:39:54 <armpit> RP, thanks
Feb 06 16:40:02 <kanavin> rburton: I can run benchmarks with it though, thanks for the tip :)
Feb 06 16:40:14 <kanavin> kmscube or glxgears aren't exactly good for that
Feb 06 16:40:17 <rburton> kanavin: no
Feb 06 16:40:24 <rburton> glmark isn't a lot better but its better than nothing
Feb 06 16:40:42 <RP> kanavin: I was hoping to run the virtgl changes through the build perf tests before we merged it
Feb 06 16:40:56 <RP> kanavin: sadly the performance comparision code doesn't like comparing master to master-next :(
Feb 06 16:41:26 <RP> kanavin: we can run the build, just don't get a comparison
Feb 06 16:41:40 <RP> https://autobuilder.yocto.io/pub/non-release/20190206-3/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_master_20190206030025_52faf80.html
Feb 06 16:51:07 <kanavin> RP: we could probably win a lot by splitting qemu into usermode and system recipes. system is not needed during the build, yet it's the one that's dependent on all the native graphical stuff.
Feb 06 16:58:16 <rburton> true
Feb 06 16:58:26 <rburton> user qemu is basically headness
Feb 06 17:15:27 <JPEW> armpit: The busybox upgraded landed on master, can it be backported to thud?
Feb 06 17:35:13 <armpit> JPEW, got it.. thanks for the reminder
Feb 06 17:39:14 <RP> kanavin: that does sound quite appealing
Feb 06 18:25:30 <cdgarren> I'm trying to use cython on a module in a python application for my image. When I build I get an ImportError in the do_compile step saying "No moduel names Cython.Build". I thought that adding python-cython as a DEPENDS in my application recipe would be enough, but is not. Anyone know what I'm missing?
Feb 06 18:42:43 <rburton> python-cpython-native for a cpython youcan actually run at build time
Feb 06 18:42:51 <rburton> otherwise you just build the target one which isn't any use
Feb 06 18:45:45 <yates> if i use devtool to modify a recipe, and i subsequently do a "bitbake <image>", will that image be built with modified recipe from devtool?
Feb 06 18:46:34 <yates> i.e, prior to "devtool finish recipe layer"
Feb 06 18:56:20 <kergoth> yes
Feb 06 18:56:45 <kergoth> devtool modify adds the workspace layer to bblayers, unpacks and patches the sources, and creates a bbappend in the workspace that makes the recipe build using those sources
Feb 06 18:56:55 <kergoth> regardless of whether you're actually using devtool for every build
Feb 06 18:57:33 <yates> i see.
Feb 06 18:57:37 <yates> that's good
Feb 06 19:42:14 <cdgarren> rburton: thanks for the pointer, figured it was something simple.
Feb 06 20:54:13 <ComputerKarate> Trying to develop for a sweet sama5d3 board
Feb 06 20:54:24 <ComputerKarate> I followed the instructions at: https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
Feb 06 20:54:53 <ComputerKarate> Works until I try to create a layer
Feb 06 20:55:27 <ComputerKarate> The errors say that my setup is not compatible with thud but is compatible with sumo
Feb 06 21:51:17 <yocti> New news from stackoverflow: Workaround for tar 1.27's bug in Ubuntu 14.04 <https://stackoverflow.com/questions/31226962/workaround-for-tar-1-27s-bug-in-ubuntu-14-04>
Feb 07 00:21:47 <yocti> New news from stackoverflow: How to disable serial console(non-kernel) in u-boot <https://stackoverflow.com/questions/34356844/how-to-disable-serial-consolenon-kernel-in-u-boot>
Feb 07 00:37:13 <khem> RP: https://errors.yoctoproject.org/Errors/Details/221395/, the glibc-locale host-user-contaminated QA error keeps cropping up when using docker etc. I have sent a patch to get rid of using cp entirely in do_install for glibc-locale, which should probably uproot the problem once for all
Feb 07 00:37:28 <khem> see https://patchwork.openembedded.org/patch/158568/
Feb 07 01:31:37 <Quazil> I'm trying to create a .bbappend file and add some patches to a recipe in another layer.
Feb 07 01:31:37 <Quazil> After I add the .bbappend to my layer it can no longer find the patches from the original layer.
Feb 07 01:31:37 <Quazil> Any pointers on what to look into to try to figure out why.
Feb 07 01:31:37 <Quazil> https://pastebin.com/raw/eeAHaXMw
Feb 07 01:53:30 <bluelightning> Quazil: I don't see anything immediately wrong (other than '_append +=' but that wouldn't actually cause any problem)
Feb 07 01:54:27 <bluelightning> Quazil: bitbake -e recipename | less and have a look at the history for FILESEXTRAPATHS and SRC_URI, see if they're being set to what you think they should be, and then perhaps look at log.do_fetch to see where it looked for files
Feb 07 02:24:34 <Quazil> bluelightning: omg I copied the .bb file into the layer then cp'd it notmv'
Feb 07 02:24:51 <Quazil> bluelightning: not mv'd it to .bbappend. But thank you, I'm sure I'll use -bitbake e again
Feb 07 02:25:13 <bluelightning> cool, glad you solved it :)
Feb 07 02:25:35 <bluelightning> bitbake -e is a very useful diagnostic tool yes
**** ENDING LOGGING AT Thu Feb 07 02:59:57 2019