**** BEGIN LOGGING AT Mon Apr 20 02:59:58 2015
Apr 20 05:59:59 <miandonmenmian> how can i get detailed info from a recipe using bitbake? or i need bitbake-layers?
Apr 20 06:11:38 <AndersD> miandonmenmian, what are you looking for? Does `bitbkae -e <recipe-name>`shou what you need?
Apr 20 06:45:19 <miandonmenmian> AndersD: wow, thanks. i suppose somewhere there has to be. I'm trying to locate the .bb file and location for the python stack. would like to add some more dependencies to python and want to see how the current ones are done
Apr 20 07:25:46 <AndersD> Well, usually I end up being lazy and run find to locate the bb-file (or look at the history in git to find the path).
Apr 20 07:31:57 <mckoan> good morning
Apr 20 08:12:34 <bluelightning> morning all
Apr 20 08:59:27 <jaz303> hello
Apr 20 09:00:19 <jaz303> how would I go about creating an SD card image that includes a UBI image?
Apr 20 09:01:14 <jaz303> at the moment I'm flashing the SD card myself and then mounting the rootfs and copying in the UBI image + all the supporting scripts
Apr 20 09:02:02 <jaz303> i have a dive through the python oe.image module but was a bit out of my depth
Apr 20 09:02:06 <jaz303> *had
Apr 20 09:05:06 <ant_work> jaz303: why would you use UBI on an SD?
Apr 20 09:05:09 <diego_r> Hi everybody. Can anybody help me understand what variable FEED_DEPLOYDIR_BASE_URI is supposed to do? I'm using ipk package format and opkg package manager. I expected to find an additional conf file under /etc/opkg/ but no additional file has been placed there after bitbaking
Apr 20 09:05:41 <ant_work> jaz303: is it to be flashed on nand/nor ?
Apr 20 09:05:49 <jaz303> ant_work: i want my users to be able to boot from the SD and if they like it they can flash it, yes
Apr 20 09:07:00 <ant_work> ah, ok, thne I se
Apr 20 09:07:06 <ant_work> argh..
Apr 20 09:07:10 <ant_work> ah, ok, then I see
Apr 20 09:12:41 <ant_work> iirc there are some layers handling complex SD images, if I'm not wrong meta-fsl-arm
Apr 20 10:24:22 <lpapp> good morning
Apr 20 10:24:41 <lpapp> when migrating to Daisy from Dylan, I can see this, but nothing in the migration guide: WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly
Apr 20 10:24:56 <lpapp> this is the only entry in the migration guide: libpam: Deny all services for the OTHER entries.
Apr 20 10:29:38 <bluelightning> lpapp: somewhere a dependency on libpam exists that is not conditional on pam being in DISTRO_FEATURES; you should find it and eliminate it
Apr 20 10:30:17 <lpapp> it is probably our software, but pam is not option for that.
Apr 20 10:31:02 <bluelightning> if by that you mean it's required, then you should add pam to your DISTRO_FEATURES value
Apr 20 10:31:38 <joshuagl> wk
Apr 20 10:36:25 <mckoan> I've a couple of questions about 'dizzy'
Apr 20 10:36:56 <mckoan> the command 'hystory' is no longer available on generated fs, what's missing?
Apr 20 10:37:22 <mckoan> the 'opkg-target' command is no longer generated in minimal-image, what's missing?
Apr 20 10:39:28 <lpapp> bluelightning: ok, thanks; interesting that this transition step is not documented.
Apr 20 10:39:36 <lpapp> or I may be missing something.
Apr 20 10:40:14 <bluelightning> lpapp: it's not that we added a new requirement, we probably just added a check, the issue was probably always there
Apr 20 10:41:33 <lpapp> still, it could have been put in there.
Apr 20 10:42:32 <lpapp> so this will do it? DISTRO_FEATURES_append = " largefile --disable-zlib pam"
Apr 20 10:44:29 <diego_r> sorry if I ask again, but maybe not everybody read. Can anybody help me understand what variable FEED_DEPLOYDIR_BASE_URI is supposed to do? I'm using ipk package format and opkg package manager. I expected to find an additional conf file under /etc/opkg/ but no additional file has been placed there after bitbaking my image
Apr 20 10:45:44 <mckoan> I mean, are those removed features in 'dizzy' ?
Apr 20 10:50:16 <bluelightning> lpapp: er, --disable-zlib doesn't belong in there
Apr 20 10:50:19 <bluelightning> lpapp: otherwise, yes
Apr 20 10:50:25 <lpapp> why?
Apr 20 10:50:33 <bluelightning> because nothing will check for that?
Apr 20 10:50:41 <lpapp> so why is it in there?
Apr 20 10:50:59 <bluelightning> I'm not sure, it's your line that's adding it
Apr 20 10:51:25 <bluelightning> could be that somewhere a check was added for it in your custom metadata, but I wouldn't have thought so
Apr 20 11:11:37 <lpapp> bluelightning: hmm, it was not used even at the denzil era?
Apr 20 11:12:09 <bluelightning> lpapp: no, we wouldn't use that syntax in DISTRO_FEATURES
Apr 20 11:14:19 <lpapp> ok :)
Apr 20 11:14:21 <lpapp> thanks.
Apr 20 11:25:33 <JYDawg> hullo
Apr 20 11:28:07 <JYDawg> is there a parser for bitbake recipes that allows me e.g. to get the dump as a dictionary in python?
Apr 20 11:28:29 <JYDawg> or the entire layer for that matter
Apr 20 11:33:07 <LetoThe2nd> JYDawg: hm, the information you're looking for might already be contained in bitbake -e
Apr 20 11:33:10 <rink_> you can try 'bitbake -e <receipe>'
Apr 20 11:33:22 <LetoThe2nd> can be spammy, though :)
Apr 20 11:33:48 <JYDawg> oke
Apr 20 11:34:04 <JYDawg> lessee
Apr 20 11:34:15 <rink_> but it depends on what you need
Apr 20 11:37:37 <JYDawg> we have several developers in the same layers and I'd like to be able to make sure they increase the package versions where needed. The other issue is that I'd like to be able to make package patches from builds but thats another item.
Apr 20 11:39:34 * rink_ never increments package versions when adding patches and stuff... it's amazing how well the dependency tracking in bitbake works
Apr 20 11:44:37 <JYDawg> buildserver has a load of 55. This may take a while
Apr 20 11:45:27 <JYDawg> does bitbake have a python lib backend or sumsuch?
Apr 20 12:03:28 <RP> JaMa: thanks for the reminder about the fontconfig patch. I want to talk to rburton about it and check his concern was addressed but will merge as soon as I can to do (or give feedback)
Apr 20 12:04:02 * RP really needs to get a better process around this...
Apr 20 12:07:58 <bluelightning> JYDawg: there is "tinfoil" that allows accessing some of the internals e.g. parsing
Apr 20 12:09:23 <bluelightning> JYDawg: here's an example of using it: https://gist.github.com/bluelightning/6138980
Apr 20 12:17:59 <miandonmenmian> i've got a layer working, where can i set distro params on my layer to override current default ones?
Apr 20 12:20:23 <bluelightning> miandonmenmian: add a conf/distro/yourdistroname.conf with the settings you want, and then set DISTRO = "yourdistroname" in conf/local.conf
Apr 20 12:20:35 <bluelightning> miandonmenmian: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution
Apr 20 12:21:59 <miandonmenmian> bluelightning: thanks a bunch. i've also had some trouble setting maintainer on per package basis. isnt it suposed to be MAINTAINER= " " on the .bb ?
Apr 20 12:23:28 <bluelightning> miandonmenmian: where are you expecting the MAINTAINER value to show up?
Apr 20 12:23:44 <miandonmenmian> on opkg
Apr 20 12:26:05 <lpapp> bluelightning:  ELF binary '<file>' has relocations in .text [textrel] from here: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html -> What would be the solution suggested? -fPIC/-fpic or something else?
Apr 20 12:26:47 <bluelightning> miandonmenmian: well, near as I can tell, setting it in the recipe should affect any packages produced; it may be that just changing MAINTAINER doesn't trigger do_package to re-execute though, I'm not sure
Apr 20 12:27:50 <bluelightning> lpapp: I believe so yes
Apr 20 12:28:31 <lpapp> bluelightning: could be put into the document as a hint, no?
Apr 20 12:29:44 <bluelightning> lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-textrel could be extended yes
Apr 20 12:32:46 <lpapp> ok, thanks
Apr 20 12:34:25 <JaMa> RP: thanks
Apr 20 12:35:31 <bluelightning> lpapp: thanks for filing, i can remove that from my todo list now ;)
Apr 20 12:35:42 <JaMa> RP: this one is only 1 week old, but also didn't get any feedback (nor is in master-next) http://lists.openembedded.org/pipermail/openembedded-core/2015-April/103684.html
Apr 20 12:41:49 <lpapp> bluelightning: :D np.
Apr 20 12:53:48 <JYDawg> bluelightning: nice, starting to look a lot like what I need.
Apr 20 12:55:16 <lpapp> bluelightning: I am getting some strange warnings, https://paste.kde.org/proplo3gj
Apr 20 12:56:27 <RP> JaMa: didn't see that one for some reason. Have replied suggesting a minor tweak to the naming
Apr 20 12:56:56 <bluelightning> lpapp: there was a regression a while ago where we now expect everything added to ROOTFS_POSTPROCESS_COMMAND to be a function rather than a plain command
Apr 20 12:57:52 <miandonmenmian> bluelightning: followed the process, seems the layer is found alltogether with packages, that individually do well. however, image is not. set the distro as per the guide link you shared didnt work for me. do i need to refresh the cache for the distro to appear?
Apr 20 12:57:59 <bluelightning> lpapp: I suppose we should probably fix it, but then again using functions is generally a better way to structure things there
Apr 20 12:59:05 <bluelightning> miandonmenmian: what exactly is failing? I'm not quite following...
Apr 20 12:59:37 <miandonmenmian> bitbake mydistro does not exist
Apr 20 13:00:02 <bluelightning> miandonmenmian: that isn't generally expected to work
Apr 20 13:00:08 <lpapp> bluelightning: should probably also be documented in the migration guide?
Apr 20 13:00:34 <miandonmenmian> not expected to work as in will have problems? or as in nothing will happen?
Apr 20 13:00:35 <bluelightning> miandonmenmian: a distro is a set of configuration values that you can select through DISTRO, it's not a target you can build
Apr 20 13:01:03 <bluelightning> miandonmenmian: what I suspect you want in addition is to define a custom image recipe containing the packages you want
Apr 20 13:01:26 <bluelightning> lpapp: well, not if it's a bug that we should fix, no
Apr 20 13:02:46 <miandonmenmian> bluelightning: BBFILE_COLLECTIONS ?
Apr 20 13:03:45 <miandonmenmian> does that refer to the set of configuration for the distro? or i need to look for this inside the distro.conf file?
Apr 20 13:04:13 <miandonmenmian> bluelightning: ok, i will take a look at your second suggestion, seems like that is exactly what i need
Apr 20 13:04:51 <bluelightning> miandonmenmian: if you haven't already seen it - http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage
Apr 20 13:05:59 <lpapp> bluelightning: is it a bug or feature? ^_^
Apr 20 13:06:10 <lpapp> either way, report is neded for either? Is there one already to fix this regression?
Apr 20 13:07:04 <bluelightning> lpapp: it seems like a regression to me, if you could file a bug that would be great
Apr 20 13:25:01 <lpapp> bluelightning: submitted, thanks.
Apr 20 13:30:10 <LongQi> can the target Runtime Package Management install .deb or .rpm from existed distribution repository?
Apr 20 13:31:24 <LongQi> if they have same CPU architecture.
Apr 20 13:31:54 <LongQi> or we must build our own repository?
Apr 20 13:36:30 <mckoan> the history command is still present but the list of commands is not persistent, how can I enable it?
Apr 20 13:46:52 <miandonmenmian> i'm building a package that installs a file, without do_compile. the file is located on the recipe/files and im calling it with SRC_URI = "file://myfile"
Apr 20 13:47:17 <miandonmenmian> install -m 644 ${WORKDIR}/myfile ${D}/usr/lib/myDestinationFolder
Apr 20 13:47:28 <miandonmenmian> is this wrong? my package is built empty
Apr 20 13:47:33 <lpapp> bluelightning: it does not matter whether it is a python or bash function?
Apr 20 14:00:45 <bluelightning> lpapp: that is one of the things we gained in exchange for the regression, yes
Apr 20 14:02:16 <lpapp> bluelightning: how can I assign a function to a variable?
Apr 20 14:02:28 <lpapp> is there an example somewhere?
Apr 20 14:02:47 <lpapp> just pass the function name along?
Apr 20 14:02:47 <bluelightning> miandonmenmian: you will need to add that path to FILES_${PN} i.e. FILES_${PN} += "${libdir}/myDestinationFolder" (and use ${libdir} rather than /usr/lib in your install command
Apr 20 14:03:07 <bluelightning> lpapp: ROOTFS_POSTPROCESS_COMMAND is still semicolon-separated, that hasn't changed
Apr 20 14:03:45 <lpapp> so the function names separated by semicolon?
Apr 20 14:04:15 <bluelightning> yes
Apr 20 14:04:21 <lpapp> thank you very much
Apr 20 14:10:32 <miandonmenmian> bluelightning: add the file to path for the do_install function ?
Apr 20 14:10:53 <bluelightning> miandonmenmian: no, outside of it
Apr 20 14:12:22 <bluelightning> miandonmenmian: assuming you were asking where to put this FILES_${PN} line
Apr 20 14:13:06 <miandonmenmian> yes, that is right, sorry. However, i am not sure I understand it:
Apr 20 14:13:41 <miandonmenmian> the source SRC_URI += "file://myfile" assumes the recipe folder?
Apr 20 14:14:23 <miandonmenmian> i was worried the file was lost on {WORKDIR} since there are no other sources. perhaps the line should be SRC_URI =
Apr 20 14:14:24 <bluelightning> miandonmenmian: myfile should be placed in a directory next to the recipe, named either the same as the recipe, or "files"
Apr 20 14:14:56 <miandonmenmian> bluelightning: ok, well, at least got that right :S
Apr 20 14:17:49 <miandonmenmian> somehow, on verbose, bitbake is still looking for sstate folder sources
Apr 20 14:18:02 <miandonmenmian> package is built empty
Apr 20 14:19:04 <bluelightning> miandonmenmian: something is still wrong with your FILES line then, it's not matching up
Apr 20 14:20:13 <bluelightning> miandonmenmian: just checking, are you using Toaster or oe-init-build-env-memres?
Apr 20 14:20:35 <miandonmenmian> oe-init-build-env
Apr 20 14:21:28 <bluelightning> miandonmenmian: would you be prepared to pastebin your recipe?
Apr 20 14:21:47 <miandonmenmian> should've done that before. sorry. give me a sec
Apr 20 14:25:53 <miandonmenmian> bluelightning: http://apaste.info/4mh
Apr 20 14:31:01 <bluelightning> miandonmenmian: you need an install -d command to create the ${D}${libdir}/python-2.7 directory
Apr 20 14:31:32 <bluelightning> miandonmenmian: also you should be doing FILES_${PN} += not = (although that won't make much difference in this case, but it's good practice)
Apr 20 14:31:37 <miandonmenmian> bluelightning: tried that as well. however, another package should be bcreating this directory
Apr 20 14:32:07 <bluelightning> miandonmenmian: doesn't matter, this recipe builds in isolation as far as the install step is concerned
Apr 20 14:32:39 <miandonmenmian> i'm reading another doc that adds the asterisk at the end for the FILES line.  ${libdir}/lib*.so.* \   does the myfile have to be included here? or just the path ?
Apr 20 14:32:49 <bluelightning> miandonmenmian: the path is sufficient
Apr 20 14:33:29 <bluelightning> miandonmenmian: you shouldn't be inheriting autotools or gettext for this recipe either
Apr 20 14:33:41 <miandonmenmian> ah, that is a very good point
Apr 20 14:34:02 <bluelightning> you do have a closing } at the end of do_install as well right?
Apr 20 14:35:02 <miandonmenmian> oh, brother...
Apr 20 14:36:09 <miandonmenmian> thanks a bunch bluelightning, that was probably it
Apr 20 14:36:30 <bluelightning> it's curious that that didn't trigger an error
Apr 20 14:37:10 <miandonmenmian> i was wondering as well. but i'm pretty certain i have not seen any with regards to the do install or brackets
Apr 20 14:52:30 <bluelightning> after reproducing the lack of error I filed a bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7633
Apr 20 14:52:31 <yocti> Bug 7633: normal, Undecided, ---, richard.purdie, NEW , Parser does not error out on unclosed function
Apr 20 14:55:43 <timsche> hey guys, i'm trying to build yocto for rpi with qt5. so i'm using poky master, meta-qt5 master, meta-raspberrypi master and meta-openembedded master.
Apr 20 14:55:43 <timsche> my bblayers.conf goes like http://apaste.info/pI0 , while my local.conf goes like http://apaste.info/qcU .
Apr 20 14:55:43 <timsche> qtbase fails to compile - the error log goes here http://apaste.info/DIT .
Apr 20 14:55:43 <timsche> did anyone of you succeed in building this configuration? any opinions?
Apr 20 14:57:28 <timsche> and i forgot to mention that i've edited qtbase.inc to use gles2 instead of desktop gl
Apr 20 15:26:27 <lpapp> bluelightning: I am getting this, WARNING: libstdc++-4.8.2 was registered as shlib provider for libstdc++.so.6, changing it to foo-0.1 because it was built later
Apr 20 15:26:32 <lpapp> I wonder hwy
Apr 20 15:26:33 <lpapp> why*
Apr 20 15:26:59 <bluelightning> lpapp: is foo-0.1 is installing its own libstdc++.so.6?
Apr 20 15:27:16 <lpapp> not as far as I am aware of.
Apr 20 15:27:27 <bluelightning> the warning would suggest that it is
Apr 20 15:27:45 <lpapp> oh, wow, it does
Apr 20 15:27:51 <lpapp> how nasty
Apr 20 15:28:01 <lpapp> this is not what I agreed with my colleague :P
Apr 20 15:48:20 <ericbutters> hi. i simply want to build my linux kernel. i use an external toolchain. i only do: bitbake virtual/kernel -- and that works. but why there are 457 tasks installing i.e binutils-native, so *-native* packages? is this really needed to just compile my kernel? how to remove unused stuff? can i blacklist this?
Apr 20 16:39:22 <lpapp> hmm, renaming yocto based repositories with ain't fun.
Apr 20 16:39:52 <lpapp> sadly, git will not do renaming of a directory with more than 4K files without further trouble and it seems the poky repository has far more than that file amount.
Apr 20 16:51:16 <lpapp> bluelightning: so is it ok to use PRIVATE_LIBS then?
Apr 20 16:51:26 <lpapp> it would be less work for me now than refactoring the system with testing.
Apr 20 16:52:08 <bluelightning> you probably should yes
Apr 20 16:52:59 <bluelightning> though it probably won't change the behaviour since it appears to have acknowledged your "custom" version of the lib
Apr 20 16:53:48 <lpapp> yes, that is fine, I just want to get rid of the warning.
Apr 20 16:54:01 <kergoth> ericbutters: i'd say use bitbake -g, possibly with depexp, to explore the dependency graph to determine that. e.g. bitbake -g -u depexp virtual/kernel
Apr 20 17:26:01 <lpapp> bluelightning: if you had not seen it, https://bugzilla.yoctoproject.org/show_bug.cgi?id=7632
Apr 20 17:26:02 <yocti> Bug 7632: normal, Undecided, ---, scott.m.rifenbark, NEW , ROOTFS_POSTPROCESS_COMMAND no longer accepts raw commands, just functions
Apr 20 17:27:24 <lpapp> bluelightning: which file shall I put into PRIVATE_LIBS, the library with the symlinks, too?
Apr 20 17:27:34 <lpapp> there are two symlinks created by the recipe to the library.
Apr 20 17:27:43 <bluelightning> just the library I believe
Apr 20 17:27:58 <lpapp> so libstdc++.so -> libstdc++.so.6 -> libstdc++.so.6.0.10
Apr 20 17:29:59 <lpapp> bluelightning: so in my case libstdc++.so.6.0.10 or libstdc++.so?
Apr 20 17:30:19 <lpapp> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PRIVATE_LIBS -> this seems to use the .so files.
Apr 20 17:30:22 <lpapp> not the versioned ones.
Apr 20 17:30:32 <lpapp> I wonder if that is intentional or just coincidence.
Apr 20 17:30:57 <bluelightning> not sure, sorry
Apr 20 17:31:10 <lpapp> ok, I will keep trying until the warning is gone.
Apr 20 18:23:08 <trip0> what is the status of fido?  Is it too late to pull in the latest bluez (5.30)?
Apr 20 18:31:27 <lpapp> does the Yocto build bail out with failure if a patch cannot be applied?
Apr 20 18:32:43 <kergoth> if a patch can't be applied, the do_patch task will fail. bitbake will then cleanly shut down, letting the other currently running tasks finish, and then exit non-zero, unless you run with bitbake -k, in which case it will continue running as many tasks as it's possible to run given the task that failed, and will then exit non-zero
Apr 20 18:33:18 <kergoth> the -k argument came from gnu make, which has similar behavior
Apr 20 18:38:50 <lpapp> ok, thanks.
Apr 20 18:39:13 <lpapp> I updated from dylan to daisy and the build succeeds, but my kernel will no longer boot
Apr 20 18:39:31 <lpapp> it hungs up at the state of "Uncompressing Linux... done, booting the kernel."
Apr 20 18:39:43 <lpapp> we have our own kernel recipe, not sharing it with Yocto
Apr 20 18:39:57 <lpapp> and after the upgrade, we did not change that, so I am surprised that it is broken.
Apr 20 18:40:11 <kergoth> possibly a toolchain version problem, assuming the kenrel hasn't changed
Apr 20 18:40:15 <lpapp> perhaps the kernel was created properly, but the image not?
Apr 20 18:40:21 <kergoth> there have definitely been issues with certain gcc versions and the kernel
Apr 20 18:40:23 <lpapp> I guess I would need to look into the the log.*?
Apr 20 18:40:46 <kergoth> that's a possibility too, but if it stops that early, i doubt it got far enough to run init in the rootfs
Apr 20 18:40:50 <lpapp> hmm, I would not know how to proceed from there as I am not the kernel developer in here.
Apr 20 18:40:53 <kergoth> unless you're passing quiet in the cmdline
Apr 20 18:41:01 <kergoth> in which case you should remove that so you can see more of what's going on
Apr 20 18:41:18 <lpapp> oh, kernelopts=rw rootwait quiet
Apr 20 18:41:22 <lpapp> uboot has that, indeed
Apr 20 18:41:28 <lpapp> good idea :)
Apr 20 18:41:31 <lpapp> (to check it)
Apr 20 18:41:55 <kergoth> :)
Apr 20 18:42:30 <lpapp> the bootlog seems to be the same without that, too :( https://paste.kde.org/pktk6fov5
Apr 20 18:43:06 <lpapp> I wonder how to proceed from here. I wish I had more low-level Linux kernel experience.
Apr 20 18:43:21 <lpapp> there must be some command line option to turn more logging on
Apr 20 18:43:25 <kergoth> my *guess* would be a possibly miscompiled kernel, assuming you're using an internal toolchain
Apr 20 18:43:37 <kergoth> yeah, should be able to crank up console printk log level
Apr 20 18:43:42 <kergoth> i don't recall the exact syntax offhand, though
Apr 20 18:44:21 <lpapp> I am using the toolchain that Yocto generates.
Apr 20 18:44:30 <lpapp> but I can double check the log.do_compile file for the kernel
Apr 20 18:45:36 <lpapp> hmm, sadly not built with VERBOSE=1
Apr 20 18:45:55 <lpapp> NOTE: make -j 8 uImage CC=arm-foo-linux-gnueabi-gcc  -mno-thumb-interwork -marm LD=arm-foo-linux-gnueabi-ld.bfd
Apr 20 18:46:00 <lpapp> this is the best I can get out of it.
Apr 20 18:46:32 <kergoth> not sure if that'll change anything, usually such bugs will just be a bad interaction between gcc and the kernel resulting in something ending up miscompiled, but no indication of such in the gcc output. i don't know of any specific bugs like that offhand, but i've seen them before. usually the kernel will end up with a fix to adjust for it later on. could check the kernel log for after your version, i suppose
Apr 20 18:46:46 <lpapp> there is this in the compilation log, but I am not sure if it can be ignored: WARNING: modpost: Found 1 section mismatch(es).
Apr 20 18:46:48 <kergoth> also don't know what version of gcc was used in your previous poky version vs current
Apr 20 18:47:46 <lpapp> me neither, I would need to look it up, but it was a dylan to daisy change
Apr 20 18:47:47 <kergoth> no idea, unfortunately. been long enough since i've done any kernel development that those skills are all atrophied and out of date :)
Apr 20 18:47:47 <kergoth> might be something else, this was all that came to mind as a possibility
Apr 20 18:47:47 * kergoth shrugs
Apr 20 18:48:38 <lpapp> ok, thank you
Apr 20 18:48:46 <lpapp> I will probably ask this in #kernelnewbies, too
Apr 20 18:48:54 <lpapp> they might be less rusty than us :P
Apr 20 19:40:09 <kergoth> Hmm, I should propose adding 'd' to event handlers, the way it's available elsewhere and via e.data, just as a convenience
Apr 20 19:46:44 <kergoth> should also propose including the cooker's expanded_data in the ConfigParsed event
Apr 20 19:47:00 <kergoth> both would simplify some event handlers somewhat
Apr 20 19:47:05 * kergoth adds todo
Apr 20 20:29:03 * kergoth moves the meta-sourcery sanity checks from BuildStarted to TreeDataPreparationStarted
Apr 20 21:29:30 <khem`> Can we generate a rootfs tar with symbols and debug info and then strip it for final image ?
Apr 20 21:30:10 <khem`> current tarball is as much stripped as any other image fs type
Apr 20 21:40:11 <kergoth> not that i know of, but work has been done on generating a separate filesystem with just the -dbg packages installed, so you can point gdb at that. not sure if that was ever merged, however
Apr 20 21:40:39 <khem`> do you have links
Apr 20 21:40:57 <kergoth> checking for it now
Apr 20 21:40:59 <khem`> it should be like
Apr 20 21:41:06 <khem`> IMAGE_FSTYPES
Apr 20 21:41:26 <kergoth> fs types just control archival of the fs, that's too late to change their content
Apr 20 21:42:04 <khem`> I meant from usability POV
Apr 20 21:42:12 <khem`> underneath I agree
Apr 20 21:42:59 <kergoth> you can alwyas add dbg-pkgs to IMAGE_FEATURES< but of course that affects every output of the image
Apr 20 21:43:17 <kergoth> th enice thing about a separate debug fs is you can e.g. put it on a usb stick, or just extrac tit to point gdb at when you connect to gdbserver
Apr 20 21:43:34 <kergoth> looking for the patch/branch now
Apr 20 21:43:56 <khem`> exactly
Apr 20 21:44:21 <khem`> I want the images to be stripped but corresponding debug rootfs image in tarball
Apr 20 21:44:44 <khem`> so folks can use it to debug the crash by booting from USB and so on
Apr 20 21:45:05 <kergoth> we rolled our own version of it in meta-mentor a while ago, but the pending one sent to the list is cleaner, if i can track the damn thing down
Apr 20 21:45:22 <kergoth> i need to start jotting down pending branches / patch series that interest me so i can monitor their status
Apr 20 21:45:23 <kergoth> heh
Apr 20 21:46:51 <kergoth> khem`: see poky-contrib, mhatle/debugfs
Apr 20 21:47:18 <kergoth> also went to oe-core, "image.bbclass: Add a method for creating a companion debug filesystem"
Apr 20 21:48:32 <khem`> ok
Apr 20 21:48:48 <khem`> hope it will work with 1.6 too
Apr 20 21:49:07 <kergoth> depends on whether 1.6 was before image construction got converted to python, i don't remember when that happened :)
Apr 20 21:51:02 <khem`> ls ../lib/oe/package.py
Apr 20 21:51:03 <khem`> ../lib/oe/package.py
Apr 20 21:51:08 <khem`> so yes it was :)
Apr 20 21:51:11 <kergoth> nice
Apr 20 21:51:21 <khem`> let me try it
Apr 20 21:55:32 <khem`> I dont see it in OE-core
Apr 20 21:55:39 <khem`> do you have a  SHA
Apr 20 21:55:48 <kergoth> it went to the oe-core *list*, but wasn't merged
Apr 20 21:55:52 <kergoth> still pending, no one merged it
Apr 20 21:56:02 <kergoth> should be in patchwork, i'd expect
Apr 20 21:56:28 <kergoth> should reply with a reminder in case it fell off the radar
Apr 20 21:56:49 <kergoth> i'm sick of having overridden image.bbclass in meta-mentor-staging :)
Apr 20 21:57:32 <khem`> ah I see
Apr 20 21:58:08 <khem`> http://patchwork.openembedded.org/patch/83519/
Apr 20 21:58:25 <khem`> you acked it
Apr 20 21:58:35 <khem`> thats good but no heed
Apr 20 21:59:20 <kergoth> yeah, i'm guessing it probably fell off richard/saul's radar and mhatle and i never followed up
Apr 20 21:59:26 <kergoth> it happens
Apr 20 21:59:48 <khem`> right
Apr 20 21:59:55 <khem`> so resurrect it
Apr 20 22:00:06 <khem`> thats why pw is so useful
Apr 20 22:00:22 <khem`> we dont use it as effectively for oe-core as we do for other layer s
Apr 20 22:01:09 <kergoth> replied
Apr 20 22:01:11 <kergoth> agreed
Apr 20 22:07:37 <RP> kergoth: its intended for master FWIW, just never see the patch at the right time :/
Apr 20 22:12:24 <khem`> RP: its has  become a bit stale
Apr 20 22:13:03 <RP> khem`: I think fray said he'd repost it
Apr 20 22:13:32 <khem`> cool
Apr 20 22:14:02 <khem`> its worth for 1.8 too
Apr 20 22:18:12 <kergoth> cool
Apr 20 22:18:13 <kergoth> looks like the rejects are pretty straightforward to resolve, it seems, just did it here when applying it to meta-mentor-staging as a temporary measure.
Apr 20 22:49:35 <khem`> kergoth: can you post the updated patch somewhere ?
Apr 20 22:53:32 <kergoth> khem`: https://gist.github.com/5412df1791f596630696
Apr 20 22:53:58 <kergoth> curl https://gist.githubusercontent.com/kergoth/5412df1791f596630696/raw/81780886483d195d3f84aae091646987347534a3/- | git am
Apr 20 22:54:35 <kergoth> only limited testing done
Apr 20 22:54:38 <kergoth> but should be fine
Apr 20 22:54:52 <kergoth> stuck waiting on a rebuild mostly from scratch after updating our upstream layers
Apr 20 22:54:54 * kergoth taps foot
Apr 20 22:55:09 <khem`> heh
Apr 20 22:56:37 <kergoth> sstate is nice and all, but still feels awfully brittle, doesn't take much to end up rebuilding the world from scratch
Apr 20 22:57:18 <kergoth> need to think about how to implement task output checksumming.. would likely be non-trivial, though, would require adjusting the runqueue more on the fly
Apr 20 23:18:33 <khem`> kergoth: Yeah i am getting lot of fire for it
Apr 20 23:19:42 <kergoth> even output checksumming wouldn't be perfect, given we'd have to figure out how to limit the scope by path potentially, or capture the api of the output, or fix builds to be more reproducible, less encoding of timestamps and whatnot.. probably a combination of all of them
Apr 20 23:20:44 <kergoth> there's also the possibility of having file-level task-dependencies coupled with the output checksumming, e.g. we only depend on these files, only if they change should we rebuild, but others might depend on something else
Apr 20 23:23:49 <kergoth> hmm, bitbake chokes if TMPDIR is g+s.. we should improve it so it just does a chmod g-s when TMPDIR is created in the first place, if possible
Apr 20 23:24:01 <kergoth> if we know what's wrong, and what's wrong is in our output, we should just fix it
Apr 20 23:24:22 <kergoth> it's quite reasonable for COREBASE & friends to be g+s for sharing will colleagues
Apr 20 23:24:37 <kergoth> so if you create build dirs in ${COREBASE}/.., bitbake gets unhappy
Apr 21 01:34:43 <chankit> hello..my bitbake process shows warning  rdepends on libgl-mesa. I then added libgl-mesa to DEPENDS variable in my recipe but now it says nothing provides libgl-mesa...any idea?
Apr 21 01:41:15 <khem`> add it to RDEPENDS_${PN} = "libgl-mesa"
Apr 21 01:41:22 <chankit> never mind..I added them to RDEPENDS_${PN} instead and all is well
Apr 21 01:41:43 <chankit> I wonder why can't I add it to DEPENDS variable?
Apr 21 01:42:03 <kergoth> DEPENDS is for recipes, not binary packages
Apr 21 01:42:09 <kergoth> RDEPENDS is runtime, binary packages
Apr 21 01:42:11 <khem`> DEPENDS is build time
Apr 21 01:42:17 <khem`> RDEPENDS is for runtime
Apr 21 01:42:41 <khem`> so DEPENDS = "recipe-name" and RDEPENDS = "ipk name"
Apr 21 01:43:01 <khem`> kergoth: I build sstate using externalsrc and then try to use it elsewhere
Apr 21 01:43:14 <khem`> and it invalidates it because ${S} changed
Apr 21 01:43:22 <khem`> any remedies
Apr 21 01:43:43 <kergoth> externalsrc explicitly disables use of sstate. see the bb.build.deltask()
Apr 21 01:44:03 <khem`> hmm
Apr 21 01:44:13 <kergoth> but yes, you could use vardepsexclude on all the tasks using it, or globally add to BB_HASHBASE_WHITELIST, but that's across everything, not per recipe, so would invalidate all current checksums
Apr 21 01:44:41 <kergoth> probably don't want to do the latter
Apr 21 01:44:55 <kergoth> but yeah, unless you kill the bits disabling sstate, it won't do much anyway
Apr 21 01:45:23 <khem`> so big issue for folks who has the flat tree dev
Apr 21 01:45:26 <khem`> like android
Apr 21 01:45:41 <khem`> all tooling is around that kind of development
Apr 21 01:45:44 <khem`> for platform work
Apr 21 01:46:09 <kergoth> yeah. i've often thought it'd be fun to try a complete oe-core build with everything using local git sources and versions extracted from the git repos
Apr 21 01:47:58 <khem`> kergoth: yes
Apr 21 01:48:08 <chankit> kergoth: khem`: So what I understand now is DEPENDS is recipe dependency, and RDEPENDS is runtime dependency. Is that right?
Apr 21 01:48:46 <khem`> chankit: yes
Apr 21 01:49:14 <khem`> kergoth: http://bazel.io/
Apr 21 01:49:19 <khem`> have you seen it
Apr 21 01:49:22 <kergoth> nope
Apr 21 01:49:36 <kergoth> oh i remember seeing it linked on hacker news or something
Apr 21 01:49:40 <kergoth> didn't look very closely yet
Apr 21 01:49:50 <khem`> it looks promising
Apr 21 01:50:03 <khem`> build from source
Apr 21 01:50:15 <khem`> the kind of thing we are talking
Apr 21 01:50:27 <chankit> khem`: So is it true that there are binary packages that are not provided by any recipe?
Apr 21 01:51:24 <kergoth> chankit: that doesn't really make sense.
Apr 21 01:51:35 <khem`> chankit: yes e.g. if they are empty then packager will optimize them out
Apr 21 01:51:56 <chankit> kergoth: I'm afraid I'm just confused here.
Apr 21 01:51:59 <khem`> so you might have to add ALLOW_EMPTY_<ipk>
Apr 21 01:52:07 <kergoth> every recipe emits multiple binary packages
Apr 21 01:52:23 <kergoth> the main package might not be emitted if the recipe doesn't install any files, as khem points out
Apr 21 01:52:50 <khem`> kergoth: I have been looking at gradle too
Apr 21 01:52:55 <khem`> and cmake
Apr 21 01:53:00 <khem`> as alternatives
Apr 21 01:53:42 <kergoth> I'd like to play with something whose primary output is the binary package(s). local sources -> packages, deal with both fetching and feed/image construction as separate steps
Apr 21 01:54:03 <kergoth> construct sysroots from the packages
Apr 21 01:54:18 <kergoth> no separate task level scheduling and task acceleration via sstate
Apr 21 01:54:24 <kergoth> just as an experiment to see how it goes
Apr 21 01:55:07 <khem`> kergoth: BUILD_IMAGES_FROM_FEEDS
Apr 21 01:55:16 <khem`> you can stay in bb world
Apr 21 01:55:29 <chankit> kergoth: khem`: I think I'm starting to get some sense here....so suppose that a recipe foo spawns binary packages spam and egg, and another recipe bar has a runtime dependency on spam, then I should do RDEPENDS_{"bar"}=spam ?
Apr 21 01:56:02 <kergoth> RDEPENDS_${PN} += "spam", yes
Apr 21 01:56:35 <kergoth> but 90% of the time the runtime dependency is due to shared library linking, and those you don't have to do manually. if A links against a library in B, A will automatically rdepend on B
Apr 21 01:59:00 <chankit> so rdepends variable can have libraries, binaries and what else?
Apr 21 01:59:02 <khem`> kergoth: BUILD_IMAGES_FROM_FEEDS is something we can use ?
Apr 21 01:59:11 <khem`> also should accelarate
Apr 21 01:59:11 <khem`> right ?
Apr 21 01:59:13 <kergoth> chankit: again, doens't really make sense. rdepends lists binary packages.
Apr 21 01:59:23 <kergoth> chankit: what gets put in those packages is up to the recipe
Apr 21 01:59:32 <kergoth> the recipe that created them, that is
Apr 21 01:59:50 <kergoth> khem`: i think so, never actually tried it myself. would be interesting to play with
Apr 21 02:00:17 <kergoth> meh, meta-sourcery has problems with multilibs again, no preferences are specified for the multilib variants.. maybe i need some ${MLPREFIX}'s
Apr 21 02:01:09 <kergoth> either that or i need to stop handling the preferences this way
Apr 21 02:01:11 <khem`> multilib should die
Apr 21 02:01:19 <chankit> kergoth: let me try again...erm...so rdepends can only contain packages?
Apr 21 02:01:49 <kergoth> as we said earlier, DPEENDS contains build time dependencies, which are recipes, and RDEPENDS contains runtime dependencies, which are packages
Apr 21 02:03:04 <chankit> kergoth: ok...got it..thanks
Apr 21 02:14:48 <khem`> kergoth: I wonder how will BUILD_IMAGES_FROM_FEEDS interact with sstate
Apr 21 02:14:59 <khem`> is it a addition
**** ENDING LOGGING AT Tue Apr 21 02:59:58 2015