**** BEGIN LOGGING AT Mon Oct 17 02:59:58 2016
Oct 17 06:54:18 <kalyan_> can i know the processes for changing rootfs in yocto
Oct 17 07:56:57 <anatoli> Where can I get a description of the images that I build?
Oct 17 08:24:34 <yann|work> how do I specify a strict versionned dependency on a given package from the same recipe ?  With (= ${PV}) I get unsubstituted AUTOINC strings in the dep string ...
Oct 17 08:51:35 <jku> anatoli: not sure what you mean by description but tmp/deploy/images/<MACHINE>/<IMAGE>.manifest and tmp/deploy licenses/<IMAGE>/* might be relevant to you?
Oct 17 08:56:42 <anatoli> jku: sry, I mean the available images: core-image-minimal, core-image-base... I want to know what they are
Oct 17 09:03:23 <jku> anatoli: take a look at the recipes, e.g. for core-image-base: meta/recipes-core/images/core-image-base.bb and following from there meta/classes/core-image.bbclass
Oct 17 09:30:54 <kalyan_> can i know the processes for changing rootfs in yocto
Oct 17 09:31:29 <kalyan_> adding my own rootfs
Oct 17 09:52:20 <yann|work> kalyan_: that's image*.bb
Oct 17 09:53:11 <yann|work> what do you mean by your own rootfs ?
Oct 17 09:54:19 <kalyan_> i have ubuntu rootfs ,i want to include this rootfs in yocto layers
Oct 17 09:54:33 <kalyan_> and build yocto
Oct 17 10:00:46 <kalyan_> yann|work: i want to add ubuntu rootfs while building yocto
Oct 17 10:03:52 <yann|work> you mean you want include an external rootfs as part of your image, right ?   you're using image-live, right ?  what to do depends on whether you want to be able to boot it from your live media, and/or if it's for installing to target drive from your live media
Oct 17 10:05:00 <yann|work> and it's different again if you're building a directly-flashable image
Oct 17 10:06:30 <kalyan_> yes i want to include external rootfs as part of image.
Oct 17 10:28:37 <kalyan_> yann|work: any suggestions
Oct 17 10:29:11 <yann|work> you want to boot it from the live media ?
Oct 17 10:29:23 <kalyan_> yes
Oct 17 10:52:12 <yann|work> kalyan_: I guess you'll have to create your own image class, inheriting meta/classes/image-live.bbclass
Oct 17 10:52:41 <yann|work> and override build_iso or build_bootimg
Oct 17 10:52:55 <yann|work> er, do_bootimg
Oct 17 10:53:21 <yann|work> most probably build_iso anyway
Oct 17 12:01:02 <rajm> With the latest meta-raspberrypi I'm getting an error http://paste.baserock.org/ralezilezu on do_image_rpi_sdimg - I updated to try to solve the taskhash mismatch noises!
Oct 17 12:34:31 <eduardas_m> Greetings. I have successfully enabled systemd on my board with Yocto Jethro. systemd and resolvd services are not present however... what is the proper way to enabled those in bitbake recipies?
Oct 17 12:34:57 <eduardas_m> I mean networkd and resolvd
Oct 17 12:35:03 <eduardas_m> sorry, mistyped
Oct 17 12:39:38 <LetoThe2nd> eduardas_m: both should be supplied as packageconfigs of systemd
Oct 17 12:41:08 <LetoThe2nd> eduardas_m: see http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-PACKAGECONFIG
Oct 17 12:41:16 <eduardas_m> LetoThe2nd, so a bbappend with PACKAGECONFIG += " networkd resolvd" should be enough?
Oct 17 12:41:30 <LetoThe2nd> eduardas_m: the last section on "configuration file" explains how to set that up for your use case.
Oct 17 12:42:38 <Ulfalizer> eduardas_m: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-OVERRIDES covers how the _pn-recipename stuff works. i expanded it recently.
Oct 17 12:43:17 <Ulfalizer> can seem a bit more mysterious than it really is
Oct 17 12:44:55 <eduardas_m> thank you, will read through it and see how it goes
Oct 17 12:48:53 <Ulfalizer> if you just need to configure a recipe (set some variables, e.g. PACKAGECONFIG), it's often cleaner to do it in the global configuration (.conf files) than to do it in .bbappend files
Oct 17 12:49:10 <Ulfalizer> .bbappend files are more for tweaking the recipe logic itself
Oct 17 12:49:33 <Ulfalizer> though people don't always do stuff consistently
Oct 17 13:02:37 <otavio> halstead: Did you see the email about the new Git?
Oct 17 13:06:33 <maho> Hi, when I configure a driver in a kernel as a module, does yocto automatically install this module? If not, where do I need to do that?
Oct 17 13:10:10 <eduardas_m> maho, the way I do it
Oct 17 13:10:16 <eduardas_m> bitbake virtual/kernel -c menuconfig
Oct 17 13:10:29 <eduardas_m> bitbake virtual/kernel -c compile -f
Oct 17 13:10:37 <eduardas_m> and them bitbake image
Oct 17 13:10:56 <eduardas_m> will get a tainted message however
Oct 17 13:11:38 <eduardas_m> but I still get a proper usable image with the new configured modules
Oct 17 13:12:10 <Ulfalizer> http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-taskrunning explains what the "tainted" warning is about, and what can be done about it
Oct 17 13:12:11 <eduardas_m> if anyone knows a more proper way to do this, it would be good to know
Oct 17 13:12:13 <Ulfalizer> also new docs :)
Oct 17 13:12:45 * Ulfalizer hasn't done much kernel configuration stuff in yocto
Oct 17 13:14:20 <Ulfalizer> you'd need to make the configuration persistent though. the configuration saved by menuconfig will go away if the work directory (tmp) is removed.
Oct 17 13:14:53 <LetoThe2nd> the kernel workflow should be nicely documented anyways.
Oct 17 13:16:29 <maho> I have some kernel with a valid defconfig. I habe bbappended some patches including a driver and a .cfg that enables it as module but when booting the image there is no module present
Oct 17 13:17:11 <maho> I don't see anything obvious missing
Oct 17 13:17:35 <Ulfalizer> look into how modules are packaged, and make sure that the package containing the module is installed
Oct 17 13:19:17 <maho> But I don't package a module, I just configure some kernel driver as module - or do I need to create such a recipe which simply module_installs?
Oct 17 13:22:43 <Ulfalizer> maybe http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#viewing-package-information-with-oe-pkgdata-util could be helpful to figure out how packaging is handled for the modules
Oct 17 13:22:48 <Ulfalizer> i don't know off the top of my head
Oct 17 13:23:10 <Ulfalizer> i imagine they end up in some package at least, whether it's a kernel-related package or a dedicated per-module one
Oct 17 13:24:08 <Ulfalizer> if you know the name of the .ko file, you could search for it in tmp/. that'll tell you which package it's in.
Oct 17 13:34:15 <yann|work> the "libpseudo.so: undefined symbol: mknod" issue is not supposed to happen with krogoth, right ?
Oct 17 13:37:43 <Ulfalizer> maho: there's a kernel-module-split.bbclass. that one probably creates separate packages for the modules.
Oct 17 13:38:06 <Ulfalizer> check what packages are generated by the kernel recipe. you might see separate ones for the modules.
Oct 17 13:39:48 <Ulfalizer> packages for kernel modules include package scripts for autostarting, etc., so you shouldn't have to worry about that
Oct 17 13:40:18 <maho> Ulfalizer: thanks for your time, I will have a look
Oct 17 13:40:38 <Ulfalizer> np, and consider filing documentation bugs if stuff is unclear
Oct 17 13:42:55 <LetoThe2nd> Ulfalizer: just misread that as "consider fulling stuff". while some metal tune plays here, mentioning booze. a freudian one, i guess.
Oct 17 13:43:03 <LetoThe2nd> s/fulling/filling/
Oct 17 13:43:43 <Ulfalizer> consider filling stuff if you get too frustrated, i guess :P
Oct 17 13:43:51 <LetoThe2nd> Ulfalizer: ++
Oct 17 14:04:53 <awaisb> hi guys
Oct 17 14:05:14 <awaisb> is morty in code freeze state or is feature development still going on?
Oct 17 14:13:08 <yann|work> how do I specify a strict versionned dependency on a given package from the same recipe ?  With (= ${PV}) I get unsubstituted AUTOINC strings in the dep string ...
Oct 17 14:25:18 <LetoThe2nd> awaisb: AFAIK there is no feature development or version bumping anymore, and it should be released soon.
Oct 17 14:29:28 <awaisb> LetoThe2nd: thanks :)
Oct 17 14:34:53 <Ulfalizer> yann|work: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-EXTENDPKGV
Oct 17 14:36:59 <yann|work> Ulfalizer: thx - shouldn'tit be mentionned in the description of dependencies ?  Even in the megamanual it only appears in the vars index and in an example
Oct 17 14:38:07 <Ulfalizer> yann|work: the manual is a bit light on cross-references in general. feel free to submit a doc bug at https://bugzilla.yoctoproject.org/enter_bug.cgi?classification=Documentation
Oct 17 14:38:14 <Ulfalizer> i'm looking at some other doc stuff at the moment
Oct 17 14:38:27 <yann|work> ok
Oct 17 15:03:00 <lpapp> hello, I am getting an error stdint.h when trying to use the Yocto SDK to build the linux-gpib project. This shows the printenv output as well as the compilation error: https://paste.kde.org/p70fx1poa/wcfxzd/raw Do you know how to fix this?
Oct 17 15:04:37 <seebs> Not given that information. None of the printenv stuff is relevant; the question is what's in your sysroot, and in particular, why the standard headers aren't.
Oct 17 15:04:40 <edge0701> Hello all (:
Oct 17 15:16:33 <edge0701> I have an issue building an x11 based image for imx6 arm architecture. I get GL/gl.h no such file or directory. In my /usr/include I have GLES/gl.h. I presume maybe because this architecture doesn't support OpenGL, only GLES?? Anyone experienced this issue that could help, I'd greatly appreciate it.
Oct 17 15:17:49 <kergoth> Has anyone looked into encoding knowledge of which recipes are subject to export controls/compliance issues, other than the obvious (openssl) into the recipe metadata?
Oct 17 15:19:58 <lpapp> seebs: hmm?
Oct 17 15:20:22 <lpapp> seebs: I thought stdint.h was there. Which location do you mean?
Oct 17 15:21:52 <seebs> it's obviously not there, because the compiler didn't find it. look in the sysroot.
Oct 17 15:22:42 <seebs> include_next is presumably trying to find a target-specific thing. Compare it with the layout of a working system, see what's different.
Oct 17 15:29:26 <lpapp> seebs: I do not have a working system outside Yocto
Oct 17 15:29:57 <seebs> Garden variety qemux86 works. It presumably has working <stdint.h>.
Oct 17 15:50:46 <Ulfalizer> 'bitbake-layers show-recipes' doesn't show PR. do you think that's an oversight?
Oct 17 15:50:54 <Ulfalizer> https://dpaste.de/qfOY fixes it
Oct 17 15:59:27 <Ulfalizer> i'll submit a patch for it later
Oct 17 16:07:10 <halstead> otavio, No. I don't think so can you point me at it?
Oct 17 16:18:15 * zeddii tries to reset to a normal work week.
Oct 17 16:19:44 * moto-timo wonders what normal means
Oct 17 16:20:15 <zeddii> in the office for 5 days :D
Oct 17 16:20:53 <Ulfalizer> sleep schedules are for conformists
Oct 17 16:21:29 * zeddii has been on planes for 4 weeks straight now. I have no idea what normal sleep is :D
Oct 17 16:24:33 <moto-timo> if you ever find out, let me know. I think it's a myth.
Oct 17 19:26:02 <kratsg> Hiya, I am trying to cross-compile ROOT (from CERN), but I'm running into an error associated with the addition of the '-m64' flag.
Oct 17 19:28:00 <kratsg> This is the CMake error message I'm seeing: https://gist.github.com/anonymous/d5d766badcee1df5efc1#file-cmakeerror-log-L87-L97
Oct 17 19:28:14 <kratsg> So it's not recognizing the -m64 flag which I think is for the architecture (64-bit)
Oct 17 19:28:27 <kratsg> And this is the recipe: https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/root/root_6.04.12.bb
Oct 17 19:42:16 <bluelightning> kratsg: the question is where is that -m64 getting added?
Oct 17 19:42:48 <bluelightning> kratsg: -m64 wouldn't be valid for armv7-a so that's probably why it doesn't like it
Oct 17 19:53:44 <otavio> halstead: RP has sent the Ack by email
Oct 17 19:53:55 <otavio> halstead: want me to fw it again?
Oct 17 19:54:11 <kratsg> bluelightning: that's a good point. I don't know where it's being added.
Oct 17 19:54:32 <halstead> otavio, I think I see it. Is this about a new repo name.
Oct 17 19:54:48 <otavio> halstead: new repo creation
Oct 17 19:54:48 <kratsg> The recipe itself seems clean and straightforward (inheriting from cmake and pkgconfig).
Oct 17 19:54:54 <otavio> halstead: meta-freescale
Oct 17 19:55:07 <halstead> otavio, Thank you I'll have it ready in a moment.
Oct 17 19:55:28 <otavio> halstead: Thank you; sorry by pestering you
Oct 17 19:55:34 <halstead> otavio, No problem.
Oct 17 19:56:08 <bluelightning> kratsg: is "-m64" present anywhere in the root source tree?
Oct 17 19:56:43 <halstead> otavio, Shall the description read, "Layer containing Freescale hardware support metadata"?
Oct 17 19:56:57 <kratsg> bluelightning: i think it's here: https://github.com/root-mirror/root/blob/11378ff72814b0443d017329cd53adeb320c1509/config/Makefile.linuxx8664gcc
Oct 17 19:57:08 <otavio> halstead: in fact it is NXP; and yes I know it is confusing
Oct 17 19:57:31 <otavio> NXP hardware support metadata
Oct 17 19:57:48 <halstead> otavio, Got it.
Oct 17 19:59:08 <halstead> otavio, Does it need any collaborators other than you?
Oct 17 19:59:27 <bluelightning> kratsg: ok so you'll either need to patch it out or set CFLAGS / CXXFLAGS on the make command-line to override the value set there
Oct 17 19:59:29 <otavio> halstead: later yes, but not for now
Oct 17 20:00:17 <kratsg> bluelightning: I think the patch way may make more sense. I'm still very new to bitbake features, so I don't quite know how to create a correct patch.
Oct 17 20:00:37 <bluelightning> kratsg: which version of the build system are you using?
Oct 17 20:00:50 <kratsg> bluelightning: I'm using jethro right now.
Oct 17 20:03:00 <bluelightning> kratsg: you should be able to use this to patch the source fairly easily: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe
Oct 17 20:03:31 <halstead> otavio, All set. E-mail incoming. I can list it after the first push.
Oct 17 20:04:35 <otavio> halstead: thx!
Oct 17 20:05:50 <kratsg> bluelightning: so I would run "devtool modify root path/to/local`, go in there, make the modifications to remove -m64 flags, commit those, and then run `devtool update-recipe root` and that would make appropriate patch files?
Oct 17 20:06:14 <bluelightning> kratsg: yes
Oct 17 20:06:32 <bluelightning> kratsg: you can do a build before you do the devtool update-recipe just to check if the changes are OK
Oct 17 20:06:48 <kratsg> How do I run a build to check if changes are ok?
Oct 17 20:06:57 <kratsg> `bitbake root` wouldn't point to the local changes?
Oct 17 20:09:44 <bluelightning> yes, when you do "devtool modify" that ensures that the directory you specify will be used for building the recipe rather than bitbake unpacking the source as it normally does
Oct 17 20:10:21 <kratsg> Oh, interesting. But that's purely for development work? Cool.
Oct 17 20:10:25 <kratsg> I've run `devtool modify -x root ~/localROOT` right now.
Oct 17 20:10:43 <armpit> otavio, will the name change affect the layer index? does it need to be cleanup
Oct 17 20:11:14 <otavio> armpit: meta-freescale will support master and morty only
Oct 17 20:11:37 <armpit> otavio, k
Oct 17 20:11:41 <bluelightning> layers are pretty easily renamed in the layer index, but you'll have to create a separate entry if you want the old and new names to persist with different supported branches
Oct 17 20:12:03 <otavio> halstead: done
Oct 17 20:12:04 <armpit> otavio, also the patchwork has meta-fsl
Oct 17 20:12:04 <bluelightning> oh and editing layers is probably broken atm
Oct 17 20:12:20 <otavio> bluelightning: yes; once it is announced we will add it
Oct 17 20:12:33 <otavio> armpit: it has all; all use same mailing list
Oct 17 20:12:34 <bluelightning> halstead: we should probably look into that when you get some time
Oct 17 20:13:18 <halstead> otavio, Published. http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/about/
Oct 17 20:13:25 <kratsg> bluelightning: I'm wondering now, because it's currently at the "NOTE: Patching..." message and it seems to have been hanging(?).
Oct 17 20:13:43 <bluelightning> kratsg: it may take some time, it's not the most optimal process
Oct 17 20:14:07 <kratsg> I'm surprised there's actually patching. Since this is a recipe I wrote with no patches anywhere else...
Oct 17 20:14:14 <kratsg> [unless I'm missing the meaning]
Oct 17 20:14:30 <halstead> bluelightning, Would getting the 1.8 branch up on a preview site be a good first step?
Oct 17 20:14:31 <bluelightning> kratsg: yes, that is odd...
Oct 17 20:14:52 <bluelightning> halstead: well we do need to do that but I'd like to know why the editing doesn't work
Oct 17 20:15:01 <bluelightning> halstead: I can't reproduce the editing issue locally
Oct 17 20:16:19 <halstead> bluelightning, okay fix editing first then look at 1.8. I'm working on patchwork a litle longer then I can do that.
Oct 17 20:16:21 <kratsg> ok, it just finished.
Oct 17 20:17:34 <kratsg> I'm a little confused, should I remove -m64 from EVERYTHING?
Oct 17 20:17:42 <kratsg> or just linux and see how that changes?
Oct 17 20:17:50 <kratsg> https://github.com/root-mirror/root/search?utf8=%E2%9C%93&q=m64
Oct 17 20:21:45 <kratsg> Ok, so I can't seem to make this work at all. I ran the above devtool modify command. And without making any changes, I wanted to see if bitbake would build and get the same error.
Oct 17 20:22:12 <kratsg> However, it complains that it can't find CMakeLists.txt https://gist.github.com/kratsg/3c48db6cf0a1c221e3a66f0c7763b7de
Oct 17 20:22:22 <kratsg> and looking at the directory, it's empty! (which is weird, I think)
Oct 17 20:25:12 <kratsg> I think I screwed things up somehow. I then try running `devtool build root` and it has the same error, pointing to a different path to look in.
Oct 17 20:26:05 <kratsg> Ok, there's good news. Removing `do_configure(){ cmake .}` from the root recipe fixes that path error.
Oct 17 20:27:14 <bluelightning> right that shouldn't be necessary
Oct 17 20:27:51 <kratsg> Yeah, I'm just a moron. So re-running gives me a different.. error than I've seen before: "| CMake Error at interpreter/llvm/src/cmake/modules/HandleLLVMOptions.cmake:350 (message): |   LLVM requires C++11 support but the '-std=c++11' flag isn't supported."
Oct 17 20:32:09 <bluelightning> kratsg: that sounds like maybe llvm is expecting a newer gcc than is in jethro
Oct 17 20:32:44 <kratsg> Hrmm, so maybe I should just bump up to a later stable release first then.
Oct 17 20:32:55 <kratsg> I'm guessing jethro is super old by now. >.<
Oct 17 20:33:58 <kratsg> I mean, I'm using pkg-config -- and I have `DEPENDS += "llvm3.3 libx11 libxpm libxft python-core"` in my recipe.
Oct 17 20:34:44 <behanw> kratsg: Jethro is ancient now.
Oct 17 20:35:03 <behanw> LLVM project is now working on a 4.0 release (latest is 3.9)
Oct 17 20:35:16 <kratsg> behanw: yay :( I like things that don't change too much. which is why I use OSX10.9!
Oct 17 20:35:23 <behanw> kratsg: 3.3 had minimal C+11 support
Oct 17 20:35:37 <kratsg> good point.
Oct 17 20:35:43 <behanw> kratsg: Get used to dissappointment
Oct 17 20:35:55 <behanw> Development tools change *FAST*
Oct 17 20:36:05 <behanw> IF you want stable tools, you have to use older C standards.
Oct 17 20:36:14 <behanw> C+11 is still very new.
Oct 17 20:36:26 <behanw> Most compilers still implement only a fraction of it.
Oct 17 20:36:30 <kratsg> behanw: Yep. ROOT uses it now. I could switch over to ROOT5. but nobody likes it.
Oct 17 20:36:40 <behanw> A lot of things use it.
Oct 17 20:37:09 <kratsg> so switch over to krogoth?
Oct 17 20:37:12 <behanw> But while people only test on gcc, there will still be issues without people porting code to clang.
Oct 17 20:37:22 <behanw> kratsg: Not guaranteed to fix the problem.
Oct 17 20:37:26 <behanw> But might help.
Oct 17 20:37:37 <behanw> I'd suggest always using the latest release regardless.
Oct 17 20:38:29 <behanw> Considering krogoth is about to be replaced with morty.
Oct 17 20:39:26 <kratsg> so... morty then?
Oct 17 20:39:38 <kratsg> actually, I can't use morty.
Oct 17 20:39:44 <behanw> If you want to use the pre-release.
Oct 17 20:39:46 <kratsg> krogoth only exists on all of my layers.
Oct 17 20:39:51 <neverpanic> FWIW, that's also my experience with C++11. Use modern tools, or you're going to have a headache sooner or later.
Oct 17 20:39:53 <kratsg> https://github.com/xilinx/meta-xilinx -- this is the main one I need for the machines.
Oct 17 20:39:57 <behanw> Because morty isn't released yet
Oct 17 20:40:17 <kratsg> ok, let me try switching to morty.
Oct 17 20:40:29 <behanw> kratsg: Probably using krogoth is your best bet
Oct 17 20:40:32 <kratsg> err, krogoth*
Oct 17 20:40:33 <kratsg> gah.
Oct 17 20:40:41 <behanw> If you're using meta-xilinx
Oct 17 20:40:48 <behanw> Good luck.
Oct 17 20:41:11 <kratsg> while I have you, a silly question, since I can't find good documentation with bitbake recipes.
Oct 17 20:41:17 <behanw> neverpanic: I always know where my towel is...
Oct 17 20:41:23 <kratsg> https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/root/root_6.04.12.bb#L18-L24
Oct 17 20:41:39 <kratsg> Is there a way to split up these into options through the recipe rather than hard-coding?
Oct 17 20:41:58 <kratsg> I know there's a way to get a recipe split into packages like ${PN}-core, and so on.
Oct 17 20:42:21 <behanw> Split it up how?
Oct 17 20:42:29 <behanw> You only configure once.
Oct 17 20:42:43 <behanw> Packages happen after the compile/install tasks.
Oct 17 20:42:56 <kratsg> Well, so the same recipe can be called like "root_Drootfit_Dminuit" instead?
Oct 17 20:43:20 <kratsg> ROOT has 100+ configuration options, and maybe someone wants root + one thing turned on / enabled on top of the default.
Oct 17 20:43:34 <behanw> Extend the recipe.
Oct 17 20:43:46 <kratsg> oh, i see.
Oct 17 20:43:49 <neverpanic> Easiest way is probably to use PACKAGECONFIG with some options, then write (or generate) a handred recipes that all include a central .inc file and just set PACKAGECONFIG
Oct 17 20:43:52 <behanw> Create a new recipe. require the old. Make changes to variables
Oct 17 20:44:14 <kratsg> i see, ok. that's what I was wondering. I thought there was a more clever way.
Oct 17 20:45:07 <behanw> If in a different layer you can use a .bbappend
Oct 17 20:45:22 <kratsg> I might go the way of an "inc" file
Oct 17 20:45:28 <kratsg> and then create a bajillion recipes that do something like
Oct 17 20:45:34 <behanw> Whatever works for you.
Oct 17 20:45:42 <kratsg> IMAGE += "root_rootfit root_minuit2" and so on.
Oct 17 20:45:58 <kratsg> which I hope would combine all the EXTRA_OECMAKE flags.
Oct 17 20:46:03 <neverpanic> That will probably not work, because those recipes will install the same files and conflict?
Oct 17 20:46:10 <behanw> combine?
Oct 17 20:46:27 <behanw> That would build the root package multiple times
Oct 17 20:46:30 <behanw> And conflict
Oct 17 20:46:32 <kratsg> Oh. sigh.
Oct 17 20:46:58 <kratsg> I just rather make it so they can just add a specific image with extra configurations. Rather than a custom root image hard-coded their way.
Oct 17 20:47:32 <behanw> You can always set variables in the image recipe for specific packages
Oct 17 20:47:43 <behanw> variable_pn-packagename = "foo"
Oct 17 20:47:52 <neverpanic> What you could do, iff all those combinations are binary compatible, is enable package management, build a package feed with multiple different versions of root that all RPROVIDE a single name and then use a package manager to switch between the packages
Oct 17 20:48:37 <behanw> neverpanic: If he just wants to change a single variable (EXTRA_OECMAKE) that is overkill
Oct 17 20:48:51 <kratsg> all the combinations are compatible. It's just a switch and ROOT takes care of it. It's only about the flags.
Oct 17 20:48:58 <behanw> Setting EXTRA_OECMAKE_pn-packagefoo in the image recipe will work.
Oct 17 20:49:26 <kratsg> EXTRA_OECMAKE_pn-root += "...." will work exactly as intended?
Oct 17 20:49:35 <behanw> Should do.
Oct 17 20:49:37 <kratsg> if so, that might be exactly what I want. It leaves it up to the user.
Oct 17 20:50:00 <behanw> There are many ways to do this.
Oct 17 20:50:25 <behanw> Some follow the intention of the build system more than others.
Oct 17 20:50:32 <kratsg> I really like the EXTRA_OOECMAKE flags way, because that doesn't try and hide anything from the user.
Oct 17 20:50:34 <behanw> Some solve the problem more easily than others.
Oct 17 20:50:43 <behanw> YMMV.
Oct 17 20:51:06 <kratsg> So on my end, I've updated meta-oe, meta-xilinx, and poky to `krogoth` and I am re-running `bitbake root` now.
Oct 17 20:51:14 <behanw> good luck.
Oct 17 20:53:34 <kratsg> thanks! :beer:
Oct 17 21:21:07 <CTtpollard> is it possible to leave the license field blank in a recipe?
Oct 17 21:21:22 <fray> no, you must fill out something
Oct 17 21:23:55 <neverpanic> CTtpollard: for your own code, you should set LICENSE = "CLOSED"
Oct 17 21:25:12 <kergoth> git -c core.editor=/bin/true rebase -ix 'cd ../build && . ./setup-environment && bitbake-selftest -qf' || git show -s
Oct 17 21:25:13 <kergoth> :)
Oct 17 21:33:05 <CTtpollard> neverpanic: thanks!
Oct 17 21:36:31 <fray> why use -i if editor is /bin/true?
Oct 17 21:36:36 <fray> just don't use -i?
Oct 17 21:37:32 <kergoth> -i is mandatory when using -x for some reason
Oct 17 21:37:46 * kergoth shrugs
Oct 17 21:38:27 <fray> huh.. didn't know that
Oct 17 21:39:28 <seebs>            This option can only be used with the --interactive option (see
Oct 17 21:39:29 <seebs>            INTERACTIVE MODE below).
Oct 17 21:39:35 <seebs> Yeah, not obvious why, but there it is.
Oct 17 21:42:31 <fray> I've deifnitely always used them together, but didn't realize it was required.
Oct 17 21:45:06 <bluelightning> neverpanic: CTtpollard: assuming "your own code" is actually closed source rather than being under an open source licence
Oct 17 21:45:28 <neverpanic> Of course. Also, make your code open source!
Oct 17 21:45:33 <bluelightning> (or it is, but you're in the middle of development - if that's the case then don't forget to go back and fix it)
Oct 17 21:45:47 <bluelightning> neverpanic: if possible, yes :)
Oct 17 21:55:12 <CTtpollard> bluelightning: what about if the upstream source has no license file?
Oct 17 21:55:29 <fray> then you really need to figure out the license before you use the component..
Oct 17 21:55:38 <fray> you don't want to get caught violating a license in the future
Oct 17 21:56:14 <bluelightning> CTtpollard: poke upstream to fix that, in the first instance
Oct 17 21:56:16 <neverpanic> Yes, go clarify, or avoid using it.
Oct 17 21:56:19 <bluelightning> CTtpollard: https://wiki.yoctoproject.org/wiki/Technical_FAQ#I.27m_required_to_set_LIC_FILES_CHKSUM_but_the_software_I.27m_building_doesn.27t_have_a_license_statement.2C_what_do_I_do.3F
Oct 17 21:56:53 <bluelightning> (sometimes there's a licence stated somewhere, but not in a form that LIC_FILES_CHKSUM can point to, that's more what that FAQ was answering)
Oct 17 21:57:20 <bluelightning> I should really clarify that, I'll do that now
Oct 18 00:01:52 <soap_aus> Anyone about? I had a question about BBMASK and Fido. Specifically, it does not seem to be masking a directory in my layer, despite appearing in the BBMASK variable.
Oct 18 00:02:18 <soap_aus> e.g.: bitbake -e initscripts | grep "^BBMASK"
Oct 18 00:02:18 <soap_aus> BBMASK="meta-ti/recipes-kernel meta-sf200-extras/recipes-aq1/initscripts/" <— I want to mask out any bbappends under that initscripts directory. They are still included and not masked, however.
Oct 18 00:03:16 <soap_aus> More interesting: the meta-ti stuff seems like it might not be masked either. I reach this conclusion due to bitbake reporting “Parsing of 2354 .bb files complete (2350 cached, 4 parsed). 2893 targets, 361 skipped, 0 masked, 0 errors.”
Oct 18 00:03:20 <soap_aus> 0 masked…any ideas?
Oct 18 00:14:52 <CTtpollard> hmm bitbake -s $image is seemingly listing packages that aren't on my finished sysroot?
Oct 18 00:16:31 <soap_aus> My BBMASK problem: I had the wrong version of the reference manual up, syntax for the re was wrong, possibly no issue in Fido.
Oct 18 00:27:24 <bluelightning> CTtpollard: -s lists all available recipes
Oct 18 00:27:36 <bluelightning> so that would be expected
Oct 18 00:28:46 <CTtpollard> bluelightning: what's the best way to list all packages going into an image then? Before waiting for the rootfs manifest?
Oct 18 00:30:32 <bluelightning> CTtpollard: bitbake -g <image> will give you a list of the recipes that will need to be built, but that's more than will end up in the image
Oct 18 00:30:51 <CTtpollard> yeh, depends and natives etc too
Oct 18 00:31:02 <bluelightning> right
Oct 18 00:32:15 <bluelightning> when it gets down to the package level, ultimately there are things that bitbake simply doesn't know about - the only definitive source of information is the image manifest or what buildhistory produces (which is pretty much the same thing)
Oct 18 00:36:53 <khem> CTtpollard: bitbake -g can be explored for what you want
Oct 18 00:37:12 <khem> CTtpollard: before generating image
Oct 18 00:37:46 <khem> ideally using buildhistory method that bluelightning was mentioning is more robust and to the point
Oct 18 00:39:36 <CTtpollard> thanks, also is there a variable I can stick in local.conf to always remove the last built image? seems to ring a bell
Oct 18 00:40:05 <khem> CTtpollard: if you are using master or morty then its automatic
Oct 18 00:41:17 <khem> look into RM_OLD_IMAGE
Oct 18 00:41:22 <khem> for older releases
Oct 18 00:41:30 <CTtpollard> Krogoth
Oct 18 00:48:35 <soap_aus> BBMASK issue on Fido: after employing the correct syntax (separating regex tokens with a vertical bar), my masking is working.
Oct 18 00:53:59 <bluelightning> soap_aus: great - I do believe we changed it in the last release to allow multiple regexes
Oct 18 00:55:42 <soap_aus> Yep, as mentioned, I unfortunately had opened the wrong manual (it was a krogoth version). The reasoning seems very sound. I am currently doing a hack to specify a different mask depending on the image I want to build, but it works so I’m happy.
**** ENDING LOGGING AT Tue Oct 18 02:59:58 2016