**** BEGIN LOGGING AT Thu Nov 07 02:59:57 2019
Nov 07 08:04:24 <kroon> RP, I'll send a follow-up rm_work cleanup patch for review once the image_qa fix is merged
Nov 07 08:04:47 <kroon> RP, unless you beat me to it
Nov 07 08:06:29 <RP> kroon: sounds good, thanks. I seem to be mainly destroying the autobuilder right now :/
Nov 07 08:24:28 <mcfrisk> is there some "for dummies" guide for creating poky git tree structure from oe-core etc?
Nov 07 08:28:09 <luneff> hey guys! Is there a guideline on how to update patch sets for a recipe? Due to apply failing I can't even unpack the package... Should I remove all of them and try to reapply them manually?
Nov 07 08:51:08 <mcfrisk> I guess combo-layer is the answer and all needed details are in https://wiki.yoctoproject.org/wiki/Combo-layer
Nov 07 09:25:58 <RP> mcfrisk: right, its done with combo-layer. The pokyconfig repo has most of the scripts I use in
Nov 07 09:27:20 <lion_heart> Hello, How can I hold on to psplash until X has loaded? I takes about 3 seconds for x+ my qt application to load which leaves a black screen
Nov 07 09:37:12 <lion_heart> I guess a real shitty way would be to add a sleeper in the destroy function but I assume there is a more sophisticated solution :p
Nov 07 09:46:01 <rburton> lion_heart: sato does this, don't switch VT on x startup and then switch when you're ready
Nov 07 09:46:28 <rburton> oh hm it used to do this
Nov 07 09:46:29 <rburton>        # dbus-wait org.matchbox_project.desktop Loaded
Nov 07 09:46:31 <rburton> why is that commented out
Nov 07 09:47:09 <rburton> ah because if X broke it never switched away
Nov 07 09:47:13 <rburton> anyway that's what you'd do.
Nov 07 09:47:36 <rburton> easily to tell X not to switch VT, and just switch when you're ready
Nov 07 09:59:38 <crawler> Hi everyone, im trying to build gsoap sdk part, and adding TOOLCHAIN_HOST_TASK_append = " nativesdk-gsoap" gets me an error like "ERROR: Nothing RPROVIDES 'nativesdk-gsoap'" - do i miss something here or is it a bug?
Nov 07 09:59:46 <mcfrisk> "bitbake world" in a project tree is like fireworks, explosions everywhere
Nov 07 09:59:55 <crawler> im using warrior branch
Nov 07 10:01:44 <lion_heart> rburton: That does indeed look nice. Basically I would add -novtswitch in the initfile and add something like openvt -s in my qt application? I'll try it out thanks a lot !!
Nov 07 10:03:06 * alessioigor waves all!
Nov 07 10:03:08 <alessioigor> Is there a way to override scripts/lib/wic/plugins/source/bootimg-efi.py?
Nov 07 10:09:04 <malanecora> Has anyone experimented problems trying to enable custom systemd services automatically at build time? SYSTEMD_AUTO_ENABLE is set to "enable" (by default), they don't start until I enable it manually the frist time though. Nevertheless, systemctl status myservice shows: myservice disabled, vendor preset: enabled....
Nov 07 10:11:49 <qschulz> malanecora: you followed and checked everything in https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-systemd ? (That'll be all for my contribution to the issue, never used systemd in Yocto)
Nov 07 10:13:27 <malanecora> qschulz: I did. Is not big deal...
Nov 07 10:14:31 <malanecora> I just can't see any issue with my recipes/servicefiles
Nov 07 10:15:18 <malanecora> They're quite simple, and as long as SYSTEMD_AUTO_ENABLE is set to "enable", that should be handled by Yocto itself
Nov 07 10:15:36 <mcfrisk> malanecora: which branch? I sent a patch for this for master but maybe zeus is missing that. 1b3f5bd39e7147eefca2 in poky master.
Nov 07 10:15:42 <malanecora> Plus no error nor warning is shown
Nov 07 10:15:48 <malanecora> mcfrisk: Thud
Nov 07 10:16:22 <malanecora> mcfrisk: Gonna check taht, ty!
Nov 07 10:16:48 <mcfrisk> I went from sumo to master/zeus and saw all custom systemd services failing. hence that patch.
Nov 07 10:18:08 <malanecora> mcfrisk: Mine don't fail, but they just dont get enabled at first start-up
Nov 07 10:18:45 <malanecora> So that I have to enable them by hand
Nov 07 10:31:11 <lion_heart> rburton: Hmm, starting X without vt switching does not seem possible. By looking at the command it says restart and exit and several forum threads are saying that -novtswitch on start was removed due to causing a lot of crashes
Nov 07 10:31:46 <rburton> lion_heart: is using wayland instead an option? :)
Nov 07 10:34:11 <lion_heart> rburton: Hm, I think I will just live with this for now. It is just 1-2 seconds of black screen (removed matchbox-terminal and cursor) anway
Nov 07 10:34:38 <lion_heart> and it's for a kiosk application so it will hopefully not be rebooted so often :)
Nov 07 10:34:40 <lion_heart> Thanks anyway!
Nov 07 11:12:00 <yocti> New news from stackoverflow: Customizing Yocto U-boot serial prompt messages <https://stackoverflow.com/questions/58663248/customizing-yocto-u-boot-serial-prompt-messages>
Nov 07 12:32:07 <mcfrisk> sigh, BSP layer breaking sstate cache and stale data pulled in do_install even after clean build. only wiping sstate cache for the recipe helps. any hints how to debug this?
Nov 07 12:39:21 * letothe2nd recommends a sledge hammer
Nov 07 12:40:45 <qschulz> letothe2nd: do you have an IRC higlight for "BSP" by any chance :'D
Nov 07 12:41:15 <letothe2nd> qschulz: heh, luckily not.
Nov 07 12:51:53 <Crofton|work> BSP's the root of all problems
Nov 07 13:03:53 <lion_heart> Anyone here that have tried running a mediawiki on imx6(A9)1gb RAM? I'm thinking of doing a yocto build for it just for fun but I'm not sure about the performance (have to run it on SD-card)
Nov 07 13:50:45 <__angelo> hi, how can easily check if a package is included in a recipe ?
Nov 07 13:50:56 <__angelo> *in an image recipe
Nov 07 13:52:44 <mcfrisk> sstate plot thickens. I can reproduce the issue, I see that do_install task is different, but it's not triggering rebuild of the recipe. could the reason be that PV = "1.0+git" is in the recipe?
Nov 07 13:54:04 <mcfrisk> sorry, PR = "r0" in the recipe?
Nov 07 13:55:07 <qschulz> __angelo: tmp/buildhistory/images/machine/installed-packages when you add INHERIT += "buildhistory" in your conf/local.conf and rebuild
Nov 07 13:59:53 <milloni> can i instruct bitbake to treat all warnings as errors?
Nov 07 14:03:00 <RP> mcfrisk: not really enough info to comment. Is this sumo?
Nov 07 14:04:58 <__angelo> qschulz, thanks
Nov 07 14:08:04 <milloni> <mcfrisk> sigh, BSP layer breaking sstate cache and stale data pulled in do_install even after clean build. only wiping sstate cache for the recipe helps. any hints how to debug this?
Nov 07 14:08:23 <milloni> i think the sstate cache could use some re-design
Nov 07 14:09:21 <milloni> do i understand correctly that the only simple way to share ssate cache between jobs is give direct access to the path where the sstate cache resides to the jobs
Nov 07 14:09:27 <milloni> e.g through nfs
Nov 07 14:09:50 <milloni> because if so it''ll be vulnerable to problems like that one
Nov 07 14:09:51 <qschulz> you can use SSTATE_MIRROR as well
Nov 07 14:10:00 <qschulz> but it's RO then
Nov 07 14:10:18 <milloni> qschulz: arguably it's not that useful if it's RO - i need a way to populate the cache
Nov 07 14:10:33 <milloni> in fact i've run into a similar problem with a low quality bsp
Nov 07 14:10:38 <RP> milloni: RO mirrors and then writing back additional artefacts post build does work
Nov 07 14:11:00 <RP> milloni: suggestions on a better design welcome but keep in mind it attempts to solve a hard problem. This is about v5 of that work
Nov 07 14:11:58 <RP> milloni: you have to write the data back to be shared *somehow* and there is no reason you couldn't add that mechanism to the existing sstate code if you had one
Nov 07 14:12:34 <RP> mcfrisk: can you share the two differing do_install functions and maybe the sigdata files that go with those tasks?
Nov 07 14:12:40 <milloni> i understand
Nov 07 14:12:55 <milloni> if ": RO mirrors and then writing back additional artefacts post build does work" then that solves the problem
Nov 07 14:13:03 <milloni> i wasnt allowed this worked
Nov 07 14:13:14 <milloni> i wasnt aware*
Nov 07 14:15:40 <mcfrisk> RP: zeus. non-public BSP sadly.. at least I can reproduce it now. For some reason PR is not updated automatically either... I need to review their bbclasses.
Nov 07 14:17:34 <RP> mcfrisk: sigdata files are where I'd be looking
Nov 07 14:22:51 <mcfrisk> RP: "bitbake-diffsigs -t recipe do_install" shows the exact diff that I want in do_install task. sadly I see some vendor prebuild binary magic in the bbclasses. they must be overwriting everything..
Nov 07 14:40:08 <cengiz_io> hello there! I have a library recipe that only copies .a files to libdir and .h files to includedir.
Nov 07 14:40:09 <cengiz_io> when I add "mylib-dev mylib-staticdev" to DEPENDS of another recipe (myapp), it fails with this:
Nov 07 14:40:09 <cengiz_io> ERROR: Nothing PROVIDES 'mylib-staticdev' (but myapp_1.0.bb DEPENDS on or otherwise requires it). Close matches:  mylib, mylib RPROVIDES mylib-staticdev
Nov 07 14:40:50 <cengiz_io> should I DEPENDS = mylib instead?
Nov 07 14:41:31 <cengiz_io> I needed to separate those because I need to include mylib-staticdev and mylib-dev in SDK but NOT in final target image.
Nov 07 14:43:15 <RP> mcfrisk: seems likely as that change should have made the signatures in that case :/
Nov 07 14:45:07 <mcfrisk> RP: yea. sigh. binary handling magic. first build works. second one doesn't. back to digging...
Nov 07 14:52:03 <fray> Didn't there used to be a section in the megamanual on debugging threaded programs?  I keep getting questions from people about debugging threaded programs and can't find a reference to point themt o
Nov 07 14:52:14 <fray> (they're missing the libc6-thread-db on the target)
Nov 07 14:52:23 <rburton> cengiz_io: depends is recipe not package
Nov 07 14:52:56 <cengiz_io> rburton ok so I've modified it to have just recipe name
Nov 07 15:11:11 <cengiz_io> ok rburton one last question
Nov 07 15:12:18 <cengiz_io> my image has TOOLCHAIN_HOST_TASK_append = "mylib-dev mylib-staticdev" but whenever I do bitbake -c populate_sdk my-image it fails with * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'mylib-dev'.
Nov 07 15:13:11 <cengiz_io> rburton do I have to include that recipe in my IMAGE_INSTALL too? if I do that, wouldn't those huge binary .a archives will be installed to target final image too?
Nov 07 15:16:37 <cengiz_io> hmm maybe not. since I don't add anything new to FILES_${PN}..
Nov 07 15:23:53 <cengiz_io> rburton adding IMAGE_INSTALL += "mylib" didn't solve it... bummer...
Nov 07 15:28:05 <wertigon> Hummmm... Why isn't meta-java thud branch compatible? >_<
Nov 07 15:29:43 <wertigon> So I have added the meta-java libarary, I include the openjre-8 package for compilation, and...
Nov 07 15:30:18 <wertigon> make: *** No rule to make target 'patch-fsg'. Stop.
Nov 07 15:30:30 <wertigon> ERROR: oe_runmake failed
Nov 07 15:33:52 <wertigon> Any ideas what I might do to fix this?
Nov 07 15:41:39 <wertigon> icedtea7-native seems to be the culprit
Nov 07 16:19:57 <cengiz_io> how can I add a recipe's -dev and -staticdev packages to my SDK?
Nov 07 16:20:07 <cengiz_io> (damn google does not return any results)
Nov 07 16:20:43 <rburton> cengiz_io: you meant to add to TOOLCHAIN_TARGET_TASK not HOST_TAK
Nov 07 16:20:48 <rburton> erm _HOST_TASK
Nov 07 16:21:21 <cengiz_io> rburton should it be in image or local.conf?
Nov 07 16:21:35 <cengiz_io> because result is still error with TARGET_TASK
Nov 07 16:21:58 <rburton> put it in image because thats where it makes sense
Nov 07 16:22:07 <rburton> and check that the packages you expect actaully exist
Nov 07 16:22:25 <rburton> nothing more embarassing than asking it to install packages you never generated
Nov 07 16:22:30 <cengiz_io> rburton there are directories in tmp/../../../mylib/packages
Nov 07 16:22:36 <lion_heart> Hello I have a beginner's question : https://pastebin.com/Q63WHT85
Nov 07 16:22:51 <rburton> cengiz_io: look in deploy, as thats where it would be fetching
Nov 07 16:23:23 <rburton> lion_heart: ask your supplier why they are using such an old BSP
Nov 07 16:23:58 <lion_heart> Well, lets say I'm not in a position to do that
Nov 07 16:25:00 <cengiz_io> bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/mylib/1.0+gitAUTOINC+98553092da-r0/deploy-ipks/armv7at2hf-neon/mylib-staticdev_1.0+git0+98553092da-r0_armv7at2hf-neon.ipk
Nov 07 16:25:13 <cengiz_io> this is in deploy-ipks
Nov 07 16:25:18 <rburton> cengiz_io: tmp/deploy/
Nov 07 16:25:40 <rburton> sure, same files eventually, but if you turned on rm_work those files wouldn't exist
Nov 07 16:25:58 <Crofton|work> During the OEDEM BSP discussion, I was worried the pitchforks would come out and people would storm BSP suppliers and commit mayhem
Nov 07 16:26:02 <cengiz_io> same files are in /bsp/build/tmp/deploy/ipk as well
Nov 07 16:26:32 <rburton> cengiz_io: and you have TOOLCHAIN_TARGET_TASK_append = " myapp-staticdev"
Nov 07 16:26:45 <cengiz_io> mylib-staticdev
Nov 07 16:27:25 <rburton> lion_heart: http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale is the current imx bsp layer
Nov 07 16:27:37 <cengiz_io> TOOLCHAIN_TARGET_TASK_append = " \
Nov 07 16:27:38 <cengiz_io>     mylib-dev \
Nov 07 16:27:38 <cengiz_io>     mylib-staticdev \
Nov 07 16:27:38 <cengiz_io> "
Nov 07 16:27:46 <rburton> lion_heart: lots of imx6 in there
Nov 07 16:28:15 <rburton> cengiz_io: i presume you checked the -dev package exists in deploy/ipkg/ too
Nov 07 16:28:25 <cengiz_io> hmm
Nov 07 16:29:21 <cengiz_io> rburton deploy/ipkg has lots of different parent directories and the one with my machine name doesn't have them
Nov 07 16:29:31 <rburton> it will be the tune
Nov 07 16:29:39 <rburton> ls tmp/deploy/*/myapp*
Nov 07 16:29:50 <qschulz> lion_heart: sabresd is pretty well supported in upstream kernel and u-boot IIRC
Nov 07 16:30:07 <rburton> cengiz_io: machine-specific deploy dir is only for truly machine specific bits, the rest is tune-specific
Nov 07 16:31:14 <qschulz> lion_heart: it's even supported in meta-freescale: https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale
Nov 07 16:31:15 <cengiz_io> only licenses show up
Nov 07 16:31:23 <qschulz> try with that first before pulling your hair
Nov 07 16:31:33 <cengiz_io> under deploy/licenses/myapp and deploy/licenses/mylib
Nov 07 16:33:28 <lion_heart> Thanks!!
Nov 07 16:33:34 <cengiz_io> rburton tmp/deploy $ find . -name mylib*
Nov 07 16:33:34 <cengiz_io> ./ipk/armv7at2hf-neon/mylib-dev_1.0+git0+98553092da-r0_armv7at2hf-neon.ipk
Nov 07 16:33:34 <cengiz_io> ./ipk/armv7at2hf-neon/mylib-staticdev_1.0+git0+98553092da-r0_armv7at2hf-neon.ipk
Nov 07 16:33:34 <cengiz_io> ./ipk/armv7at2hf-neon/mylib-dbg_1.0+git0+98553092da-r0_armv7at2hf-neon.ipk
Nov 07 16:33:34 <cengiz_io> ./licenses/mylib
Nov 07 16:33:51 <rburton> sorry, left a * out
Nov 07 16:34:06 <rburton> so what is the error when you bitbake imagename -c populate_sdk?
Nov 07 16:34:10 <lion_heart> maybe I should have looked in the repo before making assumptions based on some website :> thanks again
Nov 07 16:34:36 <rburton> lion_heart: yeah if the hardware says "use this five year old BSP" assume its out of date and look yourself :)
Nov 07 16:35:24 <qschulz> lion_heart: no worries :)
Nov 07 16:37:15 <qschulz> anyone's seen a handful of "FAILED: gir/cairo-1.0.typelib" (with a few different gir/*.typelib) in warrior for gobject-introspection on rpi3 machine by any chance?
Nov 07 16:39:14 <rburton> g-i on target?
Nov 07 16:39:29 <qschulz> http://code.bulix.org/qm4rf1-943333
Nov 07 16:39:40 <qschulz> rburton: /me shrugs
Nov 07 16:40:10 <rburton> you'd have to run the qemu-user yourself to see why it fails
Nov 07 16:40:24 <rburton> might be the qemu-user dying with invalid opcode or something
Nov 07 16:40:56 <qschulz> executing run.do_compile should be enough or am I completely going the wrong way?
Nov 07 16:41:23 <qschulz> (no idea what's gobject-introspection, and no experience with qemu, assume complete noobie :) )
Nov 07 16:43:50 <qschulz> rburton: cleansstate on the recipe apparently worked. I don't like this :/
Nov 07 16:44:52 <cengiz_io> rburton please check this gist for the error result of populate_sdk https://gist.github.com/cengizIO/7ff3ea865bd3148b228092e9c1a1b4cc
Nov 07 16:46:44 <cengiz_io> rburton please note that my image does NOT include `mylib` or `mylib-dev` or `mylib-staticdev` in IMAGE_INSTALL
Nov 07 16:46:52 <cengiz_io> only `myapp`
Nov 07 16:48:43 <rburton> oh right
Nov 07 16:49:01 <rburton> actually read the error
Nov 07 16:49:02 <rburton>  *   - nothing provides mylib = 1.0+git0+98553092da-r0 needed by mylib-dev-1.0+git0+98553092da-r0.armv7at2hf-neon
Nov 07 16:49:25 <rburton> there's a default dependency of RDEPENDS_${PN}-dev = PN
Nov 07 16:49:32 <rburton> so that installing eg zlib-dev installs zlib
Nov 07 16:49:37 <rburton> *but* you don't have a PN
Nov 07 16:49:46 <rburton> so set RDPENDS_${PN}-dev = "" in the recipe
Nov 07 16:50:00 <rburton> (fix the spelling obviously)
Nov 07 16:53:35 <rburton> maybe we need a qa test for that
Nov 07 16:53:48 * cengiz_io tries to grasp what's going on
Nov 07 16:54:10 <cengiz_io> so mylib-dev has a default runtime dependency of mylib
Nov 07 16:58:37 <cengiz_io> rburton seems to be populating the sdk now. thanks a ton! how can I take a look at qa tests so I may submit one for that?
Nov 07 16:58:49 <cengiz_io> are they in poky tree?
Nov 07 16:58:54 <rburton> insane.bbclass is the pile of qa tests
Nov 07 16:59:00 <cengiz_io> ok
Nov 07 16:59:13 <rburton> when opkg goes bang, it does explain clearly what happened
Nov 07 16:59:19 <rburton> so read the message carefully
Nov 07 17:00:03 <cengiz_io> I tried to make sense of it :)
Nov 07 17:00:18 <cengiz_io> I did contribute some error messages to rust compiler before.
Nov 07 17:01:13 <cengiz_io> but this one completely baffled me. "do not ask to install a package providing mylib-dev" :D
Nov 07 17:10:35 <rburton> right, the bit above spelt out what was happening
Nov 07 17:13:08 <yocti> New news from stackoverflow: Yocto recipes not found <https://stackoverflow.com/questions/57233257/yocto-recipes-not-found>
Nov 07 17:17:18 <cengiz_io> rburton it comes from opkg right? I will check there
Nov 07 17:17:32 <rburton> yes that error comes from opg
Nov 07 17:17:46 <rburton> a qa test would be in insane.bbclass to verify that a recipe doesn't have dependencies on itself that don't exist
Nov 07 17:21:15 <cengiz_io> rburton can we just assume that? maybe user actually forgot to include recipe
Nov 07 17:22:30 <cengiz_io> we can perhaps provide two solutions. 1) either remove rdepends on $PN-dev 2) include recipe in your image
Nov 07 17:22:54 <rburton> cengiz_io: *on itself*
Nov 07 17:23:07 <rburton> yes, foo depending on bar wouldn't be detected as bar might not be built yet
Nov 07 17:23:24 <rburton> but foo-dev depending on foo when foo doesn't exist is easy
Nov 07 17:23:40 <rburton> well, maybe actually not easy, but maybe possible :)
Nov 07 17:23:57 <cengiz_io> problem is I rename all my recipes and packages while sending to you to make them less public, so I confuse them
Nov 07 17:24:00 <rburton> should be easy enough to warn if a dependency is in PACKAGES but not actually built
Nov 07 17:40:26 <alessioigor> Is there a way to customize (IMAGE_FSTYPE=)tar generation?
Nov 07 17:43:14 <yocti> New news from stackoverflow: Is there a way to check the exact list of packages that will be installed in the image in Yocto? <https://stackoverflow.com/questions/46878640/is-there-a-way-to-check-the-exact-list-of-packages-that-will-be-installed-in-the>
Nov 07 17:48:19 <rburton> alessioigor: define customise?  the tar generation is just a tar of the rootfs...
Nov 07 17:49:05 <alessioigor> rburton: Can I define a IMAGE_CMD_mytar?
Nov 07 17:49:48 <rburton> alessioigor: yes
Nov 07 17:50:04 <kergoth> you can add whatever image types you want, sure, but if you're just tweaking the tar arguments, you could adjust the existing one
Nov 07 17:50:06 * kergoth yawns
Nov 07 17:51:32 <alessioigor> rburton, kergoth: Thanks!
Nov 07 17:59:30 <joubertb> anyone have any experience with getting a receipt to compile something with clang?
Nov 07 18:00:14 <joubertb> *recipe
Nov 07 19:29:35 <letothe2nd> joubertb: https://github.com/kraj/meta-clang
Nov 07 19:30:39 <letothe2nd> joubertb: something like TOOLCHAIN = "clang" in the desired recipe then should do the trick, read the readme of that layer
Nov 07 19:32:44 <kayterina> can I do anything from u-boot to debug why it is stuck at 'Starting kernel'? is it possible a wrong tty output,meaning the kernel starts but I don't see the output?
Nov 07 19:33:47 <joubertb> letothe2nd, thx.  Yea, been looking at that.  I am trying to pass the compiler location to make (e.g. make CLANG=${CLANGCC}), but CLANGCC is not set.  So, feel I am missing something
Nov 07 19:35:47 <letothe2nd> joubertb: huh?
Nov 07 19:36:22 <letothe2nd> joubertb: that sounds like your makefile has a hard dependency on clang instead of using the canonical environment?
Nov 07 19:37:02 <letothe2nd> (read that as: its carefully hand-broken... erm... hand-"crafted" instead of using a cross compile aware build system?)
Nov 07 19:37:51 <joubertb> letothe2nd: In the do_compile(), I have "make CLANG=$(CLANGCC}".  So, yes, has hard depndency on clang.
Nov 07 19:38:43 <letothe2nd> joubertb: well then dig meta-clang where it does the switch and therefore which variables it offers.
Nov 07 19:38:45 <joubertb> letothe2nd: actually, I am using clang to produce bdf code.
Nov 07 19:43:04 <d_thomas> kayterina, I was stuck on the "Starting kernel" problem a few weeks. Do you see anything if you enable more logging in the kernel?  Kernel hacking -> [*] Kernel low-level debugging functions -> (Select output based on device)Kernel hacking -> [*] Early printk
Nov 07 19:43:19 <d_thomas> those are the settings I changed
Nov 07 19:44:14 <d_thomas> Question:  What in the yocto project builds the FIT image (*.itb file)?  I have one in my deploy directory, but it's older and not from the kernel builds I just performed.
Nov 07 19:44:49 <RP> seebs: that patch seems fine in testing. Should I just hold it in OE for now as a patch or... ?
Nov 07 19:46:20 <letothe2nd> d_thomas: generally, look at meta/class/kernel-fit.bbclass
Nov 07 19:47:32 <seebs> hmm. hold it in OE but send it to me and I'll try to get it merged when I have some time?
Nov 07 19:49:08 <d_thomas> letothe2nd.  I added "inherit kernel-fitimage" to my bbappend file.  I also verified the device tree is built.  Maybe I'm missing another setting
Nov 07 19:49:37 <letothe2nd> d_thomas: hehe, i have no experience on that thing actually, i just know it *should* do the trick.
Nov 07 19:51:13 <d_thomas> :]  fair enough.  I suppose worst case I could right something to just run the command I need.  I just see an *.itb file in my deploy directory from this morning and I have no idea how it got there.
Nov 07 20:01:21 <RP> seebs: fair enough, thanks!
Nov 07 23:34:12 <kergoth> RP: any objection to adding a tox.ini to bitbake to run bitbake-selftest against all supported python versions? I was thinking the other day we have our minimum python version requirement and all, but i was wondering what would happen if someone checked in a random bit of code that used a feature added in 3.6 or something.. would that be caught with our current tests? do we run everything under python 3.4, since that's the oldest we support at the moment?
Nov 07 23:36:19 <kergoth> related: https://github.com/netromdk/vermin , but it uses ast analysis
**** ENDING LOGGING AT Fri Nov 08 02:59:57 2019