**** BEGIN LOGGING AT Fri Mar 14 02:59:59 2014
Mar 14 05:40:06 <vicky_> hi yocto
Mar 14 05:41:47 <vicky_> how can i remove a package(which i don't need) from my image?
Mar 14 05:59:20 <nerdboy> is it explicitly listed in image_install, or in a package group?
Mar 14 05:59:59 <nerdboy> if not, then it's most likely pulled in by a runtime depend from another package
Mar 14 06:01:10 <vicky_> it is from a package group
Mar 14 06:07:49 <vicky_> yeah. simply i want to remove a package which getting install from a package group.
Mar 14 06:08:10 <vicky_> i dont want to install it in my final rootfs
Mar 14 06:15:17 <nerdboy> other than deleting it from the package group?  i might try something like using opkg to uninstall it in postprocess function
Mar 14 06:16:16 <nerdboy> you pretty much have to edit something...  depends on how "elegant" you want it to be...
Mar 14 06:19:30 <nerdboy> for example
Mar 14 06:20:03 <nerdboy> you could create a function to "opkg remove foo" and set this:
Mar 14 06:20:06 <nerdboy> meta/classes/image.bbclass:IMAGE_POSTPROCESS_COMMAND ?= ""
Mar 14 06:20:34 <nerdboy> IMAGE_POSTPROCESS_COMMAND = " do_remove "
Mar 14 06:20:55 <nerdboy> then you define do_remove in your image recipe
Mar 14 06:22:51 <nerdboy> maybe grep your layers and make sure nothing else rdepends on it
Mar 14 06:23:13 <vicky_> i would like if any rule like IMAGE_UNINSTALL or IMGAE_INSTALL -=
Mar 14 06:24:17 <nerdboy> i've never seen that one
Mar 14 06:24:23 <nerdboy> not yet, anyway
Mar 14 06:24:27 <vicky_> ha ha. i am joking
Mar 14 06:24:38 <vicky_> there is no rule like tat
Mar 14 06:47:12 <nerdboy> vicky_: i just noticed this: meta/classes/image.bbclass:PACKAGE_EXCLUDE ??= ""
Mar 14 06:47:43 <nerdboy> take a look at meta/classes/image.bbclass
Mar 14 06:47:55 <nerdboy> maybe that'll do it for you
Mar 14 06:48:41 * nerdboy needs to spend some future spare time reading...
Mar 14 08:11:25 <mckoan> good morning
Mar 14 09:49:01 <ionte> hi. i have a basic custom image running both on olinuxino and qemux86. now i would like to specify custom network settings.
Mar 14 09:49:33 <ionte> if i understand it correctly i should override the interfaces-file installed by recipes-core/init-ifupdown ....
Mar 14 09:49:55 <ionte> but how do i do that?
Mar 14 10:16:12 <bluelightning> morning all
Mar 14 10:46:48 <sce_> hello
Mar 14 10:48:00 <sce_> i'm using autotools class and my B var is not equal to my S var. How can i know who is changing B var ?
Mar 14 10:48:46 <rburton> sce_: autotools.bbclass does
Mar 14 10:49:17 <rburton> ideally you fix the software to actually build like that
Mar 14 10:49:25 <rburton> if the authors used make distcheck, it would work already
Mar 14 10:49:57 <rburton> the workaround is to inherit autotools-brokensep instead
Mar 14 10:50:04 <rburton> but really try fixing upstream
Mar 14 10:51:21 <sce_> ok thx i'm having a look
Mar 14 10:53:30 <rburton> generally its an easy fix for the build, it's just making assumptions about what the current directory is
Mar 14 10:53:38 <rburton> and they're wrong for out of tree builds
Mar 14 10:53:57 <rburton> as i said, running make distcheck on the source outside of yocto will easily reproduce the failures
Mar 14 10:54:56 <sce_> i'm building gst-plugins-bad from git repo
Mar 14 10:55:05 <sce_> gst-plugins-bad-0.10
Mar 14 10:55:14 <sce_> i need the last revision
Mar 14 10:55:27 <rburton> from git is very hard
Mar 14 10:55:35 <rburton> becuase they use submodules and crazy scripts
Mar 14 10:55:46 <rburton> i suggest you patch the latest release instead
Mar 14 10:56:31 <sce_> yes but i need a lot of patch i guess
Mar 14 10:56:44 <sce_> and it seems to work except this B folder
Mar 14 10:57:00 <sce_> i need the eglglessink to support RPI
Mar 14 10:57:34 <rburton> try changing the inherit to autotools-brokensep and seeing if that fixes it
Mar 14 10:57:44 <sce_> i dont understand the trigger which is changing my B var
Mar 14 10:57:55 <sce_> because it is working with gstreamer-1.0
Mar 14 10:57:57 <rburton> but generating a diff will be fairly simple
Mar 14 11:22:02 <diego_r> Hi all. I'm trying to fix a problem in building native package, but I'm not able to clean it. "bitbake -c cleanall bzip2-native" doesn't work, the files in tmp/work/x86_64-linux/bzip2-native/1.0.6-r5/ are still there, at least those in "temp"
Mar 14 11:23:33 <rburton> all that remains in temp is the logs of previous builds
Mar 14 11:24:59 <diego_r> rburton: ok. Than this is the problem I get: http://pastebin.com/zL2uWm15
Mar 14 11:25:32 <diego_r> Isn't configure.ac supposed to be already there?
Mar 14 11:25:53 <rburton> yes
Mar 14 11:25:57 <rburton> is anything these?
Mar 14 11:26:01 <rburton> oh no
Mar 14 11:26:04 <rburton> that's very wrong
Mar 14 11:26:17 <rburton> the path to configure.ac is incorrect
Mar 14 11:26:21 <rburton> have you been changing bzip2?
Mar 14 11:28:27 <diego_r> rburton: I was building on dora. Then hit an "cp: will not overwrite just-created `/opt/yocto_builder/build-nitrogen6x/tmp/work/x86_64-linux/bzip2-native/1.0.6-r5/bzip2-1.0.6/install-sh' with `/opt/yocto_builder/build-nitrogen6x/tmp/sysroots/x86_64-linux/usr/share/automake-1.14/install-sh' caused by this: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-extended/bzip2/bzip2_1.0.6.bb?
Mar 14 11:28:28 <diego_r> id=937663bdeca6d6479e0db2a9578588b1aa20222c not being backported to dora
Mar 14 11:29:16 <rburton> well the path that it was trying to run configure.ac from is incorrect
Mar 14 11:29:37 <rburton> (missing an element)
Mar 14 11:30:01 <diego_r> then probably deleted tmp/work/x86_64-linux/bzip2-native/ and started to get the problem I have paste in pastebin
Mar 14 11:31:45 <diego_r> rburton: is it missing the ending "bzip2-1.0.6"? Note that it's empty anyway
Mar 14 11:31:59 <rburton> so the extract failed too
Mar 14 11:32:21 <rburton> so if you do bitbake -ccleanall bzip2-native; bitbake bzip2-native, that's what happens?
Mar 14 11:32:30 <diego_r> rburton: http://pastebin.com/wMz9NebE
Mar 14 11:32:38 <diego_r> yeah, correct
Mar 14 11:33:54 <diego_r> rburton: oh well. no
Mar 14 11:34:30 <diego_r> it looks like bitbake bzip2-native does nothing
Mar 14 11:34:37 <rburton> its not re-running fetch
Mar 14 11:34:44 <rburton> or unpack, or extract
Mar 14 11:34:57 <rburton> which makes me think your cleanall didn't work, and you just used rm
Mar 14 11:35:15 <diego_r> and so does bitbake -ccleanall bzip2-native. Nothing. All the files (even older log.do_configure) are still there
Mar 14 11:35:32 <diego_r> I get the error when I try "bitbake bzip2", without native
Mar 14 11:35:46 <diego_r> rburton: I'm guilty
Mar 14 11:36:08 <rburton> cleanall won't delete the logs
Mar 14 11:36:15 <rburton> but you can't mix up bzip2 and bzip2-native
Mar 14 11:36:22 <diego_r> rburton: is that a crime against humanity?
Mar 14 11:38:35 <diego_r> what do you suggest to try to fix the situation?
Mar 14 11:39:45 <rburton> start from clean.  bitbake -ccleanall bzip2 bzip2-native
Mar 14 11:41:37 <diego_r> rburton: still the configure.ac error. Looks like it isn't even trying to fetch it
Mar 14 11:42:03 <rburton> yeah, that's what i said.  sure you've no local changes?
Mar 14 11:43:28 <diego_r> I just cherry-picked commit 937663bdeca6d6479e0db2a9578588b1aa20222c in dora but the same error was there even before
Mar 14 11:47:08 <diego_r> no traces of fetching.
Mar 14 11:50:16 <diego_r> btw, bzip2 has mostly "temp/log.do_cleanall" files, while bzip2-native has still the "log.do_configure" and "run.autotools_preconfigure"
Mar 14 11:54:59 <diego_r> I'm quite sure bzip2-native is trying to run do_configure before having any do_fetch
Mar 14 12:04:41 <diego_r> how strange "bitbake -c fetch bzip2-native" and "bitbake -c fetch bzip2" seem to do nothing
Mar 14 12:28:12 <otavio> tf: around?
Mar 14 12:28:31 <tf> otavio: I am, unusually
Mar 14 12:28:50 <otavio> tf: patches for meta-clutter; where to send?
Mar 14 12:29:56 <tf> otavio: I can make you a contributor, if you want?
Mar 14 12:30:16 <otavio> tf: it works
Mar 14 12:30:33 <otavio> tf: but I need someone for guidance as I am not quite used to those
Mar 14 12:31:02 <tf> maybe we could get rburton involved here?
Mar 14 12:31:03 <bluelightning> the obvious question is, why not patch the recipes in OE-Core?
Mar 14 12:31:26 <otavio> tf: is someone working on getting it to work with master?
Mar 14 12:31:59 <otavio> tf: because current master seems to be for dora
Mar 14 12:32:01 <ionte> hi. i'm still working on replacing /etc/network/interfaces:
Mar 14 12:32:15 <otavio> bluelightning: some things are not in oe-core
Mar 14 12:32:25 <otavio> bluelightning: mutter, for example
Mar 14 12:32:33 <tf> otavio: nobody I know of, I am swamped with other work at the moment
Mar 14 12:32:57 <otavio> tf: someone from FSL did some patches for master
Mar 14 12:33:08 <otavio> tf: and get it working with imx6
Mar 14 12:33:22 <ionte> i have a custom layer, which works. in this layer i've created a bbappend file: recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
Mar 14 12:33:36 <otavio> tf: so I'd like to help upstreaming it so we don't lose this work
Mar 14 12:33:47 <ionte> i've also created a custom interfaces and put that in recipes-core/init-ifupdown/files/
Mar 14 12:34:28 <otavio> ionte: you need FILESEXTRAPATH_prepend in the bbappend
Mar 14 12:34:28 <ionte> and the bbappend contains two lines: FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
Mar 14 12:34:36 <otavio> oh ok
Mar 14 12:34:49 <ionte> and: PRINC := "${@int(PRINC) + 2}
Mar 14 12:34:59 <otavio> ionte: so this is parsing order in the bblayers.conf
Mar 14 12:35:15 <otavio> ionte: PRINC is not need for Dora and beyond
Mar 14 12:35:40 <ionte> still the interfaces is not replaced... if i change the version of the bbappend (init-ifupdown_0.9.bbappend) bitbake complains, so it seems to find it...
Mar 14 12:35:43 <ionte> otavio: ok
Mar 14 12:36:06 <ionte> otavio: parsing order? do my layer need to be put before "meta" in bblayers.conf?
Mar 14 12:36:13 <ionte> i've set priority of the layer to 0
Mar 14 12:36:50 <ionte> in layer.conf
Mar 14 12:37:14 <otavio> ionte: set the priority to 6, 7
Mar 14 12:37:34 <otavio> ionte: and yes. the order is important
Mar 14 12:37:34 <ionte> otavio: i thought lower number was higher priority...
Mar 14 12:38:21 <ionte> otavio: how does priority and order relate then?
Mar 14 12:38:24 <tf> otavio: what's your github id?
Mar 14 12:38:31 <otavio> tf: otavio
Mar 14 12:39:04 <ionte> tried with priority 10, but it still does not work
Mar 14 12:39:35 <otavio> ionte: the recipes are parsed in the BBLAYERS order
Mar 14 12:39:38 <tf> otavio: OK, you should have access to the github repo now
Mar 14 12:39:47 <otavio> tf: thx
Mar 14 12:39:58 <otavio> tf: I will make a wip/otavio there
Mar 14 12:40:06 <otavio> tf: and ask for review
Mar 14 12:40:17 <tf> of course, anything that makes sense to push to -core would be good there
Mar 14 12:40:24 <otavio> tf: sure
Mar 14 12:40:27 <tf> I think rburton is the maintainer
Mar 14 12:40:34 <otavio> tf: I will make a dora branch as well
Mar 14 12:40:44 <ionte> otavio: so layers overriding/appending to other recipes must be placed before the layers that are overridden in bblayers.conf?
Mar 14 12:41:29 <otavio> ionte: I'd say later; but I don't recall
Mar 14 12:41:39 <otavio> ionte: but I dealt with an issue due thi
Mar 14 12:41:41 <otavio> this
Mar 14 12:42:50 <ionte> otavio: ok. looking at the default bblayers.conf files they typically start with "meta", then "meta-yocto", "meta-yocto-bsp". that indicates that they must be placed after ... but my layer is already placed last in bblayers.conf...
Mar 14 12:45:41 <ionte> interesting. build/tmp-eglibc/work/qemux86-oe-linux/init-ifupdown/1.0-r5/interfaces is my custom interfaces. yet the default version is installed on the image.....
Mar 14 13:16:05 <sce_> rburton, even brokensep does not wokr
Mar 14 13:26:38 <kab0naresuzu> Hi, I'm working on the meta-intel GIT repository.
Mar 14 13:26:51 <kab0naresuzu> This beats building LFS. Yocto meets our requirement neatly.
Mar 14 13:44:19 <bluelightning> ionte: maybe yours is not the only init-ifupdown bbappend that is being applied for the machine you are building for?
Mar 14 13:44:36 <bluelightning> kab0naresuzu: great!
Mar 14 13:45:58 <kab0naresuzu> bluelightning: yes, very. I just landed my first contract as a Linux Distribution Manager... I'm building the first iteration via the tools, monitoring my disk usage because resources are tight... I keep having to clear out files to make room.
Mar 14 13:46:50 <kab0naresuzu> I have been working with Linux for 5 years in a professional capacity... Mostly on a redistribution of Debian targeted at Fully-Automated Install/Virtualization.
Mar 14 13:47:35 <kab0naresuzu> It's my understand that after I build via Yocto, I can image this to a drive and load it onto the hardware -- then develop Linux as usual.
Mar 14 13:47:53 <ionte> bluelightning: i'm looking for others now (find . -name "init-ifupdown*.bbappend"). so far i've only found one in meta-yocto-bsp but that layer is not in my bblayers.conf (i have only "meta" and "meta-mylayer" in it)
Mar 14 13:48:41 <bluelightning> kab0naresuzu: right, that is one possibility; we're pretty flexible as far as developer workflow goes (perhaps a little too much)
Mar 14 13:48:59 <bluelightning> ionte: try bitbake-layers show-appends
Mar 14 13:49:04 <kab0naresuzu> ionte: What's your problem statement? I'm familiar with the init daemon.
Mar 14 13:49:36 <ionte> kab0naresuzu: i want to change the default /etc/network/interfaces
Mar 14 13:49:46 <kab0naresuzu> Why not edit the file directly?
Mar 14 13:49:51 <kab0naresuzu> I write to it with Scripts in my project.
Mar 14 13:50:17 <ionte> kab0naresuzu: i've created a custom layer, and an bbappend for init-ifupdown that adds a custom interfaces. but that does not work...
Mar 14 13:50:31 <kab0naresuzu> It sounds like we have similar requirements.
Mar 14 13:50:34 <ionte> kab0naresuzu: i don't think that's the best workflow...
Mar 14 13:50:52 <kab0naresuzu> No, it's not. It's something that I hammered out in a day.
Mar 14 13:50:59 <bluelightning> kab0naresuzu: for reproducible builds it's best to do the customisation at the metadata / source level
Mar 14 13:51:16 <bluelightning> slightly more work for a better long-term result
Mar 14 13:51:35 <ionte> after reading way too much code i saw there was an exact example in the yocto bsp documentation, that does exactly what i do.. but it still does not work...
Mar 14 13:52:11 <kab0naresuzu> Some other devs in my organization handed me a firefox + javascript plugin which button-interfaces with the filesystem. I'm using the iNotify Kernel feature to watch for files; then take action based on file created to spawn dialogs / configure network interfaces.
Mar 14 13:52:18 <ionte> bluelightning: show-appends lists only my inif-ifupdown recipe...
Mar 14 13:52:57 <ionte> init-ifupdown...
Mar 14 13:55:18 <ionte> ok, could someone explain the build/tmp-eglibc/work directories for me? work/qemux86-oe-linux/init-ifupdown/1.0-r5/interfaces is my custom file, but work/qemux86-oe-linux/griffin-image/1.0-r0/rootfs/etc/network/interfaces is the default...
Mar 14 13:55:35 <ionte> (griffin-image is my custom image recipe, which inherits "image")
Mar 14 13:55:41 <kab0naresuzu> bluelightning: based on my problem statement (required interface with interactive browser buttons that spawn files that indicate action and configuration to execute)... Do you think I will require to build an ifupdown script for persistent configuration based on contents of /etc/network/interfaces and /etc/wvdial.conf ?
Mar 14 13:57:51 <kab0naresuzu> well, it looks like I require porting WVDial from Yocto-Classic to Poky... So I'll make a contrib on the Weaver-Dial PPPDaemon wrapper. I'll drop a question here if I get stuck, but I am confident that I understand bitbake recipes well enough. Thanks!
Mar 14 14:01:18 <abcd> dfd
Mar 14 14:04:20 <ionte> argh...
Mar 14 14:04:38 <ionte> i replaced "inherit image" with "inherit core-image" and now it works...
Mar 14 14:04:50 <ionte> why, oh, why ...
Mar 14 14:04:56 <sce_> hello
Mar 14 14:05:14 <sce_> is there someone who could help me with autotools recipe and build directory
Mar 14 14:05:23 <sce_> i would like to build in the source directory
Mar 14 14:05:29 <sce_> executing autogen.sh
Mar 14 14:05:48 <sce_> but the build system goes always in package/build
Mar 14 14:05:58 <sce_> S is different from B
Mar 14 14:06:04 <sce_> i would like to S = B
Mar 14 14:06:12 <sce_> i would like to have S = B
Mar 14 14:07:13 <sce_> i dotn understand the condition ...:(
Mar 14 14:07:24 <bluelightning> kab0naresuzu: FYI there is a wvdial recipe in meta-oe: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=wvdial
Mar 14 14:07:52 <bluelightning> so it's not really porting, it should just work
Mar 14 14:10:01 <kab0naresuzu> bluelightning: Thanks. Are there any equivalents to xmessage/gxmesage?
Mar 14 14:10:27 <kab0naresuzu> And yes there are.... It looks like there are a few options.
Mar 14 14:12:35 <ionte> dammit! so... i changed my image to inherit from "core-image", and suddenly my custom interfaces-file was installed. then i switched back to inheriting from "image", but now my custom interfaces-file was STILL used!
Mar 14 14:13:16 <ionte> does bitbake/yocto/whatever not notice all changes? do i need to clean my working directory before rebuilding?
Mar 14 14:14:38 <bluelightning> ionte: which version of the build system are you using?
Mar 14 14:17:23 <ionte> bluelightning: 1.5.1
Mar 14 14:17:36 <bluelightning> ionte: usually it will; however there are some corner cases e.g. if you built with the bbappend in place but your custom interfaces file not there (and you'd have received a warning) then moving it into place and building would not trigger a rebuild
Mar 14 14:18:20 <ionte> bluelightning: ok, that or something similar may very well have happened
Mar 14 14:19:31 <ionte> but if i update my custom interfaces file i hope rootfs will be rebuilt...?
Mar 14 14:20:55 <kab0naresuzu> Where is Yocto @ with CedarTrail/CedarView and PVR Graphics?
Mar 14 14:21:41 <bluelightning> ionte: yes
Mar 14 14:23:04 <rburton> sce_: as i said earlier, inherit autotools-brokensep instead of autotools to have S=B
Mar 14 14:23:15 <sce_> it was not working
Mar 14 14:23:20 <sce_> i'm using dora branch
Mar 14 14:23:29 <bluelightning> kab0naresuzu: last I heard, the specific cedartrail BSP was only supported on an earlier version of the build system, but I'm not really the best person to advise
Mar 14 14:23:36 <sce_> and even if used the class file it was not working
Mar 14 14:23:49 <sce_> i found out why it was not woking
Mar 14 14:23:51 <bluelightning> kab0naresuzu: coincidentally dvhart has just arrived - Darren can you confirm? ^
Mar 14 14:23:52 <sce_> working
Mar 14 14:24:16 <sce_> seperatedbuilddir.inc
Mar 14 14:24:32 <sce_> gst-plugins-bad was using a seperate build dir
Mar 14 14:24:55 <sce_> so i had to add B_pn-gst-plugins-bad = "${S}"
Mar 14 14:24:59 <sce_> in my recipe
Mar 14 14:25:04 <rburton> in the recipe you can just use S
Mar 14 14:25:08 <rburton> i meant B
Mar 14 14:26:14 <bluelightning> sce_: you shouldn't need to do that though, unless you are building a different version of gst-plugins-bad - if we set that it means we tested it and it works
Mar 14 14:27:20 <bluelightning> rburton: I don't think you could if B_pn-gst-plugins-bad is set in the inc file since that override would take precedence
Mar 14 14:27:36 <sce_> i'm trying to build the git version seen that in gst-plugins-bad 0.10.23 there is no eglglessink, i need on rpi
Mar 14 14:28:51 <bluelightning> sce_: I would advise looking at the gstreamer-1.0-plugins-bad recipe instead
Mar 14 14:29:12 <sce_> yes i know but i'm using a software which is using gstreamer-0.10 api
Mar 14 14:29:14 <rburton> sce_: i still recommend making a diff from 0.10.23 to master for the plguin you want to work
Mar 14 14:29:35 <sce_> the plugin does not exist and the amount of patch is important
Mar 14 14:29:43 <sce_> the plugin does not exist and the amount of patches is important
Mar 14 14:30:13 <rburton> a diff from 0.10.23 to master will be a single patch :)
Mar 14 14:30:38 <sce_> yes but this is not the same way to build anymore
Mar 14 14:30:59 <sce_> and i wanted to see the effort to do that
Mar 14 14:31:02 <sce_> :)
Mar 14 14:31:18 <rburton> its almost like someone needs to make a release of 0.10.24
Mar 14 14:31:19 <sce_> its a big effort to support eglgles in 0.10 :)
Mar 14 14:31:33 <sce_> yes it could be nice :)
Mar 14 14:32:05 <sce_> i dont know why there is no release, i guess they are pushing 1.0 now
Mar 14 14:34:05 * dvhart looks up
Mar 14 14:34:10 <dvhart> sorry was away until now
Mar 14 14:34:44 <bluelightning> dvhart: the question was about PVR on cedartrail - that BSP isn't supported anymore with current releases right? is there an alternative?
Mar 14 14:35:14 <dvhart> right, the org only supports cedar trail through..... checking
Mar 14 14:35:53 <dvhart> through danny
Mar 14 14:36:26 <dvhart> which is a 3.0 kernel
Mar 14 14:36:54 <dvhart> If you have interest in updated support for the board, please email the list and Cc the maintainers listed in the README file
Mar 14 14:37:05 <bluelightning> kab0naresuzu: ^
Mar 14 14:38:00 <dvhart> I believe the limiting factor here is the PVR driver
Mar 14 14:38:25 <dvhart> (raise your hand if you're surprised)
Mar 14 14:39:25 * diego_r not suprised at all
Mar 14 14:41:37 <bluelightning> dvhart: ok, thanks for the clarification
Mar 14 14:41:53 <dvhart> wish I had more palatable news to report
Mar 14 14:48:13 <kab0naresuzu> dvhart: thank you
Mar 14 14:49:04 <kab0naresuzu> dvhart: Thanks for putting me on the right track.
Mar 14 14:49:06 <dvhart> kab0naresuzu, please do email the list and the maintainer - if the request doesn't come in, it's more difficult to persuade people to upgrade it.
Mar 14 14:49:35 <kab0naresuzu> I'll CC them after I update it. I have somethings I'd like to try against the PVR driver.
Mar 14 14:49:45 <dvhart> great
Mar 14 14:50:13 <kab0naresuzu> Right now I am building on Kernel 3.4... so it should, likely, revert to VESA drivers if the i915 doesn't work.
Mar 14 14:50:47 <dvhart> right, that would be my expectation - provided you are building with VESA enabled and the Xorg VESA driver included
Mar 14 14:51:43 <kab0naresuzu> I'm so deep into the compile, that quitting this iteration would have wasted 3 hours; I have a hard deadline for Friday to put this together. I already have the application layer implemented on a more heavyweight distro.
Mar 14 14:52:15 <dvhart> 3 hours? that's an awful long build cycle
Mar 14 15:07:00 <ionte> bluelightning: unfortunately updating the interfaces-file in my recipe does not rebuild the rootfs :(
Mar 14 15:10:25 <bluelightning> ionte: I don't know how to explain that; it's supposed to
Mar 14 16:34:15 <lpapp> hi, interesting that no one "packaged" ntpclient or something other tiny implementation of the ntp protocol for oe-core?
Mar 14 16:34:33 <lpapp> it seems to be about 20 K, and somewhat essential a functionality, so I would imagine this is ok for oe-core?
Mar 14 16:35:06 <kergoth> RP: any objection to making the 'oe' python package a namespace package? being able to add modules to it from external layers would be convenient, and might also open up the possibility of overriding individual modules to stage fixes before they hit upstream (Not sure about that, haven't tested it)
Mar 14 16:35:23 <rburton> lpapp: ntpdate is part of ntp in meta-networking
Mar 14 16:35:34 <kergoth> RP: http://docs.python.org/2/library/pkgutil.html#pkgutil.extend_path
Mar 14 16:35:35 <lpapp> rburton: ntpdate is obsolete.
Mar 14 16:36:23 <lpapp> it is also very big, 112 K.
Mar 14 16:36:41 <rburton> feel free to package something else and send it to meta-networking i guess
Mar 14 16:37:01 <bluelightning> lpapp: er, how about the module in busybox?
Mar 14 16:37:25 <lpapp> bluelightning: oh, busybox has one, interesting. :)
Mar 14 16:37:41 <lpapp> bluelightning: let me see how big that one is.
Mar 14 16:37:51 <lpapp> (currently it is disabled, so I will need to rebuild busybox)
Mar 14 16:38:09 <rburton> i thought you had no networking so just need a one-shot time setter?
Mar 14 16:38:49 <lpapp> rburton: yeah, that was the idea, but some people prefer ntpd. :)
Mar 14 16:38:56 <lpapp> so it would be optional.
Mar 14 16:40:00 <lpapp> rburton: we have ethernet connection, so it is theoretically possible. It is just new a feature request.
Mar 14 16:48:46 <lpapp> is there an option for opkg to look for similarly named packages installed? Something like dpkg -l on debian based systems.
Mar 14 16:49:19 <rburton> opkg list_installed
Mar 14 16:49:30 <rburton> (opkg —help lists all the commands)
Mar 14 16:49:35 <rburton> you'll need to use grep to filter it, iirc
Mar 14 16:50:01 <lpapp> yes, that is my issue with that.
Mar 14 16:50:09 <lpapp> with dpkg -l, you do not need to.
Mar 14 16:50:17 <rburton> so use dpkg then :)
Mar 14 16:51:52 <lpapp> :D
Mar 14 17:00:04 <lpapp> rburton: thanks either way. :)
Mar 14 17:00:16 <lpapp> bluelightning: thanks to you, too, for the busybox idea, it worked for the first time!
Mar 14 17:00:28 <lpapp> I have spent 1-2 days to try to configure the reference implementation properly without success.
Mar 14 17:04:43 <kab0naresuzu> :: ERROR: ParseError at /home/demo/Yocto/meta-intel/common/recipes-graphics/xorg-driver/emgd-driver-bin_1.16.bb:39: Could not inherit file classes/distro_features_check.bbclass
Mar 14 17:05:01 <kergoth> sounds like a branch mismatch between your layers
Mar 14 17:05:07 <kab0naresuzu> Attempting to build meta-intel/meta-cedartrail...
Mar 14 17:05:08 <rburton> kab0naresuzu: probably you're using meta-intel master against a release of poky/oe-core
Mar 14 17:05:11 <kergoth> (its amazing how often that happens)
Mar 14 17:05:16 <kab0naresuzu> I am.
Mar 14 17:05:28 <kergoth> not going to work, use the release branch corresponding to that release
Mar 14 17:05:40 <kab0naresuzu> So I would need Danny.
Mar 14 17:05:55 <kergoth> assuming that's the release in question, yes, you haven't said :)
Mar 14 17:10:48 <dvhart> kab0naresuzu, yes, always match layer versions
Mar 14 17:11:29 <kab0naresuzu>  wgett'n
Mar 14 17:11:46 <dvhart> kergoth, it does happen an awful lot doesn't it - maybe we could come up with a way to match version dependencies and fail, or at *least* warn
Mar 14 17:12:05 <dvhart> rather than expose new folks to esoteric bitbake errors right off the bat...
Mar 14 17:12:58 <kab0naresuzu> I'm here to be exposed to esoteric errors.
Mar 14 17:13:20 <rburton> some form of "compatible with oe-core version" list in the layer would be nice
Mar 14 17:13:23 <kergoth> yeah, thats what i was just thinking about too. we do hae layer dependencies with layer versions, but i don't know that we want to impose a hard line on the release boundary or not.. there's likely value there, though
Mar 14 17:13:29 <dvhart> kab0naresuzu, then you've come to the right place .....
Mar 14 17:13:38 <rburton> so bitbake would warn if you had a layer that wasn't actually tested with the version you have
Mar 14 17:13:41 <kab0naresuzu> No doubt... I'm working on PVR.
Mar 14 17:13:43 <kergoth> rburton: bitbake supports layer versions and required layer versions in layerdepends
Mar 14 17:13:47 <kergoth> rburton: just nobody really uses it
Mar 14 17:14:01 <rburton> kergoth: clearly we need to look at doing that in meta-intel and seeing how well it works
Mar 14 17:14:15 <kergoth> definitely sounds worth looking into
Mar 14 17:14:35 <kergoth> we get someone runniing into this a few times a week, it feels like, anyway
Mar 14 17:14:35 <dvhart> rburton, could you be persuaded to spend a few minutes with me next week to get started on that?
Mar 14 17:14:37 <kergoth> heh
Mar 14 17:14:42 <dvhart> at least
Mar 14 17:14:46 <rburton> dvhart: sure
Mar 14 17:14:51 <dvhart> and that's just the public ones
Mar 14 17:15:06 <kergoth> yeah, who knows how many folks just hit the failures and give up
Mar 14 17:15:18 <rburton> dvhart: remind me next week :)
Mar 14 17:15:25 <dvhart> yup
Mar 14 17:20:01 <bluelightning> rburton: kergoth: can't anymore, because that stuff was co-opted for the autobuilder versioning :/
Mar 14 17:20:33 <rburton> !
Mar 14 17:20:34 <rburton> damnit
Mar 14 17:26:16 <kab0naresuzu> What is the best way to redistribute Yocto-based distributions? I should just be able to image the drive and go, right?
Mar 14 17:26:42 <dvhart> kab0naresuzu, hddimg is a reasonable approach
Mar 14 17:26:48 <dvhart> dd
Mar 14 17:27:04 <kab0naresuzu> That's out of my control, really...
Mar 14 17:27:06 <dvhart> I presume you are PCBIOS, not EFI?
Mar 14 17:27:14 <kab0naresuzu> They have some kind of Star-Tech OEM HDD imager in the warehouse...
Mar 14 17:27:22 <kab0naresuzu> I don't work in Distribution. I'm in Development.
Mar 14 17:27:34 <dvhart> OK, what are you asking?
Mar 14 17:27:52 <kab0naresuzu> Well, the last time I tried to run an image off the Star-Tech OEM disk imager... The file-system came out corrupted.
Mar 14 17:28:08 <kab0naresuzu> So FSCK had to be run before boot. I know dd is a far superior tool.
Mar 14 17:28:30 <kergoth> bluelightning: maybe we need layer virtuals ;) LAYERPROVIDES_foo += "virtual/foo:1.0"
Mar 14 17:28:33 * kergoth shudders
Mar 14 17:29:13 <bluelightning> kergoth: yucky as that might be it would be a simple solution
Mar 14 17:29:16 <dvhart> kab0naresuzu, OK, yes, in theory, once you have an HDD in the form you want, you should be able to clone it and write back to other media
Mar 14 17:30:10 <dvhart> but you asked what the best way was, and stipulated that it be done with a disk imager... so... not sure what else we can say?
Mar 14 17:30:48 <kab0naresuzu> That's about it. Thank you. I'm going to read up on the Linux Kernel while I wait for this build to finish.
Mar 14 17:30:49 <dvhart> deployment is a fairly involved topic too - e.g. do you have in field update requirements?
Mar 14 17:30:56 <kab0naresuzu> Yes, we do...
Mar 14 17:31:03 <kab0naresuzu> It's implemented via cookies that refresh on-boot.
Mar 14 17:31:43 <kab0naresuzu> We're leaning heavily on iNotify, as well... The browser detects the patch level within the cookie and, if it needs a patch, sends an HTTPS downstream.
Mar 14 17:32:15 <kab0naresuzu> That one... Definitely not my idea. It was originally implemented like that by a nameless, huge enterprise in the late 90s.
Mar 14 17:33:51 <kab0naresuzu> My opinion is that it makes patching and management more difficult (i.e., if a patch is required, it has to be written in bash.) Does Yocto have a system for in-field updates?
Mar 14 17:38:46 <kergoth> some distros use package management as the upgrade mechanism, with feeds. others distribute full images. its really a distro level support question than yocto in general
Mar 14 17:39:21 <dvhart> agreed
Mar 14 17:39:39 <dvhart> although in terms of what yocto provides, we create packages
Mar 14 17:39:51 <dvhart> and images I suppose
Mar 14 17:40:25 <dvhart> but we do basically punt there and leave it to the distro/product teams to do what is best for them.
Mar 14 17:42:12 <kab0naresuzu> Makes sense to me.
Mar 14 17:42:56 <rburton> kergoth: fwiw, i really want to look at integrating ostree into yocto
Mar 14 17:43:08 <rburton> kergoth: but now i have kids that need a bath
Mar 14 19:35:33 <Uzzair> Hi All :)
Mar 14 20:01:20 <kab0naresuzu> How much space is typically required to run a Yocto Build?
Mar 14 20:01:30 <kab0naresuzu> I am 1094 / 5060 into it...
Mar 14 20:01:48 <kab0naresuzu> Running off a live-debian/minimal-unstable install...
Mar 14 20:01:51 <kergoth> 20gb maybe? depends on what you're building, and whether rm_work is involved. i haven't measured a build size recently myself
Mar 14 20:01:56 <kab0naresuzu> O:
Mar 14 20:02:06 <kab0naresuzu> I have 12G avail.
Mar 14 20:02:18 <kab0naresuzu> I'll wait for it to run out
Mar 14 20:02:19 <kab0naresuzu> unmount
Mar 14 20:02:23 <kab0naresuzu> and remount this on a bigger drive
Mar 14 20:02:25 <kab0naresuzu> Then, I'll be good
Mar 14 20:02:28 <kab0naresuzu> Thanks for the tip!
Mar 14 20:02:43 <kab0naresuzu> core-image-sato
Mar 14 20:02:46 <kab0naresuzu> (I think)
Mar 14 20:07:19 <dvhart> my build dir for an x86 machine building core-image-sati is ... du is slow..., but my downloads dir is 7.1 GB (lots of history there)
Mar 14 20:09:11 <kergoth> hmm, wonder if i should set up a periodic downloads dir clean based on access tiem within the past week or two, the way i do with my sstate archive
Mar 14 20:09:14 <kergoth> :)
Mar 14 20:09:21 <kab0naresuzu> This is pretty ridiculous... I'm looking at my {fdisk -l} and storage device stats... Apparently, my root part is mounted on a 16GB flash drive -- while my home part somehow got mounted on the 32GB SSD...
Mar 14 20:09:25 <kab0naresuzu> oops.
Mar 14 20:09:30 <kab0naresuzu> looks like I'm going to leave this flash drive plugged in for a while.
Mar 14 20:09:31 <dvhart> kergoth, a pretty good idea
Mar 14 20:09:35 <dvhart> I should do the same
Mar 14 20:09:55 <kab0naresuzu> kergoth: would you put that in cron.d?
Mar 14 20:11:47 <dvhart> kergoth, and the script should go in scripts/contrib :-)
Mar 14 20:18:58 <dvhart> kab0naresuzu, build dir is 49 GB
Mar 14 20:19:16 <dvhart> I typically recommend at least 100GB of free space
Mar 14 20:31:48 <kergoth> dvhart: heh, i like the sstate-cache-management stuff, but I have a hard time getting it to identify everything i might need to build, many combinations of layers, branches, etc. access time ends up being the dumb, but effective, approach :)
Mar 14 20:32:16 <dvhart> makes sense
Mar 14 20:32:32 <kergoth> of course, having atime enabled on a build drive can be painful, i end up using a separate cache partition
Mar 14 20:32:49 <dvhart> ah... right, I do disable atime
Mar 14 20:32:55 <kergoth> :)
Mar 14 20:33:15 <dvhart> (and the journal, and a 10 hour commit interval, and......)
Mar 14 20:33:20 <kergoth> having it write every tiem you do a read, definitely not pleasant :)
Mar 14 20:34:21 <kergoth> I use https://gist.github.com/kergoth/9556209 for my sstate. not perfect, and its more complex than most folks likely need, but i have multiple caches. most use the global one, but sometimes i'll kill the symlink to the global to do local testing, or to look at a subset of the cache
Mar 14 20:34:48 <dvhart> thanks for the link
Mar 14 20:35:21 <kergoth> the key being find's -atime +6 for older than 7 days ago :)
Mar 14 21:03:07 <mr_science> kab0naresuzu: we use a disk duplicator to load our ssd's in manufacturing
Mar 14 21:03:47 <mr_science> the release build only gets installed the "normal" way once to a "master" ssd
Mar 14 22:26:18 <mr_science> Crofton: see the wiki page yet?
**** ENDING LOGGING AT Sat Mar 15 02:59:58 2014