**** BEGIN LOGGING AT Fri Dec 01 03:00:02 2017
Dec 01 06:26:00 <yocti> New news from stackoverflow: error adding java package in toaster <https://stackoverflow.com/questions/47587745/error-adding-java-package-in-toaster>
Dec 01 09:56:47 <lukma> Dear All,
Dec 01 09:57:22 <lukma> I'm wondering about the best place (I mean where) I shall put a set of commands which are adding customized stuff to rootfs
Dec 01 09:58:06 <lukma> The best would be to create links, copy some custom scripts, just after the rootfs is ready (and before creating tar)
Dec 01 09:59:34 <lukma> image.bbclass ?
Dec 01 09:59:34 <nayfe> lukma: use ROOTFS_POSTPROCESS_COMMAND to customize your image ?
Dec 01 10:02:28 <lukma> nayfe: Is it possible to use if for installing (copy) an script
Dec 01 10:03:37 <lukma> nayfe: I do have built rootfs and then I would like to "install" or just copy some legacy scripts and e.g. do some symbolic links
Dec 01 10:04:43 <nayfe> lukma sure you can
Dec 01 10:06:19 <nayfe> lukma: in image recipe you do something like
Dec 01 10:06:24 <nayfe> add_my_link() { ln -s ${IMAGE_ROOTFS}/etc/test1 ${IMAGE_ROOTFS}/etc/test2 }
Dec 01 10:06:24 <nayfe> ROOTFS_POSTPROCESS_COMMAND += "add_my_link ; "
Dec 01 10:07:34 <lukma> nayfe: Just one more question - shall I add ROOTFS_POSTPROCESS_COMMAND to recipes-core/images/my-image.bb ? or is there any better place?
Dec 01 10:07:34 <lukma> Or would you recommend creating new recipe -> like some_custom.stuff.bb and put there this
Dec 01 10:07:56 <lukma> the second option seems more appealing
Dec 01 10:10:35 <nayfe> lukma: you can add it to your local.conf but i suggest the second solution indeed, you should customize your current image recipe in your custom layer
Dec 01 10:11:54 <lukma> nayfe: having a separate recipe is better -> I can remove it in some day without cluttering other stuff.....
Dec 01 10:12:08 <lukma> but if it is the way to go -> I'm more than happy to use it
Dec 01 10:13:52 <nayfe> lukma: yes, copy it and make your own image recipe
Dec 01 10:19:13 <lukma> nayfe: ${IMAGE_ROOTFS}/etc/ == ${sysconf} ?
Dec 01 10:20:30 <nayfe> ${IMAGE_ROOTFS} is the path of your rootfs, i'm not sure at this moment you have access to ${sysconf}
Dec 01 10:23:48 <lukma> nayfe: Just last question
Dec 01 10:24:09 <lukma> I do have my-image-base.bb (it inherit core-image)
Dec 01 10:24:44 <lukma> and I would like to create in the same directory my-image-custom-adjustments.bb (with the ROOTFS_POSTPROCESS_COMMAND +=)
Dec 01 10:25:14 <lukma> how shall I "include" the package with adjustments into the my-image-base.bb ?
Dec 01 10:27:22 <nayfe> will you have 2 different images ?
Dec 01 10:28:09 <lukma> nayfe: I just want to have one -> my-image-base.bb
Dec 01 10:28:44 <lukma> and this shall "include" (require command?) the recipe to extend it with adjustments
Dec 01 10:28:57 <nayfe> you can create a custom_adjust.inc with function + postprocess then add    require custom_adjust.inc in base image
Dec 01 10:30:08 <lukma> great this is what I look for :)
Dec 01 10:32:01 <lukma> nayfe: Thanks for help
Dec 01 10:32:19 <Ramose_> Hi, how can one build OpenGL EL 2.0 for Imx platform ?
Dec 01 10:32:28 <nayfe> lukma: my plaisure
Dec 01 10:37:02 <nayfe> <Ramose_:  you mean openfg es 2.0 ?
Dec 01 10:37:06 <nayfe> opengl es 2.0
Dec 01 10:41:57 <nayfe> ramose_: i've in mind you have to remove x11 to distro feature, then maybe add virtual/libgles2
Dec 01 10:43:54 <Ramose_> nayfe: Yes, its opengl es 2.0
Dec 01 10:44:17 <Ramose_> x11 is already not present in distro-feature
Dec 01 10:45:31 <Ramose_> nayfe: virtual/libgles2 has to go to distro feature ?
Dec 01 10:50:34 <nayfe> Ramose_: nop, it's virtual package, but i'm not confident about what to do, i just have some old memories that you have to remove every backend (wayland, x11 ...) but after that, i don't remember maybe otavio?
Dec 01 10:50:54 <nayfe> Ramose_ which board do you use ?
Dec 01 10:51:02 <nayfe> yocto version ?
Dec 01 10:51:55 <Ramose_> nayfe: Its imx6 based nitrogen6x
Dec 01 10:53:27 <nayfe> if you type       bitbake -e | grep -i gles2               what do you have ?
Dec 01 10:53:45 <Ramose_> let me check
Dec 01 10:56:07 <Ramose_> its actually gives lots of stuff
Dec 01 11:00:04 <nayfe> Ramose_: libgles2 is virtual package, so there are some PREFERRED_PROVIDER_virtual/libgles2 with machine overrides
Dec 01 11:00:25 <nayfe> it should be imx-gpu-viv for nitrogen6x
Dec 01 11:00:51 <Ramose_> nayfe: I just did this, bitbake fsl-gpu-sdk
Dec 01 11:01:15 <Ramose_> it provided me few GELS2 examples
Dec 01 11:02:38 <nayfe> so what's the problem ?
Dec 01 11:03:12 <Ramose_> nayfe: Now, have to figure out how it can be run
Dec 01 11:03:31 <nayfe> brb in 1 hour, sorry
Dec 01 11:03:53 <Ramose_> ok, sure. No issues :)
Dec 01 11:03:58 <Ramose_> Thanks for helping.
Dec 01 12:14:17 <sveinse_> As a part of a build server post process tasks, I want to extract the logs from certain core recipes. What is the best approach to get the package PV (to get its path)? use bitbake -e recipe or parse one of the generated manifests?
Dec 01 12:15:38 <sveinse> bitbake -e isn't particularely fast
Dec 01 12:17:36 <LetoThe2nd> sounds more like maybe leveraging the buildinfo stuff
Dec 01 12:18:25 <Crofton|work> or buildhistory
Dec 01 12:18:36 <LetoThe2nd> Crofton|work: we all know, history software is bad.
Dec 01 12:18:45 <LetoThe2nd> s/history/historic/
Dec 01 12:18:47 <rburton> sveinse: as in the logs in workdir/recipe/version/temp?
Dec 01 12:19:51 <sveinse> rburton: Yes. However, sometimes the recipe exists in multiple version and I need to find which is the correct one.
Dec 01 12:19:59 <rburton> note that you'll want to get T to find out the path too
Dec 01 12:20:49 <rburton> just use -e to get T for the recipe and that will give you the full path.  yes, a second to let bitbake run but then you'll have the actual path.
Dec 01 12:21:20 <rburton> in the context of a build server that extra second for some recipes really isn't going to hurt
Dec 01 12:21:53 <rburton> of course another solution would be a class that runs after build and pushes the logs somewhere
Dec 01 12:22:00 <rburton> then it will already know T without havign to look it up
Dec 01 12:22:15 <sveinse> T is brilliant.
Dec 01 12:22:25 <sveinse> Hey, that's an idea!
Dec 01 12:22:31 <rburton> i should invoice for this
Dec 01 12:23:30 <sveinse> What if, instead of setting the build system up to look for certain logs, the recipes could push logs themselves.
Dec 01 12:23:56 <sveinse> hmm, the downside if you want logs from standard oe recipes
Dec 01 12:25:28 <LetoThe2nd> sveinse: thats why i said. buildinfo.
Dec 01 12:25:54 <LetoThe2nd> one could certainly make a brother of it, like, buildlogger or such. depending on your needs.
Dec 01 12:26:22 <sveinse> LetoThe2nd: Buildinfo. I need to google that.
Dec 01 12:27:13 <LetoThe2nd> https://github.com/openembedded/openembedded-core/tree/master/meta/classes
Dec 01 12:27:47 <LetoThe2nd> there are buildhistory, buildstats, and image-buildinfo already. so be inspired(TM)
Dec 01 12:28:34 <sveinse> LetoThe2nd: image-buildinfo writes to target file system, so its out of the question ot use that as is. But yes, as inspiration
Dec 01 12:29:51 <rburton> sveinse: global class inherit
Dec 01 12:30:25 <sveinse> Yocto and OE is like a big city. You discover new alleys every day. :D With intended reference to the Catherdral and the Bazaar
Dec 01 12:30:33 <rburton> hell INHERIT_append_pn-systemd = " logpusher" would work in a distro conf
Dec 01 12:30:53 <LetoThe2nd> rburton: ++
Dec 01 12:31:00 <LetoThe2nd> sveinse: we certainly need more bars.
Dec 01 12:31:07 <rburton> surely there's a service for pushing logs to for future analysis
Dec 01 12:32:14 <sveinse> LetoThe2nd: lol. What is the OE metaphor of a bar?
Dec 01 12:32:15 <joshuagl> I beleive it's quite common to push them somewhere like an elastic instance
Dec 01 12:32:18 <joshuagl> http://www.elastic.co/
Dec 01 12:34:32 <LetoThe2nd> sveinse: i don't want metaphors, but real bars :-)
Dec 01 12:36:43 <rburton> joshuagl: http://www.elastic.co/products/logstash sounds about right
Dec 01 12:37:19 <joshuagl> I'd like to do something with that for the AB
Dec 01 12:37:21 <joshuagl> one day…
Dec 01 12:37:26 <rburton> yeah
Dec 01 12:37:41 <rburton> errors.yp on steriods
Dec 01 12:51:05 <[1]muppe> Does anybody know if there is a proper support for Intel i219 Ethernet adapter in Yocto/Poky? I have a device with multiple i210s and one i219 port. The one with i219 throws "Reset adapter unexpectedly" and "Detected Hardware Unite Hang" after a while when cable is connected.
Dec 01 12:52:26 <LetoThe2nd> [1]muppe: i don't think this is realted to poky itself, but to the kernel in use
Dec 01 12:53:15 <[1]muppe> LetoThe2nd: I seem to be having 4.1.18-yocto-standard (printed with uname -a)
Dec 01 12:57:58 <LetoThe2nd> [1]muppe: um. 4.1 seems to be a bit unsuited for a chip that is very recent (which the one you nemed probably is, given a very quick google survey)
Dec 01 12:58:30 <LetoThe2nd> launched Q2'15
Dec 01 12:59:25 <LetoThe2nd> though, 4.1 is June '15
Dec 01 12:59:38 <LetoThe2nd> so that might actually have been a very close match.
Dec 01 12:59:50 <LetoThe2nd> i personally would just try a newer one for a first shot.
Dec 01 13:01:18 <[1]muppe> ok. I'll see if that works. I am afraid that upgrading kernel blows up some dependencies in some other layers I am using...
Dec 01 13:03:32 <LetoThe2nd> good luck
Dec 01 13:03:50 <[1]muppe> Thanks =:o
Dec 01 13:32:53 <MajorGrub> Hi all
Dec 01 13:33:28 <MajorGrub> I'd like to install a file from a .bbappend directory, but I can't find the proper env variables to find the path to the .bbappend
Dec 01 13:33:45 <MajorGrub> I have "FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:""
Dec 01 13:33:48 <MajorGrub> in my bbappend
Dec 01 13:34:03 <MajorGrub> So I thought using ${THISDIR}/${BPN}/myfile would work
Dec 01 13:34:50 <rburton> add myfile to SRC_URI
Dec 01 13:34:54 <rburton> then its in WORKDIR like everything else
Dec 01 13:35:56 <MajorGrub> So from workdir I can install it ?
Dec 01 13:35:57 <MajorGrub> Like
Dec 01 13:36:13 <MajorGrub> install -m 644 ${WORKDIR}/myfile ${D}${sysconfdir}
Dec 01 13:36:18 <rburton> yes, exactly like normal
Dec 01 13:36:25 <MajorGrub> Duh
Dec 01 13:36:27 <MajorGrub> Will try that
Dec 01 13:36:36 <rburton> the only tweak is the FILEEXTRAPATHS so it knows to look in the directory next to the bbappend
Dec 01 13:37:10 <MajorGrub> Why do I need to add it to the SRC_URI ??
Dec 01 13:37:41 <rburton> because thats what you do if you want to install a file
Dec 01 13:38:18 <MajorGrub> Lolz
Dec 01 13:39:26 <MajorGrub> Why can't I do  install -m 644 ${THISDIR}/${BPN}/myfile ${D}${sysconfdir} ?
Dec 01 13:39:35 <MajorGrub> Without the need for adding my file to SRC_URI ,
Dec 01 13:39:37 <MajorGrub> ?
Dec 01 13:39:43 <rburton> do you want the reason why that doesn't work, or why you should use SRC_URI?
Dec 01 13:39:50 <MajorGrub> Why it doesnt work
Dec 01 13:40:07 <rburton> becayse THISDIR is the location of the recipe at the time the variable gets expanded, not the bbappend
Dec 01 13:40:17 <MajorGrub> Ok understood
Dec 01 13:40:37 <rburton> you should use SRC_URI so the recipe knows that the file is part of the output and if the file changes, the recipe needs to be rebuilt
Dec 01 13:41:05 <rburton> also it gives you a way to have per-machine/distro/whatever files, ie you could have qemuarm/myfile qemuppc/myfile and bitbake will use the right file automatically
Dec 01 13:41:33 <rburton> but mainly the first one.  if you just copy it directly out of the layer then bitbake doesn't know that file dependency exists and changing the file won't make the recipe rebuild
Dec 01 13:42:37 <rburton> waiting for someone to say "bitbake can do that?!" for the arch-specific lookup.  yes, see xserver-xf86-config.
Dec 01 13:51:27 <dafna> yo
Dec 01 13:52:05 <dafna> I have this problem that it seems that yocto looks for header files in the /usr/include dir of my host's root
Dec 01 13:53:04 <dafna> I try to build a package that depends on libsoc
Dec 01 13:53:15 <dafna> I added DEPENDS="libsoc"
Dec 01 13:53:20 <dafna> to my bb file
Dec 01 13:53:54 <rburton> yocto doesn't look anywhere for headers.  your package's build system might be.
Dec 01 13:53:57 <dafna> and I see the libsoc_gpio.h file is in the sysroote under /usr/include
Dec 01 13:54:29 <dafna> my package have a makefile
Dec 01 13:55:25 <dafna> How do I fix it ?
Dec 01 13:55:27 <mjourdan> do you use $CC and all the other standard env ?
Dec 01 13:55:31 <mjourdan> in your makefile ?
Dec 01 13:55:35 <dafna> no
Dec 01 13:55:36 <rburton> dafna: share the makefile and we might be able to help
Dec 01 13:55:38 <dafna> I run gcc
Dec 01 13:55:44 <rburton> so theres bug one
Dec 01 13:55:52 <dafna> https://github.com/kamomil/mygpio/blob/master/Makefile
Dec 01 13:55:59 <dafna> that's the makefile
Dec 01 13:55:59 <rburton> use ${CC} ${CFLAGS} ${LDFLAGS} etc
Dec 01 13:56:18 <rburton> and line two is telling it *explicitly* to link against your build host
Dec 01 13:56:31 <rburton> line 7 is telling it *explicitly* to install on the build host so that wont work either
Dec 01 13:56:45 <dafna> this line: LIBS = -L/usr/lib64/ -lsoc
Dec 01 13:56:46 <dafna> ?
Dec 01 13:57:06 <rburton> line 1 is erasing the cflags we're trying to pass in
Dec 01 13:57:07 <dafna> the install line ?
Dec 01 13:57:17 <rburton> basically, unless you know what you're doing, don't use a bare makefile
Dec 01 13:57:18 <yocti> New news from stackoverflow: YOCTO - headers are searched in host's path <https://stackoverflow.com/questions/47594689/yocto-headers-are-searched-in-hosts-path>
Dec 01 13:57:38 <rburton> (if you know what you're doing then you'll know that writing a bare makefile is tedious and non-trivial)
Dec 01 13:57:48 <rburton> use autoconf/cmake/whatever you prefer
Dec 01 13:57:57 <dafna> I added this question
Dec 01 13:58:13 <rburton> if you just have a single file to compile, you don't need to use a makefile at all, just build it in the recipe
Dec 01 13:58:29 <dafna> ok
Dec 01 13:58:53 <rburton> ${CC} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} myfile.o -o myfile -lsoc
Dec 01 13:59:03 <rburton> erm, myfile.c
Dec 01 13:59:09 <dafna> so , just to clarify, the CFLAGS currently in the makefile overrides to default ?
Dec 01 13:59:15 <rburton> no, overrides it to empty
Dec 01 13:59:33 <dafna> so it does override ?
Dec 01 13:59:41 <rburton> yes, unsets it
Dec 01 13:59:48 <dafna> like the last value is the one in the makefile which is empty
Dec 01 14:00:12 <dafna> but , many projects still use bare makefile
Dec 01 14:00:15 <dafna> right ?
Dec 01 14:00:31 <rburton> sure, they're either trivial, complicated, or broken
Dec 01 14:00:50 <rburton> an example of the CFLAGS we're trying to pass in:
Dec 01 14:00:51 <rburton> export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/data/poky-tmp/master/build/work/corei7-64-poky-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0 -fdebug-prefix-map=/data/poky-tmp/master/build/work/corei7-64-poky-linux/m4/1.4.18-r0/recipe-sysroot-native= -fdebug-prefix-map=/data/poky-tmp/master/build/work/corei7-64-poky-linux/m4/1.4.18-r0/recipe-sysroot= "
Dec 01 14:01:12 <dafna> and many of them have their own CFLAGS
Dec 01 14:01:14 <rburton> and instead of CC you want
Dec 01 14:01:15 <rburton> export CC="x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -fstack-protector-strong  -D_FORTIFY_SOURC
Dec 01 14:01:16 <rburton> E=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/data/poky-tmp/master/build/work/corei7-64-poky-linux/m4/1.4.18-r0
Dec 01 14:01:19 <dafna> so they all overrides yocto's
Dec 01 14:01:54 <rburton> well behaved makefiles inherit CFLAGS from the environment and extend it, but not all do.  we patch where required.
Dec 01 14:02:11 <rburton> cflags/cppflags/ldflags/cc/ld/etc etc
Dec 01 14:02:34 <peacememories> hmm, can i add a postinstall script to an image recipe? for example to run a command in the sysroot of the built image?
Dec 01 14:02:34 <dafna> can you give an example of a makefile that inherit CFLAGS ?
Dec 01 14:02:50 <rburton> there's at least one recipe in oe-core where we just drop in a complete autoconf system as its easier than dealing with the makefile
Dec 01 14:03:05 <rburton> peacememories: images are not packages, so don't have a postinstall
Dec 01 14:03:07 <peacememories> still the problem from yesterday with samba, but while i'm waiting for an answer to my email i'll try to work around the problem
Dec 01 14:03:21 <peacememories> rburton any other way to do something like this then?
Dec 01 14:03:28 <rburton> peacememories: there *is* a number of post-image and post-rootfs hooks
Dec 01 14:03:32 <peacememories> i'd basically like to run update-rc.d some time later in the build process
Dec 01 14:03:45 <rburton> you're working around a stupid bug though
Dec 01 14:04:02 <peacememories> yes, but i can't afford to wait for a response on the mailing list for too long
Dec 01 14:04:07 <peacememories> so workarounds it is
Dec 01 14:05:17 <rburton> peacememories: my guess is that samba.sh is in a different package to the initscript
Dec 01 14:05:36 <rburton> oe-pkgdata-util can tell you what files are in what package
Dec 01 14:05:45 <peacememories> hmm, samba only exports one package afaics though
Dec 01 14:06:01 <rburton> well that file must come from somewhere
Dec 01 14:06:14 <peacememories> mhm
Dec 01 14:06:33 <rburton> and if its not in the package with the init script but appears in the rootfs later, its either another package, or the samba package writes it itself in another postinstall fragment that is running too late
Dec 01 14:06:35 <dafna> hi rburton, can you show a link to a bare makefile that is well behaved ?
Dec 01 14:06:40 <lukma> nayfe: There are some issues with your approach - relative symlinks will not work
Dec 01 14:06:45 <dafna> so I can see how it's done ?
Dec 01 14:07:01 <rburton> nayfe: just have MYCFLAGS and then include ${CFLAGS} in it
Dec 01 14:07:35 <peacememories> rburton well i'll see what oe-pkgdata-util tells me
Dec 01 14:07:49 <peacememories> ah, it seems to be part of samba-base. for reasons
Dec 01 14:10:02 <peacememories> so i need to change the config to use update-rc.d for samba-base i guess?
Dec 01 14:10:09 <nayfe> lukma: ln -s test1  ${IMAGE_ROOTFS}/path/test2 will do
Dec 01 14:10:31 <rburton> peacememories: move the file, or move the postinst, whatever is "right"
Dec 01 14:10:52 <peacememories> hmm 🤔
Dec 01 14:10:56 * peacememories probably broke a bunch of irc clients with that emoji right now
Dec 01 14:12:34 <peacememories> btw, i've seen -= used in some places in recipes, does that work for, say, removing a file from the FILES_${PN}-base variable? (in case i want to do this in an append file)
Dec 01 14:12:47 <rburton> back in the day we discovered that a colleague had an irc client that crashed on utf-8
Dec 01 14:12:49 <rburton> much fun
Dec 01 14:13:07 <rburton> peacememories: for appends its best practise to use _remove to ensure it happens at the end
Dec 01 14:13:29 <peacememories> thanks
Dec 01 14:13:43 <lukma> nayfe: and also problem with copying scripts
Dec 01 14:13:59 <lukma> just adi SRC_URI += "file://myscript.sh"
Dec 01 14:14:11 <lukma> is not copying it to either WORKDIR nor Source
Dec 01 14:15:25 <lukma> or I do it in a wrong way.....
Dec 01 14:16:38 <rburton> that will put it in WORKDIR for you
Dec 01 14:16:45 <rburton> so is your append even being found?
Dec 01 14:16:57 <nayfe> lukma: i think you can't do this, you can add a recipe with custom files and add it to the image recipe, you can also use https://patchwork.openembedded.org/patch/138100/ class
Dec 01 14:32:37 <sveinse> Why the distinction between BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE ? Manual sais little, and code could seem to indicate that the former is just passing vars over to bb, while the latter also exposes them to recipes and tasks?
Dec 01 14:38:06 <peacememories> rburton yes! it worked. thank you so much, also for introducing me to some new debugging methods :)
Dec 01 14:47:53 <sveinse> Apparently using BB_ENV_WHITELIST cause the build to crash on erroneous PATH. BB_ENV_EXTRAWHITE is what one should use to amend new vars into bb
Dec 01 14:48:21 <sveinse> Yet another example of "ye long and narrow road" of bitbake :D :P
Dec 01 14:53:41 <lukma> Is it possible to use directory structure from one recipe in the other?
Dec 01 14:54:00 <lukma> I mean I do have a recipe X, which creates FOO_DIR1
Dec 01 14:54:17 <lukma> then I do have recipe Y, which uses FOO_DIR1 to do e.g. ln -s
Dec 01 14:54:31 <rburton> lukma: for install, no.
Dec 01 14:54:41 <lukma> why do I need to first create at Y FOO_DIR1 to make it successfull ?
Dec 01 14:55:11 <lukma> install -m 0755 -d ${D}${bindir} must be done in Y recipe
Dec 01 14:56:31 <lukma> rburton: the RDEPENDS_${PN} += "X" at Y doesn't guarantee FOO_DIR1 normally created by X
Dec 01 14:57:01 <neverpanic> lukma: ${D} is separate for each recipe
Dec 01 14:57:14 <neverpanic> lukma: it's not until package installation that those get merged together
Dec 01 14:58:09 <lukma> So those are per instantiation of the package
Dec 01 14:58:22 <lukma> and get merged only when I do build final image?
Dec 01 14:58:37 <neverpanic> ${D} is per-recipe, not per-package.
Dec 01 14:58:51 <lukma> So I cannot rely on one recipe to create /usr/bin
Dec 01 14:59:00 <lukma> and reuse it in another?
Dec 01 14:59:26 <neverpanic> You can rely on some paths to be there, IIRC. I think ${D}${bindir} is one of them, but I could be wrong.
Dec 01 14:59:42 <neverpanic> If you want to be safe, just add the install -d
Dec 01 15:00:03 <neverpanic> And no, you cannot rely on other recipes to create folders in ${D} for you.
Dec 01 15:00:36 <lukma> ok, thanks for explanation
Dec 01 15:11:17 <overdamped> bluelightning: Thanks again for the help. Turns out meson has no hooks into where the c preprocessor is located, and the build was relying upon a hard coded cpp.
Dec 01 15:15:48 <lukma> rburton: Sorry to ask - but what is the exact meaning of "CLOSED" license?
Dec 01 15:16:05 <nayfe> not open :D
Dec 01 15:16:07 <lukma> is it a placeholder if we don't have around the LICENSE file?
Dec 01 15:16:23 <lukma> Or shall I use it if it is a proprietary SW ?
**** ENDING LOGGING AT Fri Dec 01 15:16:55 2017

