**** BEGIN LOGGING AT Wed Oct 21 02:59:59 2015
Oct 21 03:10:58 <qknight> works! nice
Oct 21 03:11:03 <qknight> how to enable xfce4 on yocto?
Oct 21 03:16:40 <qknight> i don't understand why this is not mentioned in meta-xfce ...
Oct 21 03:28:47 <qknight> funny thing: i attached a usb keyboard to the yocto host and i can't type anything
Oct 21 03:28:51 <qknight> Starting Bootlog daemon: bootlogd: cannot allocate pseudo tty: No such file or directory
Oct 21 03:29:21 <qknight> lsusb shows the keyboard and log shows: resize:  can't open terminal /dev/tty
Oct 21 03:30:20 <parrot2> hello, I'm trying to bake a recipe for darktable and it complains about perl missing. I already put RDEPENDS_${PN} = "perl" but the error persists. Any idea?
Oct 21 03:30:24 <parrot2> Error log at http://pastebin.com/QzAH5zN8
Oct 21 03:32:35 <qknight> parrot2: DEPENDS = "libfribidi libtool libgcrypt gst-plugins-bad virtual/libsdl \
Oct 21 03:32:52 <qknight> parrot2: you have to add it to DEPENDS instead of RDEPENDS_
Oct 21 03:33:10 <qknight> parrot2: if the package, for instance when doing the installation, or later in the system should have perl
Oct 21 03:33:15 <parrot2> you mean perl or the items you posted?
Oct 21 03:33:51 <qknight> parrot2: this was an example from vlc.inc
Oct 21 03:33:55 <qknight> parrot2: try to add perl there
Oct 21 03:34:02 <qknight> parrot2: into the DEPENDS
Oct 21 03:34:58 <parrot2> qknight: hmm...I tried DEPENDS = "perl" but still the same thing
Oct 21 03:35:23 <qknight> parrot2: can you paste the whole file?
Oct 21 03:35:28 <qknight> paste.debian.com
Oct 21 05:20:53 <parrot2> qknight: sorry for the slow reply but here you go http://pastebin.com/0DJeyKC3
Oct 21 05:21:01 <parrot2> I cant access paste.debian.com for some reason
Oct 21 06:41:20 <parrot2> bluelightning: ping
Oct 21 06:41:32 <bluelightning> morning parrot2, all
Oct 21 06:42:32 <parrot2> bluelightning: good morning. This time I need help. I'm trying to bake a recipe for darktable and it complains about perl missing. I already put RDEPENDS_${PN} = "perl" but the error persists. Any idea?
Oct 21 06:43:29 <parrot2> Here's my recipe. Ignore the piglit related comments since I largely took the recipe from piglit and modified it a bit. http://pastebin.com/0DJeyKC3
Oct 21 06:43:50 <parrot2> and of course the error log http://pastebin.com/QzAH5zN8
Oct 21 06:45:01 <bluelightning> parrot2: RDEPENDS is for runtime dependencies though, this is looking for perl at build time
Oct 21 06:45:31 <bluelightning> parrot2: it could be that you need to inherit perlnative also
Oct 21 06:46:14 <bluelightning> (I say "also" - I can't tell but maybe it does also need perl at runtime, you'd need to double-check that if you haven't already)
Oct 21 07:00:42 <mckoan> good morning
Oct 21 07:01:04 <abelal> morning bluelightning
Oct 21 07:03:47 <bluelightning> morning mckoan, abelal
Oct 21 07:16:28 <parrot2> bluelightning: sorry for the slow reply. I inherited perlnative and it no longer complains about perl. Well it still complains about libgphoto2 but at least we made progress
Oct 21 07:18:23 <bluelightning> parrot2: \o/
Oct 21 07:20:07 <parrot2> do we have libgphoto2 here?
Oct 21 07:29:19 <bluelightning> parrot2: in meta-oe I believe
Oct 21 07:33:05 <bluelightning> parrot2: yep: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=gphoto2
Oct 21 07:34:47 <parrot2> bluelightning: thanks for being my saviour ...again...but it looks like I'm starting to get into a dependency hell..
Oct 21 09:04:41 <parrot2> How do you guys deal with SRC_URI whose app has sourceforge as its download server?
Oct 21 09:07:19 <CTtpollard> I tend to find a mirror if possible
Oct 21 09:11:45 <parrot2> CTtpollard: suppose if I have found my preferred mirror, how can we get the direct http link that we can assign to SRC_URI?
Oct 21 09:12:09 <CTtpollard> can you give me your example?
Oct 21 09:12:27 <parrot2> http://sourceforge.net/projects/lensfun/files/0.3.1/lensfun-0.3.1.tar.gz/download
Oct 21 09:20:44 <Ox4> u-boot part II (day 2) :)
Oct 21 09:20:48 <bluelightning> parrot2: git grep SOURCEFORGE_MIRROR for lots of examples
Oct 21 09:23:04 <parrot2> bluelightning: hmm..that command returns nothing :-( Are you suggesting that every sourceforge mirror has a git repo?
Oct 21 09:24:08 <bluelightning> parrot2: I mean run that in the base of your poky/oe-core checkout
Oct 21 09:24:22 <bluelightning> parrot2: if you don't use "git grep" already, you should ;)
Oct 21 09:24:26 <CTtpollard> +1
Oct 21 09:25:39 <parrot2> bluelightning: what does git grep do?
Oct 21 09:25:58 <parrot2> btw now that command returns a lot of things which I should be able to make sense of
Oct 21 09:26:10 <bluelightning> parrot2: searches all of the files tracked in the git repository for the specified regex
Oct 21 09:27:25 <parrot2> bluelightning: ah nice.....
Oct 21 09:27:47 <parrot2> thanks bluelightning and CTtpollard . Learned a new thing today ;-)
Oct 21 09:27:53 <bluelightning> np :)
Oct 21 10:25:47 <abelal> bluelightning: can you please shed some insight on "An auto generated BSP description was used, this normally indicates a misconfiguration."
Oct 21 10:26:08 <abelal> my bsp uses the linux-yocto
Oct 21 10:26:19 <abelal> and it was created through the bsp layer generation tool
Oct 21 10:26:28 <abelal> so I have all the required sccs and stuff
Oct 21 10:27:50 <bluelightning> abelal: the check is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-yocto.bbclass#n295
Oct 21 10:27:51 <abelal> secondly I can see build-mf/tmp/work-shared/<machine>/kernel-source/.kernel-meta/top_tgt
Oct 21 10:28:04 <bluelightning> I'm not familiar with that area of the code at all but maybe you can make better sense of it
Oct 21 10:28:05 <abelal> and it lists the base scc file
Oct 21 10:28:19 <abelal> hmmmm
Oct 21 10:28:27 <abelal> i'll have a look
Oct 21 10:28:32 <abelal> bluelightning: thanks :)
Oct 21 10:28:52 <abelal> bluelightning: what's bruce ashfields handle on IRC?
Oct 21 10:28:59 <bluelightning> abelal: zeddii
Oct 21 10:29:30 <bluelightning> he's here, but not sure if he's awake/around yet
Oct 21 10:30:02 <abelal> hmmm whois says he's idling for 7 days now
Oct 21 10:30:07 <abelal> zeddii: ping
Oct 21 10:30:18 <abelal> bluelightning: thanks again :)
Oct 21 11:07:51 <Ox4> guys, I added u-boot_%.bbapend with following content: http://dpaste.com/2NHYXQ6 , but when I do bitbake u-boot it fetches v2015.07+gitAUTOINC+33711bdd4a-r0
Oct 21 11:08:24 <joshuagl> you have a typo in your filename
Oct 21 11:08:32 <joshuagl> two p's in append
Oct 21 11:09:14 <Ox4> 205 Oct 21 14:03 u-boot_%.bbappend
Oct 21 11:12:55 <joshuagl> and `bitbake-layers show-appends` lists your append?
Oct 21 11:13:10 <raykinsella78> how do I build a specific version of a package - grub for instance?
Oct 21 11:13:15 <jku> does that % actually work in filenames?
Oct 21 11:13:52 <joshuagl> it does
Oct 21 11:13:55 <CTtpollard> raykinsella78: provide / find a recipe for it
Oct 21 11:14:12 <raykinsella78> CTtpollard: huh?
Oct 21 11:15:19 <joshuagl> jku: https://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html#append-bbappend-files
Oct 21 11:16:19 <Ox4> joshuagl: u-boot_2015.07.bb:
Oct 21 11:16:20 <Ox4>   /home/vadimi/yocto/poky/firmware/meta-powerbeacon/recipes-bbappend/u-boot/u-boot_%.bbappend
Oct 21 11:16:46 <jku> raykinsella78: http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-PREFERRED_VERSION
Oct 21 11:17:23 <raykinsella78> jku: thanls!
Oct 21 11:20:03 <joshuagl> Ox4: when you say it "fetches v2015.07+gitAUTOINC+33711bdd4a-r0" what do you mean?
Oct 21 11:21:28 <Ox4> joshuagl: sorry, I have already understood. It fetches the source from my repo but prints out v2015.07+git... :)
Oct 21 11:52:39 <Ox4> guys, could somebody help me with building u-boot: http://dpaste.com/0GCEB5V ? I have a script with which u-boot is build fine on my local machine. Here it is: http://paste.pound-python.org/show/yPqjOTVTNSPPFo1wcBpK/ $opt is "PowerBeacon"
Oct 21 11:54:26 <Ox4> and here is the bbappend file of mine: http://dpaste.com/3K300EJ
Oct 21 12:06:00 <Ox4> why the .config is not found?
Oct 21 12:45:45 <Ox4> well, I found the problem. The pb_am3874_defconfig should be before all env fw_validation
Oct 21 12:45:56 <Ox4> but I don't know how to place it before :-(
Oct 21 12:46:56 <Ox4> EXTRA_OEMAKE_append just place my parameters in this order: env fw_validation pb_am3874_defconfig
Oct 21 12:52:42 <frsc__> Ox4: maybe you try EXTRA_OEMAKE_prepend instead
Oct 21 13:14:38 <Ox4> frsc__: it doesn't work. I don't see my parameters at all
Oct 21 13:59:51 <qknight> is there a manual how to create a patch which can be applied in the SRC_URI = " \  file://0004-mozbug746112-no-decommit-on-large-pages.patch;patchdir=../../ \ section?
Oct 21 14:00:43 <CTtpollard> qknight: you'll probably want to do a bbappend
Oct 21 14:01:08 <qknight> right now it is about to create the patch
Oct 21 14:01:10 <qknight> i don't have it yet
Oct 21 14:01:30 <CTtpollard> oh, you mean you want to create a patch, and then apply it with the recipe?
Oct 21 14:02:30 <qknight> CTtpollard: yes
Oct 21 14:02:36 <qknight> http://lists.openembedded.org/pipermail/openembedded-commits/2015-September/182546.html <- like this
Oct 21 14:02:40 <qknight> but that patch from there does not apply
Oct 21 14:03:58 <CTtpollard> so, you can create your patch on top of the commit used in the recipe in git, then take that patch file and place in in a subdir of the recipe, and and the file name to the recipe as you showed originally
Oct 21 14:04:06 <lpapp_> hi, when I say "chown nic:nic -R ${D}/opt/foo" in my do_install_append, does that mean that it will override the permissions on files under /opt/foo on the rootfs, coming from another package of another recipe?
Oct 21 14:04:38 <qknight> http://paste.ubuntu.com/12885819/ <- this is my patch and it fails with Patch fix-the-compile-error-of-powerpc64.patch does not apply (enforce with -f)
Oct 21 14:04:39 <ndec> ${D} is just your package.
Oct 21 14:05:05 <lpapp_> ok, so perhaps I ought to move that chown logic to the image creation step?
Oct 21 14:05:23 <qknight> CTtpollard: probably the easiest to use git format-patch
Oct 21 14:05:28 <lpapp_> because in order to do that from various recipes, I would need to make sure that the user is already created at the stage of each package installation.
Oct 21 14:05:28 <bluelightning> qknight: I forget which version of the build system you're using, but if it's 1.8 or newer then devtool tries to help a lot with this kind of workflow
Oct 21 14:05:29 <ndec> if you want to touch all files from the image, then yes.
Oct 21 14:05:49 <lpapp_> which is not impossible from each offending recipes, but it is a bit messy
Oct 21 14:05:51 <CTtpollard> qknight: yeh there's numerous ways to tell git to create a patch file
Oct 21 14:05:57 <lpapp_> which is not impossible from each offending recipe, but it is a bit messy.*
Oct 21 14:06:11 <qknight> CTtpollard: i'm on poky with daisy meta-* repos
Oct 21 14:06:41 <lpapp_> we have this USERADD_PARAM_${PN}-foo = ... for the recipe in question.
Oct 21 14:06:42 <bluelightning> qknight: ah ok, a bit too old for devtool then
Oct 21 14:07:19 <CTtpollard> qknight: have you generated your patch off the top of the SHA1 defined in the recipe?
Oct 21 14:07:41 <lpapp_> so it is not possible from one recipe to rewrite the permissions in a directory recursively on the rootfs?
Oct 21 14:07:41 <bluelightning> lpapp_: you cannot do that from do_install; you could do it from a postinst script though
Oct 21 14:07:53 <lpapp_> ah, makes sense, yes, good idea.
Oct 21 14:07:55 <bluelightning> lpapp_: in a postinst script, definitely
Oct 21 14:10:19 <lpapp_> bluelightning: ROOTFS_POSTINSTALL_COMMAND does not allow inline code either? In other words, I will need to create a little function for this command?
Oct 21 14:10:39 <lpapp_> Furthermore, RPC will be executed after USERADD_PARAM_${PN}-foo?
Oct 21 14:10:44 <lpapp_> RPC means ROOTFS_POSTINSTALL_COMMAND.
Oct 21 14:10:58 <simonl> a question on recipe/package versions: I have a package (i2c-tools) that I need a newer version of. I'd need the unreleased vcs version. Is there some guidelines for how to set PV to make bitbake prefer the vcs recipe while avoiding future trouble (once a new version is released)?
Oct 21 14:11:21 <bluelightning> lpapp_: by postinstall script I meant pkg_postinst for the recipe, not ROOTFS_POSTINSTALL_COMMAND (though you could alternatively do it there)
Oct 21 14:12:08 <bluelightning> simonl: indeed there is: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#properly-versioning-pre-release-recipes
Oct 21 14:13:04 <bluelightning> simonl: typically you would do it as PV = "lastreleasever+git${SRCPV}"
Oct 21 14:14:04 <qknight> CTtpollard: yes on top of GIT but i dont' use git, just cd'ed into the build directory where the vanialla .h file was
Oct 21 14:14:07 <lpapp_> bluelightning: so I have pkg_postinst_${PN}-foo () { chown foo:foo -R ${IMAGE_ROOTFS} }
Oct 21 14:14:40 <lpapp_> bluelightning: so I have pkg_postinst_${PN}-foo () { chown foo:foo -R ${IMAGE_ROOTFS}/opt/foo }*
Oct 21 14:14:45 <simonl> bluelightning: Thanks a ton! I guess "pre release" would have been a good search term :)
Oct 21 14:14:55 <bluelightning> lpapp_: not ${IMAGE_ROOTFS}, $D
Oct 21 14:15:05 <bluelightning> lpapp_: and I do mean $D _not_ ${D}
Oct 21 14:15:55 <lpapp_> but $D will also reflect on /opt/foo from other recipes?
Oct 21 14:16:55 <bluelightning> lpapp_: it's worth understanding the context in which a postinstall script runs
Oct 21 14:17:35 <bluelightning> lpapp_: it will be run after installing the package during image construction (or on the target when installing the package, if you are using package management on the target)
Oct 21 14:17:50 <bluelightning> lpapp_: so the context is the entire image, but only if that package is included
Oct 21 14:18:06 <lpapp_> so probably dropping the $D could help?
Oct 21 14:18:11 <bluelightning> lpapp_: no
Oct 21 14:18:26 <bluelightning> lpapp_: it won't work during image construction if you do that, it'll be deferred until first boot
Oct 21 14:18:52 <lpapp_> $D is empty when installing it separately from the image?
Oct 21 14:19:06 <bluelightning> lpapp_: the environment variable D effectively gets set to ${IMAGE_ROOTFS} during image construction when calling the postinst scripts
Oct 21 14:19:12 <bluelightning> lpapp_: on the target it's not set
Oct 21 14:19:18 <lpapp_> ah, ok, thank you.
Oct 21 14:19:26 <bluelightning> thus you can have postinst scripts that work properly in both contexts
Oct 21 14:19:58 <bluelightning> when desired you can also force execution on first boot by checking if $D is set and doing "exit 1" if so
Oct 21 14:20:11 <lpapp_> it is interesting to read that I ought to strive for $D rather than ${D} as I see the latter used throughout our layer.
Oct 21 14:20:25 <bluelightning> lpapp_: only in the context of postinst scripts
Oct 21 14:20:34 <lpapp_> hmm, alright, thanks.
Oct 21 14:20:35 <bluelightning> ${D} is still what you should be using in do_install
Oct 21 14:20:51 <bluelightning> that is the bitbake variable D, which is a different thing
Oct 21 14:21:06 <bluelightning> though they are a vaguely similar concept perhaps
Oct 21 14:23:58 <lpapp_> bluelightning: thanks, appreciated.
Oct 21 15:15:06 <T0mW> how do I set the REQUIRES within an rpm from a recipe?  I have a new package that needs another installed along with it (dependancy) using smart.
Oct 21 15:15:26 <T0mW> I tried RDEPENDS
Oct 21 15:15:54 <T0mW> Do I use something like RREQUIRES_${PN} ?
Oct 21 15:17:15 <rburton> did you use RDEPENDS_${PN}?
Oct 21 15:17:38 <T0mW> I'll try it
Oct 21 15:20:07 <T0mW> rburton: doesn't work. "rpm -qp --requires <blah>" doesn't list my requirement.  I did clean + cleansstate before build so it should have built the rpm from scratch.
Oct 21 15:20:22 <kergoth> that's what rdepends is for..
Oct 21 15:22:27 <bluelightning> RDEPENDS definitely gets translated to Requires in our rpm packaging code
Oct 21 15:23:07 <bluelightning> you should even be able to see that in the spec file created within the workdir
Oct 21 15:24:38 <T0mW> AHA! down at the bottom of my recipe is "RDEPENDS_${PN} = "base-files"", = not +=
Oct 21 15:24:52 <T0mW> thought I was going crazy, "it should work..."
Oct 21 15:25:10 <bluelightning> bitbake -e recipename | less is useful for this kind of thing
Oct 21 15:26:23 <T0mW> that did it, thank you
Oct 21 16:27:09 <kbingham> =Can I exclude the kernel from being built from my image? - I tried the obvious PACKAGE_EXCLUDE = "virtual/kernel" but it didn't work (after inherit core-image)
Oct 21 16:28:18 <kergoth> set RDEPENDS_kernel-base = "" to avoid installing the kernel image into the rootfs
Oct 21 16:28:52 <kergoth> see also "How do I install/not-install the kernel image on the rootfs?" in the kernel dev manual in the yocto project docs
Oct 21 16:32:27 <raykinsella78> if I change my PREFERRED_VERSION of gcc I expect it to trigger a complete rebuild but it doesn;t
Oct 21 16:34:20 <bluelightning> raykinsella78: I think we have a dedicated variable for that, what you're setting is probably being overridden
Oct 21 16:34:29 <bluelightning> raykinsella78: the dedicated variable is GCCVERSION
Oct 21 16:39:05 <raykinsella78> ok so I need to say GCCVERSION in local.conf?
Oct 21 16:40:53 <bluelightning> raykinsella78: I believe so yes
Oct 21 16:47:13 * zeddii saw a IRC notification, but can't find it in history. who ever it was can email me .. a better medium for me to notice anyway.
Oct 21 16:49:24 <bluelightning> zeddii: https://www.yoctoproject.org/irc/%23yocto.2015-10-21.log.html#t2015-10-21T10:25:48
Oct 21 16:54:39 <Crofton> # Hack for mesa + gcc5 failures
Oct 21 16:54:39 <Crofton> GCCVERSION_armv7a="4.9.3"
Oct 21 16:54:42 <Crofton> but he left :)
Oct 21 17:12:36 <Ulfalizer> how do the FILES_* variables get their default values?
Oct 21 17:12:40 <Ulfalizer> as in, how is it done internally
Oct 21 17:13:04 <Ulfalizer> FILES_* seems to include /usr/bin and other "standard" directories by default
Oct 21 17:17:04 <bluelightning> Ulfalizer: most of it comes from meta/conf/bitbake.conf
Oct 21 17:19:20 <Ulfalizer> ahh, yeah, i see it
Oct 21 17:19:21 <Ulfalizer> thanks
Oct 21 17:26:32 <grunzi> Hi i am trying to do this "bitbake image-multimedia-full". After a while it gives me this error " ERROR: User requested feature sdl configure was not able to find it. Install SDL devel" I am using Ubuntu 15.10 and this is the list of all packages that I have installed regarding SDL.
Oct 21 17:26:36 <grunzi> libsdl-image1.2,
Oct 21 17:26:45 <grunzi> libsdl-image1.2-dbg
Oct 21 17:26:45 <grunzi> libsdl-image1.2-dev
Oct 21 17:26:45 <grunzi> libsdl-mixer1.2
Oct 21 17:26:45 <grunzi> libsdl-mixer1.2-dev
Oct 21 17:26:45 <grunzi> libsdl-net1.2
Oct 21 17:26:45 <grunzi> libsdl-net1.2-dev
Oct 21 17:26:45 <grunzi> libsdl1.2-dbg
Oct 21 17:26:45 <grunzi> libsdl1.2-dev
Oct 21 17:26:45 <grunzi> libsdl1.2debian
Oct 21 17:26:45 <grunzi> libsdl2-2.0-0
Oct 21 17:26:45 <grunzi> libsdl2-dbg
Oct 21 17:26:45 <grunzi> libsdl2-dev
Oct 21 17:26:46 <grunzi> I don't know which sdl package I could install additionally. There is a second error message "ERROR: Task 4069 (virtual:native: ../mars/sources/poky/meta/recipes-devtools/qemu/qemu_2.2.0.bb, do_configure) failed with exit code '1'" So I tried "bitbake -b qemu_2.2.0.bb" which worked. But "bitbake image-multimedia-full" still won't work. So I tried "bitbake qemu" which ended with the error message ""ERROR: Task 587 (.../mars/sources/poky/meta/recipes-graphics
Oct 21 17:32:36 <rburton> grunzi: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8553 has a workaround
Oct 21 17:32:37 <yocti> Bug 8553: normal, Medium+, 2.0, ross.burton, NEW , Image build fails on Ubuntu 15.10
Oct 21 17:33:08 <grunzi> ah ok thanks a lot. been looking for hours know
Oct 21 17:38:42 <qknight> i would like to clean deploy/images/mytarget/* but i don't want to loose the rpm files used to build the image(s) there
Oct 21 17:39:20 <qknight> bitbake -c clean TARGET <- will that only remove the fsl-image-x11-t4240rdb-64b-20151017185342.rootfs.ext2.gz and similar in deploy/images/mytarget/?
Oct 21 17:40:47 <Ulfalizer> when you add e.g. "nativesdk" to BBCLASSEXTEND in foo.bb and foo.bb DEPENDS on "bar", it's my understand that nativesdk-foo implicitly gets a nativesdk-bar dependency. how does that work internally?
Oct 21 17:40:56 <Ulfalizer> *understanding
Oct 21 17:41:05 <Ulfalizer> provided it's correct...
Oct 21 17:41:21 <Ulfalizer> i'm trying to figure out which parts of bitbake are "magic" and which are defined in the metadata :P
Oct 21 17:44:09 <kergoth> Ulfalizer: see nativesdk.bbclass
Oct 21 17:44:13 <kergoth> Ulfalizer: it handles the dependency mapping
Oct 21 17:44:41 <kergoth> all BBCLASSEXTEND does is tells bitbake to generate multiple recipes from one recipe, with each variant inheriting the specified bbclass
Oct 21 17:44:45 <kergoth> then the bbclass does most of the rest
Oct 21 17:45:08 <kergoth> the multilib bits are slightly more complex, that's similar, but lets a single bbclass be responsible for generating *multiple* recipe variants instead of just one
Oct 21 17:45:23 <kergoth> multilib.bbclass generates a new recipe for each multilib:<name> in bbclassextend, iirc
Oct 21 17:45:31 <Ulfalizer> yeah, i don't even know what the multilib stuff does
Oct 21 17:45:50 <kergoth> multilib:lib32 causes lib32-<recipe  name> to be emitted
Oct 21 17:46:01 <kergoth> then the tuning bits know what to do with that to change the tuning in use (DEFAULTTUNE)
Oct 21 17:46:10 <kergoth> again almost entirely in the metadata
Oct 21 17:46:28 <kergoth> but in bitbake it's similar to how simpler bbclassextends are handled
Oct 21 17:46:53 <kergoth> if you want background on how bitbake works, the chapter elizabeth flanigan wrote for the architecture of open source software book may be of interest
Oct 21 17:47:25 * kergoth suspects we could still use some more conceptual bits in the yocto project docs
Oct 21 17:47:32 <Ulfalizer> so the only magic with BBCLASSEXTEND is that it acts as-if you had multiple recipes native-myrecipe.bb, nativesdk-myrecipe.bb, etc., each inheriting the same class as in the prefix?
Oct 21 17:48:02 <kergoth> exactly
Oct 21 17:48:12 <Ulfalizer> okay, that makes sense then
Oct 21 17:49:06 <Ulfalizer> yeah, i should read that one
Oct 21 17:50:07 <kergoth> then the bbclass is what implements the real changes for that variant
Oct 21 17:51:05 <kergoth> i also highly recommend pretty much everyone, at some point, read bitbake.conf and base.bbclass. all the main variables and tasks are defined there for all recipes
Oct 21 17:51:15 <kergoth> not directly applicable, but useful background
Oct 21 17:52:50 <Ulfalizer> yeah, i've already looked at them a bit
Oct 21 17:53:27 <kergoth> note that native is actually a suffix on the recipe name, whereas nativesdk is a prefix. inconsistent, but it's due to history
Oct 21 17:53:35 <kergoth> i.e. foo-native, nativesdk-foo
Oct 21 17:54:14 <Ulfalizer> how's the purpose of the meta-openembedded/ layer different from the meta/ layers's btw? is the former one "additional non-core openembedded stuff"?
Oct 21 17:54:23 <Ulfalizer> ahh, hadn't noticed that. yeah, that's a bit confusing. :)
Oct 21 17:54:29 <Ulfalizer> s/how's/what's/
Oct 21 17:54:34 <Ulfalizer> err
Oct 21 17:54:38 <Ulfalizer> scrap that
Oct 21 17:55:29 <psidhu> who decides when webkitgtk version is bumped? there's an upstream patch that fixes a build issue, but I'm not sure if I should bump the recipe version or add the upstream patch to the current version (khem, it seems you might have some insight to this)
Oct 21 17:55:31 <Ulfalizer> my understanding is that meta/ has recipes from openembedded. so what's meta-openembedded?
Oct 21 17:55:35 <kergoth> meta is from oe-core, oe-core is meant to be a stable, well tested baseline that everyone can share
Oct 21 17:55:43 <kergoth> it's shared by the yocto project and other oe-based projects
Oct 21 17:56:05 <kergoth> the intent was companies could collaborate on such a baseline and thereby avoid wasting money reinventing that part so they can focus on where they really differentiate
Oct 21 17:56:35 <kergoth> meta-openembedded is basically everything not considered core which doesn't already fit into another focused layer
Oct 21 17:56:49 <Ulfalizer> ok, kinda what i thought. thanks.
Oct 21 17:57:10 <kergoth> specifically the meta-oe layer inside meta-openembedded is basically just a pool of random recipes that don't hae anywhere better to live :)
Oct 21 17:58:22 <Ulfalizer> perhaps more layers could have a README in them to explain what they are
Oct 21 17:58:25 <kergoth> yocto is an umbrella project that includes a buildsystem component, which is poky. poky is both an integration repository which includes bitbake, oe-core, meta-yocto, etc together, and a reference distribution for hte yocto project (that's in meta-yocto)
Oct 21 17:58:29 <kergoth> probably, yes
Oct 21 17:58:43 <Ulfalizer> meta/ was pretty confusing first time i saw it. looked like an "unnamed" layer. :)
Oct 21 17:59:20 <kergoth> yeah, it's really a subdir of oe-core, so my guess was 'core' or 'meta-core' seemed redundant, but it'd be nice to have that for clarity, particularly since it's also pulled into poky
Oct 21 17:59:26 * kergoth shrugs, wasn't the one making those calls
Oct 21 17:59:41 <kergoth> naming is a concern as well, i.e. meta-yocto should really be meta-poky, to avoid yocto vs poky naming confusion
Oct 21 18:00:03 <Ulfalizer> yeah, i think i remember being confused about that too
Oct 21 18:00:21 <Ulfalizer> exactly what poky is is still a bit confusing :P
Oct 21 18:00:25 <kergoth> most are at first. yocto, poky, oe-core, bitbake, meta-oe, lots of components and not everyone knows how it fits together
Oct 21 18:00:33 <Ulfalizer> distribution, build system, etc.
Oct 21 18:00:39 <kergoth> i just described that :)
Oct 21 18:01:01 <kergoth> "yocto is an umbrella project that includes a buildsystem component, which is poky. poky is both an integration repository which includes bitbake, oe-core, meta-yocto, etc together, and a reference distribution for the yocto project (that's in meta-yocto)"
Oct 21 18:01:08 <kergoth> using the name for two things doesn't help..
Oct 21 18:01:12 <Ulfalizer> ah, sorry, missed it
Oct 21 18:01:16 <kergoth> np
Oct 21 18:01:38 <kergoth> but yes, common source of confusion, it's a work in progress to clarify such things
Oct 21 18:01:51 <Crofton> where is that quote?
Oct 21 18:02:10 <Ulfalizer> i'd like some more conceptual "under-the-hood" stuff in the manual, but i'm not sure if other people's brains work like mine
Oct 21 18:02:17 <Crofton> this poky build system must die
Oct 21 18:02:18 <kergoth> the description of yocto and poky was me quoting myself from about 5 minutes ago. not sure what the ofifcial material states
Oct 21 18:02:21 <Ulfalizer> i tend to be a bit ocd about understanding how stuff works
Oct 21 18:02:26 <Ulfalizer> other people seem to get by without it :P
Oct 21 18:02:52 <kergoth> Ulfalizer: some folks work bottom-up, so want details first and concepts later, and other folks want high level concepts first and details later, and some folks don't learn well by reading at all..
Oct 21 18:02:58 <kergoth> presumably hard to address everything
Oct 21 18:03:06 <kergoth> but yocto project does have technical writers working on the docs, thank god
Oct 21 18:03:15 <kergoth> that's a major lack in most open source projects
Oct 21 18:03:30 <kergoth> I think the docs could still use some more conceptual information
Oct 21 18:03:42 <Ulfalizer> yeah, i'm definitely bottom-up. high-level stuff feels wishy-washy until i get the lower-level details.
Oct 21 18:03:42 <kergoth> i.e. I'm not sure that our orthogonal axes of distro, machine, and image are well documented anywhere at this point
Oct 21 18:03:47 <kergoth> except possibly posts by me or koen
Oct 21 18:03:56 <Crofton> +2
Oct 21 18:04:11 <Crofton> We need to create a real BSP guide explaining that
Oct 21 18:04:28 <kergoth> oh, yes, we need good docs on creating a new bsp as well as creating and maintaining a distro at some point
Oct 21 18:05:22 <Crofton> and explaining how we expect a BSP to behave, ie all overrides do not imapct other machines
Oct 21 18:05:35 <Crofton> so many people assume you only have one bsp active at a time
Oct 21 18:06:56 <Ulfalizer> which parts of the parsing process are "file-specific" by the way? e.g., which parts would work differently if you just merged all the parsed files together into a single file?
Oct 21 18:07:14 <Ulfalizer> ignoring that some files must exist. could just have those contain the absolute minimum.
Oct 21 18:07:25 <Ulfalizer> *i.e.
Oct 21 18:07:34 <kergoth> configuration metadata is global, affects all recipes, and that flows down into the individual recipes
Oct 21 18:08:08 <kergoth> hte config files could be one file and it wouldn't change much, but recipes are separate. bbclasses are inherited by recipes, but inherit is really just a special purpose include/require, anything in a bbclass could go directly into the recipe as well
Oct 21 18:08:59 <Ulfalizer> would copy-pasting the bbclass into the position where it's inherited work?
Oct 21 18:09:07 <Ulfalizer> or is there more magic to it than that?
Oct 21 18:09:13 <Ulfalizer> might have to move it to the end i guess...
Oct 21 18:11:18 <kergoth> did my 3 messages about inherit go through? got disconnected
Oct 21 18:12:36 <Ulfalizer> nope, didn't see anything
Oct 21 18:12:58 <kergoth> inherit is an immediate operation, like include or require
Oct 21 18:13:00 <Ulfalizer> "...anything in a bbclass could go directly into the recipe as well" was the last one
Oct 21 18:13:02 <kergoth> so right at that position would be ocrrect
Oct 21 18:13:10 <kergoth> what you put before vs after a bbclass can have an effect
Oct 21 18:13:24 * kergoth has always disliked this imperative vs declarative behavioral confusion
Oct 21 18:13:45 <Ulfalizer> so it's like an include/require, only with different look-up rules for the file?
Oct 21 18:14:18 <kergoth> inherit == require classes/<name>.bbclass + a bit of caching to avoid duplicate inherits, pretty much
Oct 21 18:14:37 <Ulfalizer> ok, that makes it much less magic :)
Oct 21 18:14:46 <Ulfalizer> +seem
Oct 21 18:14:49 <kergoth> also there's the handling of EXPORT_FUNCTIONS, which generates stubs to let you e.g. write 'autotools_do_configure' in autotools.bbclass, then EXPORT_FUNCTIONS do_configure will generate a do_configure that runs autotools_do_configure
Oct 21 18:15:02 <kergoth> this lets you then write a custom do_configure and manually call autotools_do_configure
Oct 21 18:15:25 <kergoth> basically our rigged together inheritence mechanism, like overriding a method in a subclass
Oct 21 18:15:52 * kergoth not entirely happy with how we implemented that either, but it is useful
Oct 21 18:16:21 <Ulfalizer> yeah, i remember asking about that a few days ago :)
Oct 21 18:20:00 <Ulfalizer> are configuration files parsed differently compared to recipes/classes?
Oct 21 18:20:22 <Ulfalizer> i guess disallowing python/shell functions might make sense there...
Oct 21 18:20:50 <Ulfalizer> but then again, maybe bitbake.conf has some code in it. can't remember...
Oct 21 18:20:54 <jmesmon> Ulfalizer: note that BBCLASSEXTEND has magic that makes it different from concatenation
Oct 21 18:21:21 <kergoth> yeah, there's two different parsers
Oct 21 18:21:47 <kergoth> scroll up, we went over bbclassextend a few minutes ago :)
Oct 21 18:22:20 <Ulfalizer> how do they differ? i guess most parts would be shared.
Oct 21 18:22:21 * jmesmon hides in shame
Oct 21 18:22:26 <Ulfalizer> :P
Oct 21 18:23:43 <Ulfalizer> nope, no code in bitbake.conf
Oct 21 18:23:59 <Ulfalizer> except ${@ stuff, but i'm not counting that
Oct 21 18:29:46 <kergoth> mainly inherit and functions/tasks are recipe specific
Oct 21 18:29:51 <kergoth>  / class specific
Oct 21 18:32:58 <Ulfalizer> what happens if you try to use them in configuration files? i still don't have a linux box due to the moving company being slow. :P
Oct 21 18:33:19 <Ulfalizer> not that it's hugely important to know
Oct 21 18:36:53 <kergoth> it'll just give a parsing error. unrecognized lines in teh file
Oct 21 18:37:01 <Ulfalizer> okay
Oct 21 18:37:04 <kergoth> the separation can be kind of irritating at times, actually
Oct 21 18:42:23 <Ulfalizer> how does it work internally? some kind of "context" variable and some checks on that when encountering a function/inherit?
Oct 21 18:42:45 <ulf`> wtf
Oct 21 18:42:48 <ulf`> Ulfalizer!
Oct 21 18:42:53 <ulf`> No one Ulfalizers me
Oct 21 18:42:59 <ulf`> ;)
Oct 21 18:44:17 <Ulfalizer> you should steal ulfenstein. i used to use that. :P
Oct 21 18:47:59 <kergoth> Ulfalizer: bitbake chooses which python file parser to use based on file extension. see bitbake/lib/bb/parse/parse_py/ConfHandler.py and the BBHandler
Oct 21 18:53:03 <Ulfalizer> probably excessive, but a small optimization there might be to assign the match() method directly, like __include_regexp_match__ = re.compile(...).match, and then __include_regexp_match__(s). i've written a parser for a configuration language in python, and i think that gained a few % on the runtime for me.
Oct 21 18:53:35 <Ulfalizer> but depends on where the bottleneck is. might be completely insignificant. :P
Oct 21 18:53:39 <kergoth> not a bad idea, woul dneed to profile
Oct 21 18:53:54 <kergoth> we have a lot of places we could improve performance, not sure if that part is significant or not
Oct 21 18:54:02 <kergoth> using regex in general isn't ideal
Oct 21 18:54:35 <Ulfalizer> i used a regex/manual mix in the end
Oct 21 18:55:54 <kergoth> the oe-lite folks wrote a PLY-based parser, but they've since changed the file format substantially, so couldn't use it as is
Oct 21 18:58:33 <kergoth> Any folks around that know git well? Could use input on https://bugzilla.yoctoproject.org/show_bug.cgi?id=7958#c13
Oct 21 18:58:34 <yocti> Bug 7958: enhancement, Medium, 2.1, kergoth, IN PROGRESS DESIGN , Implement shallow git clone functionality
Oct 21 20:03:54 <kergoth> Hmm, I don't really like that a failure to tar the git repo results in a "fetch error" and that cauess it to fall back to mirrors, which could end up doing the same steps that led to the first failure
Oct 21 20:04:03 <kergoth> would be nice if the mirror tarball generation was a separate operation
Oct 21 20:35:24 <rburton1> kergoth: g'wan, rewrite the fetcher
Oct 21 20:43:10 <kergoth> hmm, wonder if it'd be worth using platform.dist() rather than lsb_release for the native distro string
Oct 21 20:43:17 <kergoth> would avoid one host dependency
Oct 21 21:39:50 <clsulliv> parrot2: do you happen to have or can point to a beignet recipe I can use?
Oct 21 22:38:15 <tripzero1> anyone tried building poky (or similar) on ubuntu 15.10 yet?  I'm getting errors when compiling qemu-native
Oct 21 22:38:42 <tripzero1> "Error: User requested feature sdl configure was not able to find it.  Install sdl devel"
Oct 21 22:50:02 <kergoth> either install the sdl development packages, or edit local.conf and remove the qemu sdl lines
Oct 21 22:53:07 <tripzero> i've built libsdl-native
Oct 21 22:58:59 <tripzero> isn't that all qemu-native needs?
Oct 21 23:00:29 <kergoth> check the qemu documentation, i'd say
Oct 21 23:12:23 <tripzero> Odd that this error would suddenly pop-up after a distribution upgrade
Oct 22 01:39:47 <qknight> in my yocto image i can plug in a usb keyboard but /dev/input does not exist
Oct 22 01:40:01 <qknight> any idea if that is a udev problem or a kernel configuration problem?
Oct 22 01:40:51 <qknight> < >   Event interface
Oct 22 01:40:56 <qknight> ah, a kernel configuration issue
Oct 22 02:59:53 <parrot2> what does bb.utils.contains mean in  PACKAGECONFIG ??= "udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri dri2 dri3 glx', '', d)}" ?
**** ENDING LOGGING AT Thu Oct 22 02:59:58 2015