**** BEGIN LOGGING AT Fri May 06 02:59:58 2011
May 06 06:59:56 <risca> Good morning =)
May 06 07:10:52 <bluelightning> morning all
May 06 07:13:48 <ka6sox-home> morning...
May 06 07:13:53 <ka6sox-home> pb_, you up yet?
May 06 07:22:14 <eFfeM_work> hi ka6sox-home, bluelightning, all
May 06 07:22:50 <ka6sox-home> mourning :D
May 06 07:24:04 <eFfeM_work> ka6sox-home: cheer up!
May 06 07:28:53 <ka6sox-home> too many 19hr days in a row
May 06 07:29:45 <eFfeM_work> hm, that's no good
May 06 07:29:47 <eFfeM_work> gm woglinde
May 06 07:30:24 <eFfeM_work> ka6sox-home: wind down, settle priorities and relax every once in a while, there is more in life than work
May 06 07:31:53 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r97d339ad07 10openembedded.git/recipes/libdaemon/libdaemon_0.13.bb: 
May 06 07:31:53 <CIA-32> libdaemon: update to 0.14
May 06 07:31:54 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 07:31:57 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb3ad4e11b2 10openembedded.git/recipes/avahi/ (avahi.inc avahi_0.6.30.bb): 
May 06 07:31:57 <CIA-32> avahi: add 0.6.30
May 06 07:31:57 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 07:32:04 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc062f83ab2 10openembedded.git/recipes/udev/udev_165.bb: 
May 06 07:32:04 <CIA-32> udev 165: package systemd files when present
May 06 07:32:04 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 07:32:04 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r32881acb70 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: 
May 06 07:32:04 <CIA-32> angstrom v2010: prefer avahi 0.6.30
May 06 07:32:05 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 07:32:05 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * red5f4802ea 10openembedded.git/recipes/angstrom/angstrom-version.bb: 
May 06 07:32:06 <CIA-32> angstrom-version: also provide /etc/os-release
May 06 07:32:06 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 07:32:59 <ka6sox-home> I'm listening to music, having a glass of wine and thinking about sleep D:
May 06 07:33:21 <eFfeM_work> :-) enjoy!
May 06 07:34:07 <ka6sox-home> well..I hope since WR is supporting Cavium that means that Yocto will support them too.
May 06 07:34:44 <eFfeM_work> WR ?
May 06 07:35:22 <ka6sox-home> Wind River
May 06 07:35:30 <eFfeM_work> ah ok
May 06 07:37:48 <ka6sox-home> okay I guess its too early for pb_, so I'll catch him on the other side of sleep.
May 06 07:37:56 <eFfeM_work> hi obi
May 06 07:38:09 <obi> good morning!
May 06 07:38:10 <eFfeM_work> ka6sox-home: nite!
May 06 08:05:01 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r1f14659d5e 10openembedded.git/recipes/systemd/ (9 files in 3 dirs): 
May 06 08:05:01 <CIA-32> systemd: update to v26
May 06 08:05:01 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 08:05:22 <woglinde_> hi obi
May 06 08:10:23 <woglinde_> gm mickeyl
May 06 08:15:32 <mickey|office> morning woglinde_ 
May 06 08:16:53 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r00108ef708 10openembedded.git/recipes/dbus/dbus.inc: 
May 06 08:16:53 <CIA-32> dbus: package systemd files
May 06 08:16:53 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 08:24:47 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb358a36dd3 10openembedded.git/recipes/rsyslog/ (5 files in 2 dirs): rsyslog: add 5.8.0
May 06 08:27:52 <CIA-32> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r5ea1842c89 10openembedded.git/ (3 files in 3 dirs): 
May 06 08:27:52 <CIA-32> linux-nokia900-meego: add few modules to defconfig and reenable CMDLINE
May 06 08:27:52 <CIA-32> * be aware that SRCPV sorts still lower because
May 06 08:27:52 <CIA-32> 4dc381db40ecd82cf885515f3733767899948484 changed branch without PE
May 06 08:27:52 <CIA-32> bump and SRCPV started from 0 again..
May 06 08:27:52 <CIA-32> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 06 08:28:00 <CIA-32> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * rdaab5afcad 10openembedded.git/recipes/u-boot/u-boot-git/nokia900/0001-configs-nokia_rx51.h-start-shr-as-default-and-change.patch: 
May 06 08:28:00 <CIA-32> u-boot: switch root= from mmcblk1 to mmcblk0 in shr config
May 06 08:28:00 <CIA-32> * PR wasn't bumped because other distributions/machines don't deserve
May 06 08:28:00 <CIA-32> needless noise without any change for them (and I've already built
May 06 08:28:00 <CIA-32> newer u-boot for SHR)
May 06 08:28:00 <CIA-32> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 06 09:20:16 <vanner_> i hava a few own packages and tried include to build with oe. first package use autotools and install corrected. second packages instaled manually. package compiled, in work dir created folder image with all files, but files not copyed to sysrootf. how to make it?
May 06 09:47:47 <ant_work> pls define/paste " instaled manually"
May 06 09:52:52 <pb_> hi ant_work
May 06 09:53:13 <ant_work> pb_: hey, nice to see you back
May 06 09:54:51 <vanner_> ant_work: do_install () { oe_runmake CC="${CC}" INSTALL_PREFIX="${D}" install }
May 06 09:55:51 <ant_work> have you tried removing your do_install ?
May 06 09:56:40 <vanner_> ok, i'll try it
May 06 09:56:41 <ant_work> seems it's doing nothing special
May 06 09:57:26 <ant_work> FYI http://wiki.openembedded.net/index.php/Legacy_staging
May 06 09:57:49 <pb_> you need some kind of do_install() if you're not using autotools; base.bbclass doesn't provide anything.
May 06 09:58:07 <ant_work> pb_: as native english speaker, do you think ^^^ is understandable ?
May 06 09:58:21 <ant_work> (for foreigers ;)
May 06 09:58:23 <pb_> arguably it might make sense for base_do_install() to do what autotools_do_install() currently does, but it doesn't do that today (afaik)
May 06 09:58:39 <pb_> the wiki page?  let me have a look
May 06 09:59:17 <pb_> ant_work: I had to read the first paragraph three times before I understood it
May 06 09:59:24 <ant_work> :)
May 06 09:59:48 <ant_work> that ',along' kills me
May 06 10:00:35 <ant_work> vanner_: I missed the no-autotools part :/
May 06 10:00:35 <pb_> yeah, it sort of runs off the rails at "... building rather than ..."
May 06 10:00:57 <pb_> it would be better if there was a comma after building, and no comma after "works"
May 06 10:01:10 <ant_work> best would be 2 examples: old/new style
May 06 10:01:18 <pb_> let me see if I can gain access to modify that page
May 06 10:01:27 <ant_work> great, thx
May 06 10:01:58 <pb_> hm, apparently not
May 06 10:02:05 <pb_> either I don't have a wiki account or I can't remember my username
May 06 10:02:29 <pb_> and, although there is a "Create a new account" link, it seems to be a joke
May 06 10:02:54 <ant_work> I did login now fwiw
May 06 10:55:18 <ant_work> pb_: once logged in, would you pls add that magic explanatino about -pn  http://tinyurl.com/6eve8uj
May 06 10:55:40 <ant_work> argh..on friday I cannot type anymore...
May 06 10:57:46 <pb_> yeah
May 06 10:58:08 <pb_> I'm not quite sure how to get an account.  apparently only the "administrators" can create them but there is no obvious clue on the wiki as to who they are.
May 06 10:58:55 <ant_work> iirc our XorA and Crofton have super-cow powers
May 06 10:59:33 <pb_> ah right, cool
May 06 10:59:51 <Crofton> ?
May 06 11:00:30 <Crofton> ah
May 06 11:00:40 <Crofton> accounts are disabled due to spammers
May 06 11:01:03 <Crofton> I am supposed to know what to do, but tried and failed yeasterday
May 06 11:01:35 <Crofton> however wmat (elinux editor) is going to help ka6sox with a better solutoin
May 06 11:01:48 <Crofton> pb_, did you have an account?
May 06 11:02:08 <pb_> I'm not sure.  I tried logging in with all the usernames I was likely to have used and none of them seemed to be recognised.
May 06 11:02:15 <pb_> so I'm guessing I probably don't have one, but I could be wrong
May 06 11:03:07 <Crofton> doesn't look like it
May 06 11:04:03 <pb_> can I create one manually from the shell?
May 06 11:04:10 <pb_> not that I have my melo key with me at the moment, but I could do that later
May 06 11:06:27 <Crofton> not usre
May 06 11:06:46 <Crofton> I'll defer to ka6sox-work, hopefully he a wmat solve this headache
May 06 11:07:06 <Crofton> elinux also uses mediawiki and I do not think they had to disable logins
May 06 11:07:50 <ant_work> fwiw I can still login
May 06 11:08:41 <ant_work> what I could not do was adding new pages iirc, that was locked
May 06 11:08:55 <ant_work> edit is allowed
May 06 11:12:02 <pb_> mickey|office: good morning
May 06 11:13:32 <Crofton> rofl graham growers email mirrors some of the questions from the yocto panel session at elc
May 06 11:18:03 <ant_work> btw should the link to openembedded-members appear together with the other ML?
May 06 11:18:25 * XorA has no cow powers on anything
May 06 11:18:55 <ant_work> (XorA != Larry the cow) ? exit0
May 06 11:23:38 <pb_> okay, thanks
May 06 11:23:40 <pb_> I will talk to tom
May 06 12:36:50 <mickey|office> good morning pb_ 
May 06 12:48:40 <otavio> Hello; who is doing merges on oe-core?
May 06 12:53:05 <JaMa|Wrk> you send pull request to oe-core list and RP merges it
May 06 12:56:52 <otavio> JaMa|Wrk: I did it and got no ack/nack on those and seems like oe-core has no change for days ...
May 06 12:57:20 <JaMa|Wrk> oe-core was changed 26hours ago
May 06 12:58:15 <JaMa|Wrk> and yes, sometimes it takes a while for someone to reply
May 06 13:25:05 <khem> otavio: patches to oe-core gets tested so saul or someone else should have pulled those in and eventually if all is fine they will get merged if you dont see an activity for a week then ping
May 06 13:29:56 <khem> kergoth: ping
May 06 13:41:46 <paepke> i'm wondering about bitbake/bin/install script. its missing a "t" in line 6 "while getopts ...". the recipe mozilla/nss-2.12.6.bb needs this switch.
May 06 13:41:54 <paepke> do i miss something else?
May 06 13:53:39 <foerster> paepke: http://cgit.openembedded.org/cgit.cgi/openembedded/log/bin/install
May 06 13:53:50 <foerster> -t was added march 22
May 06 14:00:59 <paepke> foerster: ah thx. was using 2011.03-maintanence
May 06 14:01:41 <foerster> paepke: you can ask that they pull that into 2011.03-maint
May 06 14:01:57 <paepke> foerster: on oe mailing list?
May 06 14:02:21 <foerster> paepke: yes, that's how I've seen it
May 06 14:03:31 <foerster> reference 2011.03-maintenance in the subject, probably include the commit hash and branch to pull from (oe.dev)
May 06 14:03:47 <foerster> and say why it's needed
May 06 14:06:16 <paepke> foerster: thx
May 06 14:06:21 <foerster> np
May 06 14:12:06 <supjigator> I'm having trouble builidng the am3517-evm.  Everything compiles but linux-omap-psp and it fails on musb
May 06 14:36:37 <CIA-32> 03Yu Ke <ke.yu@intel.com> 07master * r8e8ca00b35 10bitbake.git/lib/bb/fetch2/git.py: (log message trimmed)
May 06 14:36:37 <CIA-32> git fetcher: make tag back to work, fix Yocto bug 972
May 06 14:36:37 <CIA-32> In current git fetcher, tag does not work due to commit
May 06 14:36:37 <CIA-32> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=5920e85c561624e657c126df58f5c378a8950bbc.
May 06 14:36:37 <CIA-32> Tag is not in sha256 form, so it will be treated invalid, and silently replaced
May 06 14:36:38 <CIA-32> by latest revision.
May 06 14:36:38 <CIA-32> To fix it, this patch treat tag name as branches name, thus it will be handled correctly later. Thanks Richard for reviewing and proposing the better approach.
May 06 14:36:48 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r7d5642231f 10bitbake.git/lib/bb/codeparser.py: 
May 06 14:36:48 <CIA-32> bitbake/codeparser: Correctly handle a missing/empty cache file
May 06 14:36:48 <CIA-32> (From Poky rev: 72875493b8bbb5d6793380ee71c6bca4f438ca04)
May 06 14:36:48 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 14:36:50 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r2b0194b408 10bitbake.git/lib/bb/ (codeparser.py cooker.py): (log message trimmed)
May 06 14:36:50 <CIA-32> bitbake/cooker/codeparser: Ensure the code parser cache is saved for each parsing process
May 06 14:36:50 <CIA-32> Before this change, the codeparser cache was only being saved for the main
May 06 14:36:50 <CIA-32> server process. This is suboptimal as it leaves code being re-evaluated at
May 06 14:36:50 <CIA-32> task execution time and increases parse time.
May 06 14:36:50 <CIA-32> We use the multiprocess Finalize() functionality to ensure each process
May 06 14:36:51 <CIA-32> saves out its cache. We need to update the cache save function to be multiprocess
May 06 14:36:52 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * rddf498b487 10bitbake.git/lib/bb/ (cache.py parse/ast.py): 
May 06 14:36:52 <CIA-32> bitbake/ast.py: Only run finalise() for the specified variant
May 06 14:36:52 <CIA-32> Allows the heavy finalise function to only be run for the case we're
May 06 14:37:14 <CIA-32> interested in when running tasks, saving some processing time.
May 06 14:37:14 <CIA-32> (From Poky rev: 9211fd9c375489c73924fd43f1f8a0da2c4290bb)
May 06 14:37:14 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 14:37:14 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * rd4574ad906 10bitbake.git/lib/bb/ (cache.py cooker.py ui/knotty.py): 
May 06 14:37:14 <CIA-32> bitbake/cache.py: Ensure skipped recipes make it into the cache to avoid reparsing
May 06 14:37:16 <CIA-32> (From Poky rev: 001a555c2f755d4f8a69b113656d9307ca7ee597)
May 06 14:37:16 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 14:37:16 <CIA-32> 03Darren Hart <dvhart@linux.intel.com> 07master * re081b20c10 10bitbake.git/doc/manual/usermanual.xml: 
May 06 14:37:16 <CIA-32> correct typo in ??= documentation
May 06 14:37:17 <CIA-32> ??= is a lazy version of ?=
May 06 14:37:17 <CIA-32> (From Poky rev: 2ee0be82d065aeee716a9c0289bf111ea121e6dc)
May 06 14:37:18 <CIA-32> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
May 06 14:37:26 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 14:37:26 <CIA-32> 03Darren Hart <dvhart@linux.intel.com> 07master * r2884ecb471 10bitbake.git/doc/manual/Makefile: (log message trimmed)
May 06 14:37:26 <CIA-32> bitbake docs: use dblatex to build the pdf bitbake manual
May 06 14:37:26 <CIA-32> Fix [BUGID #593]
May 06 14:37:26 <CIA-32> The current manual build fails for printing formats which use latex as an
May 06 14:37:26 <CIA-32> intermediate format. This bug has been reported in multiple locations and I
May 06 14:37:27 <CIA-32> haven't found a solution posted to any of them.
May 06 14:37:27 <CIA-32> Using --with-dblatex uses dblatex to make the conversion and successfully
May 06 14:40:18 * JaMa|Wrk cheers
May 06 14:49:42 <JaMa|Wrk> RP: could you please push fix for "ERROR: Error parsing /OE/shr-core/meta-shr/recipes-shr/shr/libphone-ui_git.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception AttributeError: 'FetchData' object has no attribute 'branches'" if it's in poky's bitbake as patch?
May 06 14:50:06 <JaMa|Wrk> RP: it works with bitbake from poky and fails like this with master from oe
May 06 14:50:17 <JaMa|Wrk> kergoth: ^ maybe you know about fix
May 06 14:51:17 <Tartarus> yay
May 06 14:55:12 <Crofton> JaMa|Wrk, networkmanager patches updates
May 06 14:56:02 <JaMa|Wrk> seen it, or another one?
May 06 14:58:06 <kergoth> JaMa|Wrk: i don't track the fetch2 work very closely
May 06 15:00:47 <JaMa|Wrk> kergoth: ok
May 06 15:01:23 <kergoth> best for rp to pull them over to master.  would be nice if these things were fixed there directly..
May 06 15:01:23 <kergoth> heh
May 06 15:26:30 <JaMa|Wrk> RP: kergoth: I've merged those 2 AUTOREV fixing patches, is it worth sending to bitbake list or do you want to resolve conflicts yourself? :)
May 06 17:10:10 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r933350f801 10bitbake.git/lib/bb/build.py: 
May 06 17:10:10 <CIA-32> build.py: Fix ordering bug introduced in 7a29ab534388c0095f7f826b16c5cff343927d10
May 06 17:10:10 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 17:15:58 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * reb799b44ad 10bitbake.git/lib/bb/fetch2/ (__init__.py git.py): (log message trimmed)
May 06 17:15:59 <CIA-32> bitbake/fetch2/git: Fix a bug where AUTOREV and the git fetcher interact badly
May 06 17:15:59 <CIA-32> Fix a bug where ud.branches were being referenced before it was set by
May 06 17:15:59 <CIA-32> the git fetcher when using AUTOREV. To do this some ordering needed
May 06 17:15:59 <CIA-32> to be changed. This fixes errors like:
May 06 17:15:59 <CIA-32> ERROR: Error parsing /recipes-kernel/linux/rt-tests_git.bb: Failure expanding variable
May 06 17:16:00 <CIA-32> SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
May 06 17:16:00 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r12112102dd 10bitbake.git/lib/bb/fetch2/ (__init__.py bzr.py git.py hg.py svn.py): (log message trimmed)
May 06 17:16:01 <CIA-32> bitbake/fetch2: Fix the problems introduced by the git fetcher AUTOREV fix
May 06 17:16:01 <CIA-32> The ordering constrains on the urldata_init functions are not straight
May 06 17:16:02 <CIA-32> forward. To avoid further problems, create a helper function to setup
May 06 17:16:02 <CIA-32> the source revisions which the init functions can all at the appropriate
May 06 17:16:03 <CIA-32> point.
May 06 17:16:03 <CIA-32> (From Poky rev: c4371138f7444ecaa1fdd2b1ee4949fbc819f886)
May 06 17:22:09 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * r584df1efa0 10bitbake.git/lib/bb/fetch2/ (__init__.py local.py): (log message trimmed)
May 06 17:22:09 <CIA-32> bitbake/fetch2: Allow local file:// urls to be found on mirrors
May 06 17:22:09 <CIA-32> With the current implementation, file:// urls as used by sstate don't access the
May 06 17:22:09 <CIA-32> mirror code, breaking sstate mirror support. This change enables the usual
May 06 17:22:09 <CIA-32> mirror handling. To do this, we remove the localfile special case, using the basename
May 06 17:22:09 <CIA-32> paramemter instead. We also ensure the downloads directory is checked for files.
May 06 17:22:10 <CIA-32> The drawback of this change is that file urls containing "*" globing require special
May 06 17:22:15 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * rd98bded97c 10bitbake.git/lib/bb/fetch2/local.py: 
May 06 17:22:15 <CIA-32> bitbake/fetch2/local: Fix inverted update required logic
May 06 17:22:15 <CIA-32> (From Poky rev: 4f28cd2d1854df8e6f56544fe509fb2e3ddce9aa)
May 06 17:22:15 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 17:23:41 <Crofton|work> how often does patchwork update/
May 06 17:26:18 <CIA-32> 03Richard Purdie <richard.purdie@linuxfoundation.org> 07master * re4acd09735 10bitbake.git/lib/bb/utils.py: 
May 06 17:26:18 <CIA-32> bitbake/utils.py: Only try and add read access to a file if we don't have it
May 06 17:26:18 <CIA-32> A file we're copying might be on a readonly filesystem so if we can already read
May 06 17:26:18 <CIA-32> it, don't try and add read permission.
May 06 17:26:18 <CIA-32> Fixes BUGID #771 in Yocto.
May 06 17:26:18 <CIA-32> (From Poky rev: 9166b9e32fd6f618f9597b07d88cef09a88916a1)
May 06 17:26:19 <CIA-32> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
May 06 17:29:29 <Crofton|work> how clever ask when pw qill update and it does
May 06 17:30:25 <CIA-32> 03Koen Kooi <koen@dominion.thruhere.net> 07org.openembedded.dev * r1bdfd7d2bf 10openembedded.git/classes/package.bbclass: 
May 06 17:30:25 <CIA-32> package.bbclass: convert unpackaged file message from 'info' to 'warn' so that it shows up on the console
May 06 17:30:25 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 17:30:25 <CIA-32> Acked-by: Philip Balister <philip@balister.org>
May 06 17:30:25 <CIA-32> Acked-by: Eric Bénard <eric@eukrea.com>
May 06 17:30:26 <CIA-32> Signed-off-by: Philip Balister <philip@balister.org>
May 06 18:34:01 <khem> kergoth: around ?
May 06 18:40:08 <kergoth> khem: yeah, whats up
May 06 18:41:11 <khem> kergoth: how does BBFILES_PRIORITY kick in
May 06 18:41:45 <khem> I am trying to understand how a recipe contention from multiple layers is resolved by bitbake 
May 06 18:51:18 <CIA-32> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r0359979746 10openembedded.git/recipes/connman/ (connman.inc connman_0.73.bb): 
May 06 18:51:18 <CIA-32> connman: package systemd files
May 06 18:51:18 <CIA-32> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 06 18:58:35 <kergoth> khem: if a given recipe (pn-pv) exists in more than one layer, BBFILE_PRIORITY determines which one is used
May 06 19:05:39 <khem> kergoth: so order of the directories are used in BBFILES or in BBPATH wont matter
May 06 19:06:00 <khem> it just has to be in those somewhere thats it right ?
May 06 19:06:03 <kergoth> BBPATH has nothing to do with recipes, its only how include/require are handled
May 06 19:06:11 <kergoth> BBFILES is just a list, order does not matter, indeed
May 06 19:06:26 <khem> ok but BBPATH it will matter right
May 06 19:06:29 <khem> search order
May 06 19:06:45 <khem> if I have a require xx.inc
May 06 19:06:54 <kergoth> yes, include/require traverse bbpath in order
May 06 19:07:09 <khem> ok so BBFILES is clear to me
May 06 19:07:31 <khem> somehow BBPATH followed the priority also would be helpful
May 06 19:08:15 <khem> so whats is a good default for BBPATH in layered world
May 06 19:08:25 <khem> should oe-core be preferred above all
May 06 19:08:35 <khem> or reverse
May 06 19:08:51 <kergoth> i know, it's annoying that the "priority" for config vs recipe is different
May 06 19:09:00 <kergoth> what do you mean?
May 06 19:09:15 <kergoth> if you're using bblayers, you don't need to touch bbpath or bbfiles yourself, other than to add your build/project dir to bbpath
May 06 19:09:31 <kergoth> the layer.conf in each layer does the work, and those are parsed in the order of their listing in BBLAYERS
May 06 19:09:49 <khem> kergoth: yes thats the setup I have
May 06 19:10:21 <khem> define BBLAYERS in bblayers.conf
May 06 19:10:31 <khem> and the order of layers is important for BBPATH
May 06 19:10:45 <khem> so I wanted some sort of convention
May 06 19:11:02 <khem> like first layer in BBLAYERS list is preferred 
May 06 19:11:08 <khem> over second and so on 
May 06 19:11:12 <khem> w.r.t. BBPATH
May 06 19:11:45 <kergoth> the layer.conf generally appends to bbpath, which means the first entry in bblayers is first in bbpath, so its high priority to low for BBLAYERS
May 06 19:12:04 <khem> yes thats the patch I proposed for known layers and oe-core
May 06 19:12:12 <kergoth> this is what bugs me, the behavior of the layer.conf results in bbpath priority reflecting bblayers order, but bbfile priority doesn't necessarily match up with that
May 06 19:12:13 <khem> it was a bit inconsistent
May 06 19:12:28 * khem nods
May 06 19:12:38 <kergoth> its part of why i didn't like this implementation.  at least with COLLECTIONS it was a single place
May 06 19:12:39 <khem> we need to attach the priority to BBPATH 
May 06 19:12:56 <kergoth> the problem is, it has to be done in bitbake.  anything in the metadata is too late, and would have to re-exec the way collections does
May 06 19:13:10 * khem agrees
May 06 19:13:18 <kergoth> i was thinking about doing something where a layer gets automatically added to bbpath/bbfiles and bbfile_ vars set up if its not already in those vars and set explicitly
May 06 19:13:35 <kergoth> so it woudln't change current behavior, but you could just leave out the bbpath/bbfile bits from layer.confs in the future and they'd all start reflecting bblayers order
May 06 19:14:03 <kergoth> but i don't know how anyone else would feel about that (namely, RP)
May 06 19:14:49 <khem> well current behavior needs fixing anyway
May 06 19:16:06 <khem> kergoth: but layers may have a different tree structure 
May 06 19:16:16 <kergoth> what do you mean?
May 06 19:16:24 <kergoth> you can add a directory to bbfiles, it gets traversed to find the recipes
May 06 19:16:29 <khem> I thought you planned to add that automatically 
May 06 19:16:29 <kergoth> then just use bbmask to exclude obselete, etc
May 06 19:16:30 <khem> somehow
May 06 19:16:35 <kergoth> this is how collections worked
May 06 19:16:40 <kergoth> no need for the explicit glob
May 06 19:16:47 <kergoth> takes slightly longer
May 06 19:17:13 <khem> BBFILES += "${LAYERDIR}/packages/*/*.bb ${LAYERDIR}/recipes-*/*/*.bb"
May 06 19:17:21 <khem> thats from one of the layers
May 06 19:18:08 <kergoth> BBFILES += "${LAYERDIR}"
May 06 19:18:09 <kergoth> ta da.
May 06 19:18:13 <kergoth> problem solved.
May 06 19:18:36 <khem> yes I was thinking of thats what you meant
May 06 19:18:46 <khem> it wont work as of today though right ?
May 06 19:18:59 <kergoth> not sure what you mean by that
May 06 19:19:16 <kergoth> you've been able to put a dir in bbfiles for quite a few years
May 06 19:19:17 <khem> BBFILES += "${LAYERDIR}" this one 
May 06 19:19:20 <kergoth> collections already does it
May 06 19:19:22 <kergoth> like i just said
May 06 19:19:24 <kergoth> collections.inc
May 06 19:19:27 <kergoth> does exactly that
May 06 19:19:44 <khem> hmm so I dont need to specify those wildcards ?
May 06 19:19:49 <kergoth> that's correct
May 06 19:20:00 <khem> it will automagically collect recipes and bbappends
May 06 19:20:07 <kergoth> but again, slightly slower to walk the directory structure than to glob()
May 06 19:20:14 <kergoth> i think its worthwhile though for the simplicity
May 06 19:21:01 <khem> so we dont need BBPATH .= ":${LAYERDIR}" or BFILES += "${LAYERDIR} in layer.conf
May 06 19:21:06 <khem> if they are assumed defaults
May 06 19:21:10 <khem> when nothing is used
May 06 19:21:34 <kergoth> yeah, that's what i was thinking
May 06 19:22:48 <khem> kergoth: BBPATH .= ":${LAYERDIR}" may not be default as of now or is it ?
May 06 19:23:06 <khem> added to BBPATH by bitbake automatically already
May 06 19:23:19 <kergoth> bitbake doesn't do any bbpath or bbfiles changes automatically
May 06 19:23:35 <khem> ok
May 06 19:24:37 <khem> ok so current problem is that BBFILES will be picked based upon priority but the files they include will depend upon order of layerdir in BBPATH
May 06 19:25:03 <kergoth> right
May 06 19:25:22 <khem> so one has to be careful in setting BBLAYERS and BBFILE_PRIORITY
May 06 19:25:24 <kergoth> the layer is responsible for one, the user the other
May 06 19:25:29 <kergoth> split responsibility
May 06 19:25:32 <kergoth> not ideal
May 06 19:25:53 * khem nods
May 06 19:25:57 <kergoth> i think layer dependencies + BBLAYERS order should satisfy all needs
May 06 19:26:02 <kergoth> the layer can use deps to exert control
May 06 19:26:34 <khem> it should be simple 
May 06 19:26:39 <khem> prefer layer1 over layer2
May 06 19:26:41 <khem> period
May 06 19:26:47 <kergoth> agreed
May 06 19:26:57 <khem> so whateever bitbake needs from layers follow that order
May 06 19:27:09 <kergoth> really, i'd like to see a long term goal to drop bbpath/bbfiles/bbfile_*/etc entirely
May 06 19:27:17 <khem> be it incs or .bbs or mothers or frogs
May 06 19:27:33 * khem needs food
May 06 19:27:58 * kergoth too
May 06 19:37:34 <Crofton|work> kergoth, amen!
May 06 19:52:38 <CIA-32> 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r8f6422e080 10openembedded.git/recipes/uhd/uhd.inc: 
May 06 19:52:39 <CIA-32> uhd : Enable usrp e100 utilities and package them seperately.
May 06 19:52:39 <CIA-32> Signed-off-by: Philip Balister <philip@balister.org>
May 06 20:46:29 <hbeck> I have a set of recipes for a program that is split into 3 packages all placed into a single recipe directory (name of the program) - hitting a problem with placing some extra files to be installed to one of the packages in /files not being pulled in by the file:// directive in the recipe.  '-e' to bitbake shows FILESPATH contains the directory which holds the file, so...what am I doing wrong here?
May 06 20:47:53 <woglinde_> hbeck?
May 06 20:48:09 <woglinde_> file:// pulls nothing into packages
May 06 20:48:39 <hbeck> not literally file:// - "file://config.conf"
May 06 20:48:54 <hbeck> just meaning I'm using the local URI fetcher
May 06 20:49:02 <woglinde_> again file:// pulls nothing into packages
May 06 20:49:16 <woglinde_> when you use file:// you should do something with this file
May 06 20:49:19 <hbeck> I do
May 06 20:49:21 <woglinde_> atleast in do_install
May 06 20:49:21 <hbeck> in install
May 06 20:49:29 <hbeck> but it isn't making it to WORKDIR
May 06 20:49:35 <hbeck> so install fails
May 06 20:49:49 <hbeck> sorry, used the wrong wording :)
May 06 20:50:01 <woglinde_> hm
May 06 20:50:40 <pb_> ka6sox-home: github mirrors are populated now, I think
May 06 20:51:44 <kergoth> nice
May 06 20:51:45 <roza> have you tried putting the config.conf file in a directory with name ${PN} instead of "files"
May 06 20:52:06 <hbeck> woglinde_: to be more descriptive, I have recipes/vuurmuur/ directory with libvuurmuur, vuurmuur, and vuurmuur-conf recipes in it. I put config.conf under recipes/vuurmuur/files/ and it is referenced by vuurmuur-conf, but not getting pulled to WORKDIR
May 06 20:52:07 <hbeck> roza: yes
May 06 20:52:16 <hbeck> that was where I stuck it initially
May 06 20:52:27 <woglinde_> why this?
May 06 20:52:27 <hbeck> moved it just to see if it made a difference
May 06 20:52:33 <woglinde_> put all into one
May 06 20:52:43 <woglinde_> and define extra packages?
May 06 20:54:27 <hbeck> because it isn't my source, and is already split up with 3 different configure/make setups. More headache to get it to work as one recipe than I wanted to deal with
May 06 20:55:09 <hbeck> it's not set up to 'make' all 3 from a top-level makefile
May 06 20:56:40 <hbeck> which I think is weird, but again not my project - I'm just trying to do recipe(s) for it
May 06 20:57:49 <roza> can other recipes in your system pickup stuff in the files directory?
May 06 20:58:20 <hbeck> roza: definitely. I have also had success with PN, or PN-PV
May 06 20:59:13 <hbeck> so I don't think it's a problem with my setup :)
May 06 20:59:27 <roza> i would think there would be an error if you specify a SRC_URI that the system cannot find
May 06 21:00:01 <roza> does the build break at the fetch step or the install step
May 06 21:00:06 <hbeck> install
May 06 21:00:25 <hbeck> and when I go look in the work/ build area, it's not there
May 06 21:00:46 <roza> did you use SRC_URI+= 
May 06 21:01:03 <kergoth> bitbake -e is our friend.  make sure the SRC_URI really does look sane
May 06 21:01:24 <roza> you might be overwriting it with the http one if they are not the same expression
May 06 21:02:09 <hbeck> kergoth: it doesn't have a space between my svn:// for the main source and the file://config.conf, but I'm not sure if that's normal
May 06 21:02:18 <hbeck> roza: not overwriting
May 06 21:02:22 <kergoth> thats why its brkoen
May 06 21:02:26 <kergoth> src_uri is space separated
May 06 21:02:28 <kergoth> stop using .=
May 06 21:02:32 <kergoth> or _append
May 06 21:02:35 <kergoth> neither of which add a separator
May 06 21:02:51 <hbeck> ah
May 06 21:02:54 <hbeck> would be the _append
May 06 21:02:58 <kergoth> use +=
May 06 21:03:03 <kergoth> 20:59 <roza> did you use SRC_URI+= 
May 06 21:07:30 <hbeck> kind of something I've been wondering about there - what is the idea behind having both += (or .= for no space) and _append?
May 06 21:08:06 <kergoth> += is a convenience.
May 06 21:08:11 <kergoth> .= is a straight concatenation
May 06 21:08:18 <kergoth> _append needs to die
May 06 21:08:21 <hbeck> haha
May 06 21:08:48 <kergoth> unfortunately, our only conditional append uses _append.  we'd need to add an alternative syntax for it
May 06 21:09:31 <woglinde_> yes yes
May 06 21:12:56 <roza> is it possible to have two versions of the same recipe exist in different images; ie imageA get recipe PV1.0 and imageB gets recipe PV2.0
May 06 21:13:25 <kergoth> not going to happen, due to how opkg works
May 06 21:13:34 <kergoth> there are also a number of problems with building two versions of something in a single run
May 06 21:13:43 <kergoth> the files will step all over one another in the sysroot, for example
May 06 21:14:23 <roza> yeah I have being trying to use the PREFERRED_VERSION syntax but I have been getting strange results
May 06 21:15:04 <roza> so I would need to build the images in seperate sandboxes for them to have different versions?
May 06 21:15:15 <kergoth> yep, two different build dirs
May 06 21:25:25 <liamMT> is there a standard group of packages to install to provide a c/c++ dev environment on an image?
May 06 21:37:31 <khem> kergoth: I am getting these NOTE messages 
May 06 21:37:33 <khem> http://pastey.net/149745
May 06 21:37:52 <khem> IIRC you fixed those with PACKAGE_DYNAMIC stuff few weeks back isnt it ?
May 06 21:37:59 <kergoth> no, the other was native vs non
May 06 21:38:01 <khem> kergoth: this is using oe-core meta-oe
May 06 21:38:02 <kergoth> this is just two target recipes
May 06 21:38:11 <kergoth> afaik, anyway
May 06 21:38:13 <khem> k
May 06 21:40:44 <woglinde_> good nite
May 06 21:44:52 <CIA-32> 03Paul Menzel <paulepanter@users.sourceforge.net> 07master * rb8f1b8e7c8 10openembedded.git/recipes/systemd/systemd_git.bb: (log message trimmed)
May 06 21:44:52 <CIA-32> systemd: remove `gtk+` from `DEPENDS`
May 06 21:44:52 <CIA-32> This is a fix up for commit 1f14659d [1]
May 06 21:44:52 <CIA-32> commit 1f14659d5e01f1896ed8899900d2d10745993eea
May 06 21:44:52 <CIA-32> Author: Koen Kooi <koen@openembedded.org>
May 06 21:44:53 <CIA-32> Date: Mon May 2 10:22:10 2011 +0200
May 06 21:44:53 <CIA-32> systemd: update to v26
May 06 21:45:03 <CIA-32> 03Paul Menzel <paulepanter@users.sourceforge.net> 07master * ref7114f6ac 10openembedded.git/recipes/systemd/systemd_git.bb: (log message trimmed)
May 06 21:45:03 <CIA-32> systemd: fix typo s/seperate/separate/
May 06 21:45:03 <CIA-32> This is a fix up for commit 1f14659d [1].
May 06 21:45:03 <CIA-32> commit 1f14659d5e01f1896ed8899900d2d10745993eea
May 06 21:45:03 <CIA-32> Author: Koen Kooi <koen@openembedded.org>
May 06 21:45:03 <CIA-32> Date: Mon May 2 10:22:10 2011 +0200
May 06 21:45:04 <CIA-32> systemd: update to v26
May 06 23:18:15 <jkridner> does oe have a git submodule fetcher?
May 06 23:18:44 <kergoth> hmm, good idea.  would be nice if we had a 'recursive' mode ala git clone --recursive
May 06 23:18:48 <kergoth> don't think  we do now
May 06 23:42:44 <kergoth> what the hell
May 06 23:42:51 <kergoth> hrm
May 06 23:44:02 <kergoth> i do a logger.info() from knotty and it never makes it to the console, somehow
May 06 23:44:09 <kergoth> console is the handler..
May 06 23:44:12 <kergoth> the only one other than null
May 06 23:44:15 <kergoth> standard formatter..
May 06 23:44:18 <kergoth> what the hell?
May 06 23:55:52 <kergoth> this makes no sense
May 06 23:57:16 <tharvey> trying to understand why meta-toolchain doesn't seem to produce a cross-compile environment correctly.  My understanding is I should be able to build meta-toolchain, extract the sdk to / source the environment-setup file, then do a './configure --host=<target-arch>' and make
May 06 23:57:43 <kergoth> in theory, yes
May 06 23:57:59 <tharvey> yet configure likes to bail out with things like: configure: error: C compiler cannot create executables
May 06 23:58:11 <tharvey> (trying to build curl-7.21.2 as an example)
May 06 23:58:19 <tharvey> that would be a bad/missing site-config?
May 06 23:59:45 <tharvey> what is magic in configure that just setting --host can figure out your env based on the few vars set in environment-setup?
May 07 00:00:34 <tharvey> also I notice that 'pkg-config <lib> --cflags' returns expected results including path to sdk include, yet 'pkg-config <lib> --libs' does 'not' include path to SDK 
May 07 00:15:43 <kergoth> anyone done an EBNF for our file format?
May 07 00:15:49 <kergoth> i'd swear i remember something of the sort
May 07 00:15:50 <kergoth> hrm
**** ENDING LOGGING AT Sat May 07 02:59:58 2011