**** BEGIN LOGGING AT Fri Dec 01 15:16:55 2017
Dec 01 15:17:13 <Crofton|work> lukma, yes for proprietary
Dec 01 15:17:31 <Crofton|work> and if you lack a licnese at least it marks the recipe as needing careful review before releasing anything
Dec 01 15:17:56 <lukma> Ok, thanks
Dec 01 15:17:56 <Crofton|work> really depends on your business needs
Dec 01 15:18:26 <lukma> I was just curious -> since LIC_CHECKSUM_FILE is very strict to have proper value
Dec 01 15:18:31 <kergoth> ideally you'd set it to a unique name for your particular brand of proprietary, but CLOSED is a decent starting point
Dec 01 15:19:08 <lukma> and then you can specify LICENSE="CLOSED" and all checks are gone
Dec 01 15:20:04 <jdelmore> ls
**** ENDING LOGGING AT Fri Dec 01 15:20:47 2017

**** BEGIN LOGGING AT Fri Dec 01 15:21:01 2017
Dec 01 15:21:16 <nayfe> lukma: in meta-foo/conf/layer.conf add LICENSE_PATH += "${LAYERDIR}/custom-licenses" then in meta-foo/custom-licenses you can add your custom license file
Dec 01 15:22:57 <nayfe> say meta-foo/custom-licenses/mylicense then you can use LICENSE = "mylicense"
Dec 01 15:26:20 <jdelmore> hello everyone
Dec 01 15:27:29 <jdelmore> I am having issues with a build process that is building dependencies that are required to continue building itself
Dec 01 15:31:01 <nayfe> jdelmore: hey you need to be more specific
Dec 01 15:31:03 <jdelmore> I am building Bro Network Security Monitor and it builds a package called bifcl which is supposed to be placed in /bin/sh. as it continues to build and tries to use that binary it cannot find it
Dec 01 15:33:18 <jdelmore> which software do you prefer to share snipets of output code
Dec 01 15:34:17 <nayfe> jdelmore: bifcl is replacing default shell ?
Dec 01 15:37:27 <neverpanic> jdelmore: you'll likely need a bifcl-native if you intend to run bifcl on the build system
Dec 01 15:41:27 <jdelmore> https://imgur.com/HGn4HGH
Dec 01 15:41:47 <wouterstreamit> Why does setting a PREFERRED_VERSION of some recipe in my local.conf work but setting it in my image recipe does not? How can I have two image recipes where I want one version in the one recipe and another version in the other recipe?
Dec 01 15:42:36 <nayfe> jdelmore: add DEPENDS = "bifcl" in your recipe ?
Dec 01 15:42:51 <nayfe> oops
Dec 01 15:42:57 <nayfe> you are using yocto sdk ?
Dec 01 15:44:56 <jdelmore> @nayfe did you see the snip of output messeges I shared?
Dec 01 15:45:45 <jdelmore> I am using the yocto environment that Phytec probided with its imx7 evaluation board
Dec 01 15:47:35 <jdelmore> @neverpanic the problem is that bifcl is being built during the process
Dec 01 15:48:39 <nayfe> it's more a cmake problem to me
Dec 01 15:50:25 <jdelmore> @nayfe correct. cmake doesn't make this process easy
Dec 01 15:51:31 <jdelmore> @neverpanic you can't add bifcl-native to DEPENDS because it doesn't exist. it is build from the Bro source repository
Dec 01 15:53:50 <neverpanic> jdelmore: is bifcl a binary?
Dec 01 15:54:19 <jdelmore> it is after it is built
Dec 01 15:54:34 <neverpanic> Unfortunately CMake does not support building tools for the build machine at the same time as building code for a target machine. Autotools does.
Dec 01 15:55:35 <neverpanic> Since you need bifcl built for the build machine's architecture, you'll have to add a bifcl-native recipe that builds bifcl for the build machine and patch the target-bifcl buildsystem to use that
Dec 01 15:56:34 <peacememories> hmm, the eternal dilemma of how to deploy python applications does not get better when combining it with yocto^^
Dec 01 15:57:14 <brrm> I try to install a package as part of a packagegroup which only contains a C header file. but it fails with '...Cannot satisfy the following dependencies for packagegroup-pe-devel:  pe-headers'. like the other packages I added it to RDEPENDS_${PN}. Why does it fail and how can it be done?
Dec 01 15:58:07 <neverpanic> brrm: the header was probably packaged in pe-headers-dev
Dec 01 15:58:30 <neverpanic> as a consequence, pe-headers is probably empty, and you didn't set ALLOW_EMPTY_pe-headers = "1", so the package was not created.
Dec 01 16:00:13 <jdelmore> @neverpanic this does build on the actual target platform
Dec 01 16:00:40 <brrm> neverpanic: I tried adding pe-headers-dev, but still the same error
Dec 01 16:01:11 <brrm> so I have to add ALLOW_EMPTY_pe-headers = "1" AND add pe-headers-dev?
Dec 01 16:01:54 <brrm> and ALLOW_EMPTY_pe-headers = "1" goes into  pe-headers_0.1.0.bb?
Dec 01 16:03:25 <neverpanic> brrm: First, you should check which package contains your header file. Then, add a dependency on that package.
Dec 01 16:03:57 <neverpanic> brrm: ALLOW_EMPTY_pe-headers = "1" doesn't give you anything if the package is empty and your goal is to get the header installed. (But yes, this would be added to the recipe file.)
Dec 01 16:04:25 <neverpanic> jdelmore: Unfortunately, Yocto doesn't know that and assumes the general case of host arch != target arch.
Dec 01 16:10:50 <brrm> neverpanic: I did like explained above and it worked. so I think the header is in pe-headers-dev
Dec 01 16:11:43 <brrm> is it possible that the pe-headers-dev package implicitely depends on pe-headers?
Dec 01 16:12:07 <brrm> and so if ALLOW_EMPTY_pe-headers = "1" is not set both are not created?
Dec 01 16:22:29 <neverpanic> brrm: main packages never depend on -dev packages. That would make the split useless, because you could never install the main package without the dev package.
Dec 01 16:22:39 <neverpanic> In fact, there's a QA check about that
Dec 01 16:22:58 <neverpanic> But yes, pe-headers-dev might depend on pe-headers.
Dec 01 16:23:09 <neverpanic> In that case, pe-headers-dev will still be created, but you won't be able to install it.
Dec 01 18:32:53 <batman_> Hello, I built an image without FSTYPE container and was able to create and run a docker image out of that rootfs. My question is then what does FSTYPE = "container" do?
Dec 01 18:33:55 <kergoth> FSTYPE?
Dec 01 18:34:26 <batman_> After comparing the logs for both the builds(with and without container FSTYPE), I understand that if I declare container FSTYPE then somethings like the kernel etc are not built.
Dec 01 18:34:28 <armpit> halstead, is autobuilder.yoctoproject.org under maintenance ?
Dec 01 18:35:02 <batman_> kergoth: I meant IMAGE_FSTYPE = "container"
Dec 01 18:35:35 <kergoth> you're mixing up running docker on target with running the image as a container on the host
Dec 01 18:36:36 <halstead> armpit: no. Let me check on it.
Dec 01 18:37:01 <armpit> halstead, k.
Dec 01 18:37:11 <batman_> kergoth, so building with IMAGE_FSTYPE = "container" produces a native rootfs?
Dec 01 18:38:38 <kergoth> yes, which is why it doesnt' need a kernel, docker isn't booting a kernel in a vm, it's booting userland processes in a container
Dec 01 18:43:14 <batman_> kergoth: Thank you! I understand it now
Dec 01 18:43:51 <halstead> armpit, Looks like eclipse-plugin-mars was dropped from the AB code on both clusters but not from the buildset on main. So the controller can't start.
Dec 01 18:43:57 * halstead tries to fix.
Dec 01 18:51:53 <halstead> armpit, Controller back up. Builders to follow.
Dec 01 18:52:08 <armpit> k
Dec 01 19:03:34 <halstead> armpit, You can start something now. Debian 8 will join soon.
Dec 01 19:04:26 <batman_> kergoth: I am comparing the rootfs.manifest for with and without IMAGE_FSTYPE = "container" build. I was expecting to see native packages in the with case. But, both the manifests are identical in terms of the packages included
Dec 01 19:04:34 <armpit> halstead, thanks
Dec 01 19:05:00 <batman_> Is my expectation wrong?
Dec 01 19:13:48 <halstead> armpit, Up. And I upgraded to jdk8 so the oxygen plugin can build here now.
Dec 01 19:13:59 * halstead heads afk for a bit.
Dec 01 19:20:44 <peacememories> hmm, if i've created a new recipe in my workspace with devtool create, how do i update this recipe to the newest source version from upstream?
Dec 01 19:27:37 <sveinse> In Krogoth, if I set IMAGE_NAME in an image recipe, the image does not create the deploy symlink from image-machine.tar.bz2 -> ${IMAGE_NAME}. I've spent an hour debugging bitbake. First I thought it was the symlink generator which didn't work, but then I see
Dec 01 19:28:10 <sveinse> when I set IMAGE_NAME, then the output image is ${IMAGE_NAME}.tar.bz, while if I don't its written to ${IMAGE_NAME}.rootfs.tar.bz2
Dec 01 19:29:28 <sveinse> and that creates problems for the symlink creator in bb
Dec 01 19:30:07 <sveinse> Does anyone know where this "rootfs" actually is appended?
Dec 01 20:07:39 <sveinse> I think I've found a bug in bitbake i krogoth: I'm setting IMAGE_NAME="sp-image-sphw-1.0.12-sveinse" in the recipe (and -e confirms it). But inside image.bbclass, when d.getVar('IMAGE_NAME',True) is called, I get "sp-image-sphw-1.0.12" back. Without the -sveinse suffix!
Dec 01 20:08:26 <sveinse> So what could be modifying IMAGE_NAME?
Dec 01 20:23:26 <jdelmore> I am having trouble with the do_install() using oe_runmake
Dec 01 20:23:28 <jdelmore> https://imgur.com/GXfTkEW
Dec 01 20:24:58 <jdelmore> it fales to copy a static library file (.a) to /usr/lib/
Dec 01 20:25:01 <jdelmore> fails
Dec 01 20:28:38 <jdelmore> I am using "oe_runmake install PREFIX=${D}" within do_install()
Dec 01 20:29:42 <nayfe> You have to install it in ${D}/${libdir} and add it to FILES_${PN}-dev for example. You dont need to set prefix
Dec 01 20:30:30 <nayfe> Did you try with stock do_install(), without override it?
Dec 01 20:32:16 <nayfe> sveinse: did you try sp-image-sphw-sveinse-1.0.12?
Dec 01 20:33:09 <nayfe> jdelmore: did you also install libdir folder before?
Dec 01 20:34:54 <jdelmore> nayfe if I don't override the do_install i get a "contains probably-redundant RPATH /usr/lib"
Dec 01 20:35:58 <jdelmore> also, not sure what you mean by install libdir
Dec 01 20:37:51 <nayfe> You shouldn't have anything pointing to /usr it's host poisoning right?
Dec 01 20:39:13 <sveinse> nayfe: No, however if I set the version to "sp-image-sphw-1.0.0.0-sveinse" in text it works, while if I do "sp-image-sphw-${MYVERSION}" is fails. So its connected to expansion I think. I'm still debugging in python
Dec 01 20:39:26 <nayfe> I mean instead of using cmake to install, you can copy built stuff in deploy folder in recipe
Dec 01 20:40:18 <sveinse> The variable (store) is ok all until create_symlinks() is executed
Dec 01 20:55:52 <sveinse> I think I found it. the MYVERSION variable is read from disk, and the path changes. So my bad essentially
Dec 01 20:57:40 <jdelmore> i think cmake is trying to move the .a file to the hosts /usr/lib
Dec 01 20:58:14 <jdelmore> @nayfe is there a way to specify the target for files
Dec 01 21:01:45 <nayfe> It should be automatic when inherit cmake (--installdir should be already set to correct folder)
Dec 01 21:03:18 <sveinse> Is there a way to set a variable once and use the cached value after? I set _MYVAR:="${@get_version(d)}" and then MYVAR ?= "${_MYVAR}", but still the get_version() function is called many times
Dec 01 21:03:33 <sveinse> seems very inefficient
Dec 01 21:03:57 * nayfe going to bed 
Dec 01 21:04:11 <sveinse> nayfe: good night
Dec 01 21:04:31 <nayfe> Ty, see you on monday ;)
Dec 01 21:06:57 <rburton> sveinse: why not just MYVAR:=${@get_version(d)}
Dec 01 21:07:05 <rburton> thats exactly what := is for...
Dec 01 21:08:12 <sveinse> rburton: because to have it overrideable in local.conf. no, wait, that overrides anyways. ok, ill try it
Dec 01 21:08:52 <rburton> see eg bitbake.conf
Dec 01 21:08:53 <rburton> # Immediate expansion since there is no point in reapeatedly calling
Dec 01 21:08:53 <rburton> # os.uname() throughout parsing
Dec 01 21:08:54 <rburton> BUILD_ARCH := "${@os.uname()[4]}"
Dec 01 21:12:48 <sveinse> yeah, that worked. The function is still called 5-10 times during a build, but a lot less frequent than before
Dec 01 21:38:45 <uglyoldbob> hi im trying to create a sizecheck function in a recipe. i have this so far https://pastebin.com/LE1TRBTY the (size=$size) does not print as expected, which form of escaping or not escaping should i use here?
Dec 01 21:41:30 <uglyoldbob> hmm, nevermind, it seems my actual question should be where do i hook for finding the size of a generated jffs2 image
Dec 01 21:41:34 <kergoth> obviously hardcoding jffs2 and using ls are both bad approaches, but it does look like it hsould function fine
Dec 01 21:54:17 <uglyoldbob> i corrected my file link to ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.jffs2 and made another simple correction, works as i hoped
Dec 01 22:29:09 <yocti> New news from stackoverflow: How to export DBUS_SESSION_BUS_ADDRESS <https://stackoverflow.com/questions/41242460/how-to-export-dbus-session-bus-address>
**** ENDING LOGGING AT Sat Dec 02 02:59:59 2017