**** BEGIN LOGGING AT Thu Apr 23 02:59:59 2015
Apr 23 08:58:43 <bluelightning> morning all
Apr 23 09:01:01 <wv> Hello, how can I make sure everything gstreamer1.0-related is build in stead of gstreamer0.10?
Apr 23 09:16:29 <chankit> wv: you mean built as in just generating the package or including it inside the image?
Apr 23 09:21:31 <wv> both
Apr 23 09:21:40 <wv> well, I have this a recipe for an image
Apr 23 09:21:56 <wv> and as I remember it correct (it has been build a while ago) It said something like:
Apr 23 09:22:13 <wv> gstreamer0.10 build because it was requested later then gstreamer1.0 ...
Apr 23 09:22:16 <wv> something like that
Apr 23 09:22:25 <wv> don't know which package requires this gstreamer0.10
Apr 23 09:22:37 <wv> but I prefer all gstreamer1.0 related packages though...
Apr 23 09:32:18 <lpapp> good morning
Apr 23 09:33:46 <lpapp> bluelightning: why do I have kernel_3.2.1-r16_foo.ipk as well as kernel-3.2.1-r16_3.2.1-r16_foo.ipk? What is the difference?
Apr 23 09:34:35 <bluelightning> lpapp: I'm not sure
Apr 23 09:35:10 <bluelightning> that looks like something went wrong with the naming
Apr 23 09:35:56 <lpapp> possibly, yeah, one is emptier than the other.
Apr 23 09:36:55 <lpapp> bluelightning: perhaps this is because the naming changed between dylan and daisy?
Apr 23 09:41:44 <lpapp> it is not in the migration guide, so I would need to compare the line defining the pattern both in dylan and daisy
Apr 23 09:46:38 <lpapp> hmm, does not seem to have changed.
Apr 23 09:47:28 <kanupatar> hi guys
Apr 23 09:48:54 <kanupatar> hi guys, can anybody point me the u-boot,kernel and fs version coming with following releases? dylan,dora,daisy,dizzy,fido of yocto?
Apr 23 09:52:11 <LetoThe2nd> kanupatar: as this is highly dependent on the platform you are actually interested in, there's little use in naming numbers....
Apr 23 09:52:46 <kanupatar> I am havin arm arch for R-Car H2 board
Apr 23 09:52:52 <kanupatar> it is from Renesas
Apr 23 09:53:11 <LetoThe2nd> kanupatar: then look at the layer of the board that you use, and which revisions it uses for the releases.
Apr 23 09:53:42 <LetoThe2nd> kanupatar: the versions are usually defined by the board support package, not be the yocto release.
Apr 23 09:53:42 <kanupatar> LetoThe2nd: where can I see the releases?
Apr 23 09:54:40 <kanupatar> LetoThe2nd: sorry, where can I see man?
Apr 23 09:54:45 <LetoThe2nd> kanupatar: look into the board support package, and its recipes. like its recipes-bsp and recipes-kernel directories.
Apr 23 09:55:03 <kanupatar> LetoThe2nd: I am planning to dump all versions for my board
Apr 23 09:55:15 <kanupatar> this is for fast boot analysis
Apr 23 09:55:47 <kanupatar> LetoThe2nd: I need to download all versions right?
Apr 23 09:55:50 <LetoThe2nd> kanupatar: whatever, the answer is still the same over and over again: look into the board support package that you use.
Apr 23 09:55:52 <kanupatar> to check the folder?
Apr 23 09:56:15 <kanupatar> LetoThe2nd: May I know the revisions of yocto releases?
Apr 23 09:56:26 <LetoThe2nd> https://wiki.yoctoproject.org/wiki/Releases
Apr 23 09:56:51 <LetoThe2nd> naming versions of kernel/u-boot is totally pointless, so i just won't do it.
Apr 23 09:57:01 <kanupatar> LetoThe2nd: okay.
Apr 23 09:57:20 <kanupatar> LetoThe2nd: so, I need to download all releases from dylan
Apr 23 09:57:29 <kanupatar> LetoThe2nd: any links for that?
Apr 23 09:57:33 <LetoThe2nd> no, you need to look at your board support package
Apr 23 09:58:01 <LetoThe2nd> this is in absolutely no way related to whats in the packages provided by the yocto project
Apr 23 09:58:32 <LetoThe2nd> if you don't have the BSP, contact your vendor and/or documentation on how to get it
Apr 23 09:59:13 <kanupatar> LetoThe2nd: bsp comes in yocto?
Apr 23 09:59:17 <LetoThe2nd> no
Apr 23 09:59:31 <LetoThe2nd> please, read the documentation for your board.
Apr 23 09:59:57 <LetoThe2nd> talk to the person/vendor that gave it to you
Apr 23 10:00:29 <LetoThe2nd> those are technically obliged to give you the sources that have been used (if its running u-boot and linux)
Apr 23 10:00:37 <kanupatar> LetoThe2nd: I have the working yocto for dylan
Apr 23 10:00:50 <kanupatar> they given that
Apr 23 10:00:59 <LetoThe2nd> well then look at the recipes in the BSP
Apr 23 10:01:04 <kanupatar> but I need to update the revision
Apr 23 10:01:09 <LetoThe2nd> i don't get your problem, to be honest.
Apr 23 10:01:32 <kanupatar> LetoThe2nd: I have dylan branch of yocto working in board and I checked out it
Apr 23 10:01:56 <kanupatar> now, I am planning to check new versions of u-boot and kernel
Apr 23 10:02:19 <LetoThe2nd> kanupatar: and you certainly had to add *SOMETHING* to the official dylan download by the yocto project in oder to make it work, right?
Apr 23 10:02:28 <LetoThe2nd> kanupatar: so please look at that *SOMETHING*
Apr 23 10:02:31 <kanupatar> LetoThe2nd: yes yes
Apr 23 10:03:04 <kanupatar> is that meta-bsp?
Apr 23 10:03:11 <LetoThe2nd> and once you have looked at that *SOMETHING* and found your version numbers inside that *SOMETHING*, you can change them in that *SOMETHING*
Apr 23 10:03:25 <LetoThe2nd> its all in that *SOMETHING*, thats usually called a BSP
Apr 23 10:03:53 <kanupatar> LetoThe2nd: I though BSP is like u-boot,kernel and drivers
Apr 23 10:03:59 <kanupatar> *thought
Apr 23 10:04:01 <LetoThe2nd> those highly board specific things like kernel and u-boot are *NOT* defined by the yocto project, but by that BSP
Apr 23 10:04:27 <LetoThe2nd> kanupatar: yes so why don't you just look at your BSP and then change it to your needs?
Apr 23 10:04:47 <kanupatar> LetoThe2nd: let me check
Apr 23 10:05:01 <kanupatar> LetoThe2nd: thanks for your inpus
Apr 23 10:20:12 <lpapp> hmm, updating the kernel from package works, but flashing the image gets a stuck kernel... with the booting process
Apr 23 10:20:21 <lpapp> I wonder what the actually means in terms of recipe rules, etc.
Apr 23 11:36:44 <zaman> I am getting the warning "WARNING: [kernel]: An auto generated BSP description was used, this normally indicates a misconfiguration.
Apr 23 11:36:45 <zaman> Check that your machine (quark) has an associated kernel description."
Apr 23 11:39:07 <zaman> I have scc file as SRC_URI += "file://quark-standard.scc" with contents
Apr 23 11:39:50 <m0t0ro> hello everyone!
Apr 23 11:42:32 <m0t0ro> I'm having some trouble with the mraa and pwm with intel edison, maybe anyone could help me out?
Apr 23 12:27:30 <bluelightning> arfoll_: ^
Apr 23 12:36:06 <darkspike> hi guys, if i have a recipe called wayland_1.1.0.bb  and then i create my own layer and in it a recipe called wayland_1.4.0.bb would bitbake use the higher version one ?
Apr 23 12:36:40 <mimetonbo> hi guys, Im working on a yocto build on an ARM9 processor board
Apr 23 12:36:52 <mimetonbo> Anyone have embedded linux experience here?
Apr 23 12:37:27 <mimetonbo> Basically I want to use the onboard uart peripheral on the board. I need some pointers regarding that
Apr 23 12:39:33 <bluelightning> darkspike: assuming your layer has the same or higher layer priority, yes
Apr 23 12:39:49 <LetoThe2nd> mimetonbo: depending on the board and kernel revision, you'd either have to modify the the board file, the device tree file, or both
Apr 23 12:40:13 <mimetonbo> Well I have a vague idea of what you are saying
Apr 23 12:40:27 <mimetonbo> So the board file basically links the software to the hardware right?
Apr 23 12:40:42 <mimetonbo> and the device tree also does something similar right?
Apr 23 12:41:06 <LetoThe2nd> mimetonbo: very roughly, yes. thery both part of the kernel source
Apr 23 12:41:22 <darkspike> bluelightning: cool, thanks !
Apr 23 12:41:51 <LetoThe2nd> mimetonbo: so my basic outline would be 1) manually rebuild the kernel in use 2) motify, tinker, test 3) reinsert your changes into recipes
Apr 23 12:42:11 <mimetonbo> Leto: is there a way I can read both while the system is running? the current board file and device tree file
Apr 23 12:43:24 <LetoThe2nd> mimetonbo: nope
Apr 23 12:43:59 <LetoThe2nd> usually you can get the device tree, but certainly not the board file. the board file is ordinary c source.
Apr 23 12:44:05 <mimetonbo> hmm... well in the yocto source where can I find these files?
Apr 23 12:45:15 <LetoThe2nd> mimetonbo: not at all in the yocto sources.
Apr 23 12:45:33 <mimetonbo> oh well Im at my wits end
Apr 23 12:45:38 <LetoThe2nd> mimetonbo: first i guess you mean poky, or some bsp layer that you use.
Apr 23 12:45:56 <LetoThe2nd> in there are recipes that tell the build process how to build the kernel
Apr 23 12:46:05 <mimetonbo> yes
Apr 23 12:46:35 <LetoThe2nd> in the recipe that builds your kernel, there basically is the description where the kernel sources are obtained, and which patches are applied
Apr 23 12:46:55 <LetoThe2nd> mimetonbo: and these are the things to look at
Apr 23 12:47:22 <mimetonbo> hmm let me comprehend that a bit
Apr 23 12:47:41 <LetoThe2nd> mimetonbo: basically i'd suggest to have a thorough look at the yocto project kernel development manual, as it should explain the steps to modify the kernel pretty nicely
Apr 23 12:47:57 <mimetonbo> okay gotchya! thanks!
Apr 23 12:47:59 <mimetonbo> Im on it
Apr 23 12:55:20 <StMartin81> Hello,
Apr 23 12:55:28 <StMartin81> I've asked this question a few days ago on the general developer mailing unfortunately I didn't get any reply:
Apr 23 12:55:43 <StMartin81> The Yocto Project ADT Eclipse plugin preferences offers two options for choosing a cross compiler toolchain: "Standalone pre-built toolchain" and "Build system derived toolchain".
Apr 23 12:55:53 <StMartin81> When I select "Build system derived toolchain" after executing "bitbake meta-ide-support" I always get the error message "Specified toolchain directory does not contain a toolchain generated with "bitbake meta-ide-support"." no matter what directory I select.
Apr 23 12:55:59 <StMartin81> If I select "Standalone pre-built toolchain" the plugin seems to be happy.
Apr 23 12:56:07 <StMartin81> Now my question is if the "Build system derived toolchain" option is still valid and if so what the prerequisites are?
Apr 23 12:57:14 <LetoThe2nd> StMartin81: AFAIK, the build system dereived toolchain is meant for you if you actually have done the complety poky build proess, and want to use the toolchain that got generated in the course of that
Apr 23 13:01:12 <StMartin81> LetoThe2nd: You mean the toolchain which gets built when I execute "bitbake  <image name>"?
Apr 23 13:02:41 <LetoThe2nd> StMartin81: more like "bitbake <any kind of recipe that needs a cross toolchain>", but basically yes.
Apr 23 13:06:08 <StMartin81> LetoThe2nd: Ok, thanks!
Apr 23 13:08:33 <StMartin81> What's confusing me though is that the error message states that I should run "bitbake meta-ide-support" which will generate a toolchain which can be used with the "Standalone pre-built toolchain".
Apr 23 13:09:34 <LetoThe2nd> well according to what you said above, the message is correct, right?
Apr 23 13:09:54 <StMartin81> So my understanding is that if I have setup the poky build system on my computer I can simply select "Build system derived toolchain" so that Eclipse will use the same toolchain as bitbake is using.
Apr 23 13:10:18 <LetoThe2nd> again AFAIK, yes, thats the way its meant to be
Apr 23 13:14:43 <StMartin81> Ok, assume I build an image using "bitbake <my_image>". This should build a cross-toolchain which I want to use in Eclipse.
Apr 23 13:14:59 <StMartin81> Now, what directory would I need to select if I selected "Build system derived toolchain" and why is the error message mentioning that I should build a toolchain using "bitbake meta-ide-support"?
Apr 23 13:16:09 <LetoThe2nd> no idea, sorry. its been some time since i dabbled with that. and the ADT is maintained not too well at the moment, from what i've heard
Apr 23 13:17:33 <arfoll_> m0t0ro: move to #mraa
Apr 23 13:18:56 <StMartin81> Ok, thanks a lot! Considering the amount of information I've found during my search I was almost expecting that there is not too much interest in this plugin...
Apr 23 13:20:52 <ericbutters> hi.. i got: ERROR: QA Issue: No GNU_HASH in the elf binary -- this is with pre-build libs. how to solve?
Apr 23 13:26:21 <bluelightning> ericbutters: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-qa-checks
Apr 23 13:26:46 <bluelightning> ericbutters: in this instance if the libs are built outside of our build system, you'd probably use INSANE_SKIP to disable the check
Apr 23 13:30:18 <ericbutters> bluelightning: i did: INSANE_SKIP_${PN} += "ldflags" -- but same errors
Apr 23 13:31:39 <bluelightning> ericbutters: is ${PN} the specific package in which those files are included?
Apr 23 13:32:32 <ericbutters> bluelightning: i added  INSANE_SKIP_${PN} to the recipe that installs/packages the files
Apr 23 13:33:19 <bluelightning> ericbutters: yes, I get that, but if those files are not in the main package for the recipe (i.e. ${PN}) then that would explain why adding ldflags to INSANE_SKIP_${PN} would not disable the warning...
Apr 23 13:34:05 <bluelightning> in that case you would need to specify the package they were in fact in instead of ${PN} in that statement
Apr 23 13:44:35 <ericbutters> bluelightning: i am still wondering why it is not working, but btw, i also do INHIBIT_PACKAGE_STRIP = "1" and there is a packages-split/ generated containing targetfs-genivi-dbg/ -> but i also set INHIBIT_PACKAGE_DEBUG_SPLIT = "1" ?!
Apr 23 13:45:47 <ericbutters> the recipe ($PN) i set this is doing do_fetch do_unpack and do_install and simple unpack and install pre-build rootfs
Apr 23 13:46:11 <bluelightning> ericbutters: we are considering packages at this point, not the recipe
Apr 23 13:46:48 <bluelightning> ericbutters: INHIBIT_PACKAGE_DEBUG_SPLIT = "1" doesn't stop the -dbg package existing, just whether or not the symbols get split out to that package
Apr 23 13:48:05 <bluelightning> ericbutters: the files that the GNU_HASH warning is complaining about - which directory do they appear in under packages-split ?
Apr 23 13:48:33 <ericbutters> bluelightning: -dev
Apr 23 13:48:58 <bluelightning> ericbutters: right, then you would need to do INSANE_SKIP_${PN}-dev += "ldflags" in that case
Apr 23 13:53:18 <ericbutters> bluelightning: yes, thanks! that solved it.. but i got one more: ERROR: QA Issue: my-package: Files/directories were installed but not shipped -- as i said i got a total rootfs, in packages-split/my-package i only see a subset of that rootfs
Apr 23 13:53:26 <ericbutters> so do i need to set FILES?
Apr 23 13:55:03 <bluelightning> ericbutters: either set/add to FILES_<package> to add those files to a package, or avoid them being installed in the first place, or delete them within do_install, whichever is appropriate
Apr 23 13:57:12 <ericbutters> bluelightning: i need them all, i just want bitbake to generate a roofs out of a pre-built rootfs. so i would need to set/add to FILES_<package>
Apr 23 13:59:35 <bluelightning> ericbutters: right yes
Apr 23 14:03:31 <ericbutters> bluelightning: i got everything in the package/ folder, but not in the packages-split/my-package -- so i tried: FILES_${PN} += "${PKGD}/*"
Apr 23 14:03:45 <ericbutters> is ${PKGD} correct?
Apr 23 14:06:01 <bluelightning> ericbutters: no, because you're now specifying the path on the host, FILES refers to the path as it would appear on the target
Apr 23 14:06:44 <bluelightning> ericbutters: for the hack you are doing you probably want to set PACKAGES = "${PN}" as well
Apr 23 14:07:03 <bluelightning> ericbutters: you're aware you are going to have problems if any of the packages install conflicting files, right?
Apr 23 14:07:47 <bluelightning> in fact I suspect it may make this approach unworkable
Apr 23 14:09:49 <ericbutters> bluelightning: okay, thanks. what would you suggest? any idea you can share would be nice :) -- btw, PACKAGES = "${PN}" did not work
Apr 23 14:10:15 <bluelightning> ericbutters: you can't package an entire rootfs with conflicting files
Apr 23 14:11:35 <bluelightning> ericbutters: I'm guessing you'd need to do something like merge the old rootfs into the new one at the end of image construction, because doing it before is going to lead to similar issues where the package manager isn't expecting files to exist
Apr 23 14:12:56 <bluelightning> to be honest thinking about doing this makes me feel somewhat ill...
Apr 23 14:13:35 <ericbutters> bluelightning: my goal is to use yocto/bitbake without compiling any source, just use a pre-build rootfs and then copy binaries, header, config etc out of svn into this and let bitbake generate a rootfs out of it
Apr 23 14:13:50 <ericbutters> bluelightning: ;)
Apr 23 14:13:53 <bluelightning> ericbutters: yes, I recall the discussion from the other day
Apr 23 14:13:59 <ericbutters> right
Apr 23 14:14:11 <bluelightning> it's just not a route I would ever choose to go down myself
Apr 23 14:14:24 <ericbutters> i know
Apr 23 14:16:01 <LetoThe2nd> bluelightning: ++
Apr 23 14:16:33 <LetoThe2nd> souds androidish... grab some stuff, put binary blobs inside, ship it ;)
Apr 23 14:23:35 <kergoth> you probably *could* package an entire rootfs in a recipe, or most of one, but if you build anything else, you'd have to have it PROVIDES everything it really provides, to avoid the conflicts bluelightning mentions. possible, not pretty, and not sure using bitbake in such a case even buys you much
Apr 23 14:23:36 * kergoth yawns
Apr 23 14:23:56 <bluelightning> kergoth: right, it's not impossible, just painful
Apr 23 14:24:04 <bluelightning> but then the whole thing is likely to be painful
Apr 23 14:24:38 <bluelightning> morning kergoth :)
Apr 23 14:25:55 <kergoth> morning
Apr 23 14:37:18 <danielpavel> Hello, I'm trying to find out what exact params are passed to uboot-mkimage during yocto build. I checked out logs (build/tmp/logs) and there's no output that can gives me the info i need. I'm trying about the task do_uboot_mkimage from kernel.bbclass. Is there a way to find out something about that ?
Apr 23 14:37:48 <danielpavel> I'm talking *
Apr 23 14:49:29 <kergoth> just add set -x to the top of the task and look at the task log
Apr 23 15:07:33 <ericbutters> QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so
Apr 23 15:10:28 <kergoth> you should probalby just disable all qa tests, given the hack you're doing
Apr 23 15:10:35 <kergoth> INSANE_SKIP_${PN} = "1"
Apr 23 15:10:36 <bluelightning> yes
Apr 23 15:10:54 <bluelightning> I suspect INSANE_SKIP_${PN} = "1" won't actually do anything
Apr 23 15:10:55 <ericbutters> ok
Apr 23 15:11:24 <kergoth> oh, right, that's the one for specific tests, ignore me
Apr 23 15:11:26 <kergoth> insufficient caffeine
Apr 23 15:11:48 <joshuagl> any c++/cmake savvy folks in here? I'm trying to build a large piece of software which uses CMake and getting a bunch of failures like "fatal error: cstdlib:" - if I edit the .flags files by hand to add -isystem /srv/build/geh/tmp/sysroots/qemux86/usr/include/c++/4.9.2/
Apr 23 15:11:55 <joshuagl> things start to proceed
Apr 23 15:12:21 <joshuagl> that should be "fatal error: cstdlib: No such file or directory"
Apr 23 15:12:41 <bluelightning> joshuagl: is the sysroot being specified?
Apr 23 15:13:06 <ericbutters> so how to disable all qa tests?
Apr 23 15:13:19 <joshuagl> bluelightning: oh, no it isn't :-/
Apr 23 15:14:13 <bluelightning> ericbutters: I don't believe we have an actual option for that, having never deemed it a good idea... I would guess you could stub out do_package_qa() but I can't guarantee that will work
Apr 23 15:14:53 <ericbutters> ok
Apr 23 15:16:55 <joshuagl> bluelightning: any ideas how that might have been removed?
Apr 23 15:17:16 <bluelightning> joshuagl: not sure, maybe it's simply not using CC / CXX
Apr 23 15:17:28 <bluelightning> since those have the --sysroot option specified
Apr 23 15:18:47 <joshuagl> bluelightning: pro tip, thanks
Apr 23 15:23:47 <kergoth> ericbutters: presumably you could empty ERROR_QA and WARN_QA in the recipe. normally those are distro policy, as to what to do when qa problems occur, but you could probably set it in the recipe to silence them all
Apr 23 15:23:59 <kergoth> untested, obviously
Apr 23 15:28:47 <ericbutters> kergoth: i overwrite do_package_qa .. that worked.. it is all hacking for that approach, but i have to try this.. now i got the rpm in deploy-rpm, but baking my target image will use/install it?!
Apr 23 15:29:16 <ericbutters> will *not* ^
Apr 23 15:30:17 <ericbutters> i only get a subset in rootfs/ folder of the package
Apr 23 15:37:49 <joshuagl> bluelightning: that was it, my hero!
Apr 23 15:41:10 <bluelightning> joshuagl: \o/
Apr 23 16:04:32 <T0mW> I've built a sato image on Daisy, matchbox comes up on the LCD, a mouse is available on /dev/psaux.  When I cat /dev/psaux I see mouse data.  However, the desktop does not see the mouse.  I tried linking /dev/psaux to /dev/mouse, but no mouse movement in matchbox.
Apr 23 16:04:47 <T0mW> No docs, as yet, on Yocto regarding the mouse.
Apr 23 16:04:53 <T0mW> suggestions?
Apr 23 16:20:36 <bluelightning> T0mW: I guess this is a generic X11 configuration issue, it's not something specific to us
Apr 23 16:20:50 <T0mW> bluelightning: thanks
Apr 23 18:43:56 <lpapp> B = "${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build" -> B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build" -> so this apparently changed?
Apr 23 19:00:07 <lpapp> kergoth: are you around?
Apr 23 19:00:38 <lpapp> kergoth: would it be possible that our forked kernel recipe would not work that well with daisy as it worked with dylan? I am still trying to figure out the root cause of the kernel boot issue.
Apr 23 19:00:57 <lpapp> and it is certainly not an image generation problem as updating the kernel from package also breaks.
Apr 23 19:01:37 <lpapp> I am just trying to make sure that our "old" recipe, which is just a slightly customized version of the meta-yocto kernel for the time is still OK with the daisy rules. If that is true, I am afraid that the only issue could be toolchain related.
Apr 23 19:04:33 <kergoth> Yeah, the kernel build process changed somewhat. the source tree and build dir are both in the sysroot now. it's possible, it depends on what all the recipe is doing
Apr 23 19:04:54 <lpapp> hmm, I was just about to paste our recipe for introspection.
Apr 23 19:05:37 * kergoth honestly isn't 100% on the kernel build changes, never read the commits
Apr 23 19:06:49 * paulg_ would be very surprosed of the work-shared changes could result in a bzImage that somehow was corrupted and unbootable.
Apr 23 19:07:05 <paulg_> surprised, even.
Apr 23 19:08:21 <lpapp> kergoth: paulg_ https://paste.kde.org/p1xklmakq
Apr 23 19:10:41 <lpapp> anything suspicious? This was working fine with dylan.
Apr 23 19:13:56 <paulg_> I'm missing way too much context to even try to attempt to understand what you are trying to do here.
Apr 23 19:15:02 <paulg_> like why are  you gluing an ancient 3.2 kernel into a modern yocto.
Apr 23 19:15:16 <kergoth> he's taking a kernel recipe from dylan which worked, pulled it forward to the nxt release, and his kernel isn't booting. i suggested the most likely cause was something miscompiled with the new toolchain
Apr 23 19:15:19 <kergoth> 3.2? yikes
Apr 23 19:15:35 <paulg_> yep, my thought exactly.
Apr 23 19:16:59 <paulg_> lpapp, the quick check is to compare the .config for both old and "new" -- assuming your kernel version is the same  for each.   And check what branch / head commit was built
Apr 23 19:17:38 <paulg_> if you have the same src and the same .config (and same dts/dtb, if applicable) then you are kind of down to the toolchain at that point.
Apr 23 19:18:38 <lpapp> as you can see we ship our configs.
Apr 23 19:19:09 <lpapp> so unless there are incompatible changes, which I doubt in kernel land, it oughto to be comparably equal or at least very similar.
Apr 23 19:19:36 <lpapp> the reason for 3.2 is not relevant here, but it is that we do not have enough resource nor expertise to update our huge changes on top of a new kernel version.
Apr 23 19:20:10 <paulg_> ok, so let me rewind here a bit to fill in whatever discussion I missed.
Apr 23 19:20:17 <lpapp> most of the extra 20K changes would not apply against the new kernel and the changes are really not upstreamable, nor do we have the time and money in this small company to make it so.
Apr 23 19:20:34 <lpapp> sadly.
Apr 23 19:20:37 <paulg_> a) on both the failing newer yocto, and the older working yocto, the same 3.2 source was used, correct?
Apr 23 19:21:01 <lpapp> yes, as you can see it is verbatim in our meta-foo
Apr 23 19:21:04 <lpapp> our layer has not changed.
Apr 23 19:21:19 <lpapp> meta/, scripts/, and bitbake/ has changed
Apr 23 19:21:29 <lpapp> and the .tempconfig or how it is called in the root coming from Yocto again.
Apr 23 19:22:41 <paulg_> yeah, forget all that and go right to the .config of the kernel build.
Apr 23 19:24:12 <lpapp> as in?
Apr 23 19:24:51 <lpapp> so as you can see on the pastebin site, we have this ./meta-foo/recipes-kernel/linux/linux-foo-3.2.1/defconfig. That is the configuration that is also carried on.
Apr 23 19:24:56 <paulg_> well, I've NFI what board you are using, etc, but with the x86 stuff I'm poking at currently, and with the yocto-dev kernel, it would be here:
Apr 23 19:25:19 <paulg_> build/tmp/work/genericx86_64-poky-linux/linux-yocto-dev/3.19++gitAUTOINC+eaceb64585_31b35da6a5-r0/linux-genericx86_64-standard-build
Apr 23 19:25:26 <paulg_> the .config in that dir
Apr 23 19:25:57 <lpapp> it is coming from ./meta-foo/recipes-kernel/linux/linux-foo-3.2.1/defconfig.
Apr 23 19:26:01 <lpapp> it is preconfigured and saved.
Apr 23 19:26:05 <lpapp> and then applied as a patch.
Apr 23 19:26:11 <paulg_> yours will be tmp/work/<arch-mumble>/linux-yocto/....
Apr 23 19:26:15 <lpapp> you can also see that in my recipe.
Apr 23 19:26:40 <paulg_> doesn't matter where it is sourced from etc.  -- only thing that counts is the final .config in that build dir
Apr 23 19:27:11 <paulg_> only by comparing the final two .config (working and non-working) will you be able to rule out a mangled config due to processing changes.
Apr 23 19:27:30 <lpapp> okay, thanks, I am vimdiffing them now.
Apr 23 19:29:40 <lpapp> paulg_: I need to rebuild the kernel packages, I think
Apr 23 19:29:45 <lpapp> as I have used rm_work
Apr 23 19:30:24 <paulg_> and that is a possibility, since use of defconfigs is actively discouraged vs. the normal workflow of config fragments, so it is possible that defconfigs inadvertently got handled differnetly
Apr 23 19:30:24 <paulg_> imagine for example your config lost its uart settings -- instant silent boot death.
Apr 23 19:31:17 <lpapp> but config fragments are difficult to grasp for me.
Apr 23 19:31:37 <lpapp> hmm, bitbake linux-foo did not regenerate the .config file.
Apr 23 19:31:38 <lpapp> I wonder why.
Apr 23 19:31:45 <lpapp> do I need to clean first?
Apr 23 19:31:58 <lpapp> I just removed rm_work and I thought that ought to be enough to repopulate it.
Apr 23 19:32:13 * lpapp is doing bitbake -c clean linux-foo
Apr 23 19:32:50 <paulg_> cleanall or cleansstate perhaps...
Apr 23 19:33:14 <lpapp> hmm, I only have got: ./tmp/work/foo-linux-gnueabi/linux-foo/3.2.1-r16/sysroot-destdir/usr/src/kernel/.config
Apr 23 19:33:43 <lpapp> which is probably the right one, just after population the sysroot.
Apr 23 19:33:56 <lpapp> anyway, I am doing -c cleanall as you were hinting that above.
Apr 23 19:47:29 <lpapp> paulg_: zero difference according to the vimdiff output
Apr 23 19:47:32 <lpapp> next thing to check?
Apr 23 19:47:44 <lpapp> they are equal bit-by-bit.
Apr 23 19:48:58 <lpapp> I guess I could also unpack the .ipk packages and make some binary compare?
Apr 23 19:51:51 <paulg_> lpapp, did you confirm both are building from the same source?
Apr 23 19:52:04 <paulg_> again, don't just assume so from recipe X and bb Y.
Apr 23 19:52:16 <lpapp> hmm?
Apr 23 19:52:23 <paulg_> go in the build dir and  check
Apr 23 19:52:26 <tlwoerner_> lpapp: as an aside, you can leave 'INHERIT += "rm_work"' and then just selectively turn off rm_work for given recipes using RM_WORK_EXCLUDE
Apr 23 19:52:28 <lpapp> the source is equally the same, yes.
Apr 23 19:52:40 <paulg_> see what git branch is checked out, see what commit is the top commit.
Apr 23 19:52:48 <lpapp> tlwoerner_: yeah, I think bluelightning mentioned that yesterday to me, thanks.
Apr 23 19:53:27 <lpapp> paulg_: that is the same.
Apr 23 19:53:28 <paulg_> and after you've done that, check dts/dtb if you are using one.
Apr 23 19:53:57 <lpapp> I do not.
Apr 23 19:54:00 <paulg_> and finally are the resulting vmlinux/bzImage files comparable size
Apr 23 19:55:11 <lpapp> from which location are you suggesting to compare them?
Apr 23 19:55:42 <paulg_> right in the build dirs ; don't be looking at possibly stale stuff in tmp/deploy/images
Apr 23 19:55:59 <paulg_> same place where the .config files where that you compared.
Apr 23 19:56:14 <paulg_> s/where/were/
Apr 23 19:56:25 <paulg_> s/where/were/2
Apr 23 19:57:15 <lpapp> both are 5.7 MB
Apr 23 19:57:18 <lpapp> vmlinux, that is.
Apr 23 19:58:21 <lpapp> does that count as comparable size?
Apr 23 20:04:18 <lpapp> paulg: ^
Apr 23 21:20:36 <chrgrff1> I'm trying to build a Qt5 project with bitbake for deployment and SDK for development; in SDK, QT_SYSROOT isn't set but I have OECORE_TARGET_SYSROOT environment variable. In bitbake, QT_SYSROOT is set but OECORE_TARGET_SYSROOT is not. Is there one location the target sysroot is defined that I can reference in both cases?
Apr 23 23:21:20 <kergoth> So, the problem where my ncurses is owned by the build user can be reproduced with a poky build, but only for ipk. rpm doesn't encounter the problem
Apr 23 23:54:52 <kergoth> confirmed, rebuilt it from scratch, the behavior with ipk is substantially different than with rpm. interesting
**** ENDING LOGGING AT Fri Apr 24 02:59:59 2015