**** BEGIN LOGGING AT Fri May 13 02:59:59 2016
May 13 04:39:54 <smurray> seebs: what release are you using? I believe there was a fix wrt removing those packages post-fido to make it only kick in if you enable readonly rootfs
May 13 05:21:46 <seebs> smurray: We're relatively recent, I think, and there were some conditions related to read-only rootfs, but I'm not entirely sure.
May 13 05:21:57 <seebs> I ended up just modifying the run-ptest script not to use gpasswd to try to edit /etc/group.
May 13 06:07:39 <niteshnarayanlal> are there any other examples for  the usage of multilib support
May 13 06:08:30 <niteshnarayanlal> boucman_work, ^
May 13 06:08:37 <khem> what are you looking at
May 13 06:09:04 <niteshnarayanlal> right now I am referring http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image
May 13 06:09:15 <niteshnarayanlal> and meta-skeleton example as given there
May 13 06:10:26 <khem> ok so what is missing in those examples ?
May 13 06:11:26 <niteshnarayanlal> so I understood the part where I need to set multilib.conf
May 13 06:11:30 <niteshnarayanlal> in my conf directory
May 13 06:12:03 <niteshnarayanlal> after that I was lost because I don't have to install anything anywhere (32-bit and64-bit libs)
May 13 06:12:37 <niteshnarayanlal> I just have to build a binary using 32-bit tool chain which will be used by another which is to be compiled by 64-bit tool chain
May 13 06:12:57 <khem> no
May 13 06:13:19 <khem> additional things needed
May 13 06:13:46 <khem> once you enable mutlilib it will generate 32bit and 64bit toolchains for you
May 13 06:14:15 <khem> as well as runtimes
May 13 06:14:52 <niteshnarayanlal> so if I just want to enable it all I have to do is define multilib.conf in my conf
May 13 06:14:54 <niteshnarayanlal> isn't
May 13 06:19:04 <khem> you need to add something like this to local.conf
May 13 06:19:51 <khem> #require conf/multilib.conf
May 13 06:19:53 <khem> #MULTILIBS = "multilib:lib32"
May 13 06:19:55 <khem> #DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
May 13 06:20:01 <khem> ofcourse no leading #
May 13 06:20:09 <khem> this is for arm
May 13 06:20:23 <khem> but you can use same for x86
May 13 06:20:52 <khem> just set DEFAULTTUNE to one of x86 tunes
May 13 06:27:35 <niteshnarayanlal> ah ok I created multilib.conf but didn't make any changes in the local.conf
May 13 06:28:19 <niteshnarayanlal> probably that's why it was not building the 32 bit tool chain, I am trying this for arm platform only
May 13 06:55:39 <marek_> hi all, I'm having strange error when building custom image (never seen that before) during manifest create: http://pastebin.com/gWxk04Tj
May 13 07:00:29 <khem> marek_: which branch/distro
May 13 07:03:41 <marek_> khem: disto is ubuntu 12.04 and it jethro 14.0.1
May 13 07:07:55 <khem> ok
May 13 07:08:04 <khem> did u change
May 13 07:08:12 <khem> anything
May 13 07:09:41 <marek_> khem: nope no changes in poky
May 13 07:10:25 <khem> ok
May 13 07:10:39 <khem> did it work in past
May 13 07:12:14 <marek_> yes it works
May 13 07:12:28 <marek_> I just removed some dependecies of packages whic hI don't need
May 13 07:12:41 <marek_> strange it that I'm building for other machines and it works
May 13 07:12:48 <marek_> have an issue with only one machine
May 13 07:12:51 <marek_> which is odd
May 13 07:14:30 <present> Hi
May 13 07:15:35 <khem> marek_: you said you did notchange
May 13 07:16:09 <marek_> I'm using poky and some of mine layers (I mean I doidn't change anything in poky)
May 13 07:23:42 <marek_> khem: when checking log I found also another error: ERROR: QA Issue: PKGV not defined [pkgv-undefined]
May 13 07:47:15 <boucman_work> morning
May 13 09:07:26 <niteshnarayanlal> multilib is setup but I am getting Checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
May 13 09:07:48 <niteshnarayanlal> I looked up for it and tried some suggestions but no success
May 13 09:50:08 <boucman_work> hey all
May 13 09:50:29 <boucman_work> I have opkg's first-boot task that fail on read-only filesystems (which is normal)
May 13 09:50:50 <boucman_work> is there a way to find out what it is trying to do so I can audit whatever recipe wants to write ?
May 13 10:01:26 <LeifSo> hi! I want to use toaster's web ui to manage a local project. Unfortunately, it refuses to import layers
May 13 10:01:44 <LeifSo> it states the name is already taken, but the layer isn't there
May 13 10:02:23 <LeifSo> 'hint layer exists with different url'
May 13 10:36:33 <belen> LeifSo: yes, we have a bug there right now. Sorry. If a layer with the same name exists already in your Toaster database with a different Git URL, you won't be allowed to export it with that name. You need to give your layer a different name
May 13 10:36:44 <belen> export / import
May 13 10:37:16 <belen> LeifSo: which version of Yocto Project are you using?
May 13 15:56:57 <davis> someone here told me about oe-pkgdata-util, that was great.  It enabled me to find a receipe.  Besides $find . -name "*recipe*name*.bb", how do I find the recipe .bb? Is there some tool to do that?
May 13 15:59:17 <fredcadete> what a good question
May 13 16:00:07 <rburton> $ bitbake-layers  show-recipes m4 -f
May 13 16:00:07 <rburton> Parsing recipes..done.
May 13 16:00:07 <rburton> === Matching recipes: ===
May 13 16:00:07 <rburton> /home/ross/Yocto/poky/meta/recipes-devtools/m4/m4_1.4.17.bb
May 13 16:00:07 <rburton>   /home/ross/Yocto/poky/meta/recipes-devtools/m4/m4_1.4.9.bb
May 13 16:00:48 <rburton> indentation shows priority, so 1.4.17 is used
May 13 17:21:26 <RP> halstead: I'm assuming you're doing maintenance atm, could you fire a master-next build when done please?
May 13 17:23:37 <halstead> RP, Gladly!
May 13 17:24:19 <RP> halstead: thanks!
May 13 17:40:21 <halstead> RP, Started without debian8 which will take a little extra care today.
May 13 17:41:57 <halstead> And apparently something isn't right....
May 13 17:51:51 <halstead> RP, Was that a problem with master-next or the autobuilder? The basics on the AB seem fine.
May 13 17:53:48 <kergoth> hmm, rrdtool isn't getting the Makefile fixups cpan_do_configure normally does. also, the do_compile re-runs Makefile.PL anyway, blowing away the bits we did for that in do_configure..
May 13 17:53:54 * kergoth kicks rrdtool recipe
May 13 17:58:47 <Circuitsoft> How can I make my app run on something less than a core2?
May 13 17:58:59 <Circuitsoft>     Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS_tune-i686} genericx86) for DEFAULTTUNE (i686) does not contain TUNE_PKGARCH (${TUNE_PKGARCH_tune-i686}).Toolchain tunings invalid:
May 13 18:12:23 <khem> kergoth: can we use BB_SRCREV_POLICY in recipe namespace
May 13 18:14:05 <khem> halstead: there ?
May 13 18:14:15 <kergoth> khem: afaik yes, it's used by the fetcher in multiple places, but all of which should be recipe context, not config metadata. but i could be wrong, never tested it
May 13 18:14:18 <halstead> khem, I am here.
May 13 18:14:33 <khem> Can we shed some fat on poky-contrib
May 13 18:14:38 <halstead> khem, Were you suggesting moving some older parts of poky-contrib into poky-contrib-archive ?
May 13 18:15:04 <halstead> khem, Yes. I can do that.
May 13 18:15:14 <khem> actually 90% branches must be dead
May 13 18:15:35 <khem> so may be send out a request for owners to delete dead or merged branches
May 13 18:16:16 <khem> git push contrib :user/branchname
May 13 18:23:25 <kergoth> there we go, fixed rrdtool's reloc failure and also fixed B vs S so we can drop brokensep.. now to get back to what i was working on before it exploded...
May 13 18:23:26 <kergoth> hmm
May 13 18:37:20 <khem> kergoth: once I set BB_SRCREV_POLICY = "cache" and then add SRCREV = "AUTOREV"
May 13 18:37:38 <khem> will it still poke at the repo for revision everytime  ? or just first time
May 13 18:39:50 <kergoth> just the first time. once it has a rev, it'll use that rather than contacting upstream
May 13 18:40:47 <kergoth> for a while we shipped a prepopulated srcrev map in the sqlite db coupled with BB_SRCREV_POLICY = "cache" to handle BB_NO_NETWORK for autorev. nowadays we must run buildhistory-collect-srcrevs and include that file instead to do the lockdown
May 13 18:40:55 <kergoth> s/must/just/
May 13 19:31:02 <halstead> sgw_, Could you look at the master-next I started and let me know if the failures are obviously caused by the code? I did AB maintenance and all looks well on the builder side so far.
May 13 21:05:51 <RP> halstead: the build failures are my fault, don't worry
May 13 21:06:40 <RP> halstead: trying another build
May 13 21:07:00 <halstead> RP thanks! I couldnt find anything wrong with the builders. :)
May 13 21:07:21 <RP> halstead: my own fault for fixing up something on the branch and not testing :/
May 13 21:07:29 <halstead> sgw_, Nevermind. It's sorted.
May 13 21:07:48 <halstead> Debian8 will be awhile while disks are replaced.
May 13 22:00:11 <astrophys> Or he could just have the pizza
**** ENDING LOGGING AT Sat May 14 02:59:58 2016