**** BEGIN LOGGING AT Tue Apr 16 02:59:58 2013
Apr 16 07:05:00 <mckoan> good morning
Apr 16 07:40:28 <apelete> good morning
Apr 16 07:40:39 <apelete> Hi mckoan
Apr 16 07:42:00 <silvio__> hi all
Apr 16 07:43:49 <woglinde> hi apelete
Apr 16 07:44:27 <apelete> Hi silvio__, woglinde 
Apr 16 08:06:54 <silvio__> hi apelete 
Apr 16 08:50:43 <bluelightning> morning all
Apr 16 08:55:28 <silviof> morning! How can i generate the run.*-files in temp directory but avoid the execution of this run-file?
Apr 16 09:16:27 <apelete> hi bluelightning, silviof
Apr 16 09:17:04 <silviof> hi apelete 
Apr 16 09:17:44 <woglinde> hi bl
Apr 16 09:17:44 <bluelightning> hi apelete
Apr 16 09:17:47 <bluelightning> hi woglinde
Apr 16 09:22:26 <pb_> hi all
Apr 16 09:22:32 <woglinde> gm pb
Apr 16 09:22:40 <pb_> morning woglinde
Apr 16 09:23:10 <silviof> hi pb_ 
Apr 16 09:23:20 <pb_> morning silviof
Apr 16 09:27:48 <bluelightning> hi pb_
Apr 16 09:28:29 <ensc|w> are there plans when the /lib/udev -> /sbin/udev movement has been completed?  Lot of stuff in oe still refers to /lib/udev and it would be nice when there would be provided a generic way how udev rules and keymaps are to be installed nowadays
Apr 16 09:56:09 <apelete> I'm having the following messages displayed:
Apr 16 09:56:09 <apelete> NOTE: multiple providers are available for virtual/libsdl (libsdl, libsdl-qpe)
Apr 16 09:56:09 <apelete> NOTE: consider defining a PREFERRED_PROVIDER entry to match virtual/libsdl
Apr 16 09:56:09 <apelete> NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
Apr 16 09:56:12 <apelete> NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg
Apr 16 09:56:15 <apelete>  
Apr 16 09:56:38 <apelete> does someone know what happens when there is no PREFERRED_PROVIDER in this case ?
Apr 16 10:01:36 <bluelightning> I suspect it builds the first in the list, but I'm not entirely sure
Apr 16 10:01:55 <bluelightning> apelete: if you really want to ensure the right thing happens, follow its advice and just set PREFERRED_PROVIDER_xyz
Apr 16 10:03:23 <apelete> bluelightning: for libsdl I already have PREFERRED_PROVIDER_virtual/libsdl = "libsdl-x11", don't know why I'm getting the message (looking through bitbake -e right now)
Apr 16 10:04:22 <bluelightning> apelete: I don't think libsdl-x11 exists anymore given the message above
Apr 16 10:04:28 <bluelightning> there is only libsdl
Apr 16 10:05:33 <apelete> ok, that could explain it, because bitbake -e confirms that PREFERRED_PROVIDER_virtual/libsdl = "libsdl-x11" has been set
Apr 16 10:05:49 <apelete> bluelightning: thanks, as usual :)
Apr 16 10:09:28 <apelete> I'm trying to spend more time on meta-jlime lately, didn't make much progress due to lack of time, so I really appreciate the help I'm getting around here 
Apr 16 10:09:39 <OWayne> Just discovered HAL is no more, what is the recommended replacement?
Apr 16 10:10:09 <bluelightning> OWayne: udev I believe
Apr 16 10:11:27 <OWayne> bluelightning: I thought HAL was built on top of udev, was hoping for something higher level
Apr 16 10:11:46 <bluelightning> OWayne: what functionality are you looking for specifically?
Apr 16 10:12:13 <OWayne> detect insertion/removal of usb devices
Apr 16 10:12:35 <bluelightning> right, udev is definitely where that is handled now
Apr 16 10:12:54 <bluelightning> there are a set of rules that determine what to do when a new device is detected
Apr 16 10:13:05 <bluelightning> you can of course add your own custom rules
Apr 16 10:17:43 <OWayne> bluelightning: yeah I have rules for mount operations, for the application level, I suppose I can monitor message bus
Apr 16 10:18:44 <OWayne> for udev messages
Apr 16 10:19:33 <bluelightning> there's also udisks, not sure if that's helpful in your situation
Apr 16 10:19:56 <ensc|w> OWayne: when you want it a little bit more low-level, you can listen on the kernel netlink messages directly
Apr 16 10:23:51 <OWayne> udisks might be of some use, thanks for the tips guys.
Apr 16 10:24:45 <woglinde> bluelightning we already have udisks and udisks2
Apr 16 10:36:43 <hrw> bluelightning: any plans on updating php to 5.4.14?
Apr 16 10:37:12 <bluelightning> hrw: I'd like to set aside some time in the next cycle to sort out the php mess, and part of that would be updating it
Apr 16 10:37:21 <bluelightning> but if someone else gets there first then I won't mind ;)
Apr 16 10:38:18 <hrw> bluelightning: :D
Apr 16 10:47:45 <OWayne> bluelightning: find-replace hal with UDisks and we have life :)
Apr 16 10:49:37 <bluelightning> OWayne: :)
Apr 16 11:02:25 <hrw> bluelightning: NOTE: recipe php-5.4.14-r4.0: task do_rm_work_all: Succeeded
Apr 16 11:02:51 <bluelightning> hrw: so you have done it already?
Apr 16 11:03:00 <hrw> bluelightning: during last 20 minutes
Apr 16 11:03:06 <bluelightning> great!
Apr 16 11:03:14 <bluelightning> assuming it works at runtime, ship it! :)
Apr 16 11:03:23 <hrw> one patch dropped, one updated
Apr 16 11:03:35 <hrw> building linaro-image-lamp now to test
Apr 16 11:04:27 <hrw> sstate-cache rulz
Apr 16 11:19:59 <silviof> How can i generate the run.*-files in temp directory but avoid the execution of this run-file?
Apr 16 11:46:38 <woglinde> silviof you cannt
Apr 16 11:47:40 <silviof> woglinde: ok - thx
Apr 16 11:47:54 <woglinde> but you run -c devshell
Apr 16 11:48:09 <woglinde> after some task finished and look at the run files
Apr 16 11:49:21 <silviof> woglinde: hmm yes - i work so - but i thought it gives a better way.
Apr 16 12:42:56 <hrw> bluelightning: php 5.4.14 sent
Apr 16 12:43:06 <bluelightning> hrw: thanks
Apr 16 13:16:59 <silviof> what must I do to use the yocto-toolchain in openembedded?
Apr 16 13:17:11 <silviof> Write a own toolchain-recipe?
Apr 16 13:18:51 <bluelightning> silviof: the yocto toolchain is the same as the OE one
Apr 16 13:19:15 <silviof> ok - and how can i use the preinstalled toolchain?
Apr 16 13:19:20 <bluelightning> silviof: if you're asking, can you use the OE toolchain as an external toolchain, the answer is we don't really support that
Apr 16 13:20:02 <bluelightning> if the reason you're asking is to save build time, then I'd suggest sharing your shared state cache to solve that problem instead
Apr 16 13:20:18 <silviof> hmm - ok
Apr 16 13:20:47 <silviof> I will think about it
Apr 16 13:20:57 <silviof> bluelightning: thx!
Apr 16 13:21:09 <bluelightning> np
Apr 16 15:11:42 <bluelightning> JaMa: sent OE-Core PR bump patches, I missed your comment about +2 so they're only +1 unfortunately :/
Apr 16 15:11:58 <bluelightning> hopefully they get accepted
Apr 16 15:12:05 <hrw> looks like it is time to bump layer priority for all linaro layers
Apr 16 15:12:19 <hrw> bitbake builds php 5.3.19 from meta-oe instead of 5.4.14 from meta-linaro
Apr 16 15:13:14 <bluelightning> hrw: a layer like meta-linaro should probably have higher priority anyway I would think
Apr 16 15:15:05 <JaMa> bluelightning: replied on one of them
Apr 16 15:15:40 <JaMa> bluelightning: so you have another chance to do +2
Apr 16 15:16:01 <bluelightning> JaMa: hmm ok
Apr 16 15:24:52 <pb_> or meta-oe should have a lower priority :-}
Apr 16 15:25:08 <pb_> but yes, setting a higher priority on meta-linaro sounds like a reasonable thing to do.
Apr 16 15:25:27 <bluelightning> JaMa: sent
Apr 16 15:37:34 <JaMa> bluelightning: maybe it would be safer to remove .bbappends now and then wait for oe-core bumps to fix that (if you'll make sure they are appied in both dylan/master), what do you think?
Apr 16 15:38:00 <bluelightning> JaMa: it's up to you, but I don't yet have assurance those changes will be accepted
Apr 16 16:14:59 <bluelightning> JaMa: ok changes have been merged
Apr 16 16:17:22 <JaMa> meta-oe too
Apr 16 16:22:15 <bluelightning> JaMa: thanks!
Apr 16 16:28:50 <dv_> i have a kernel recipe that gets a modified kernel from github. right now, it uses git clone. but that is very slow.
Apr 16 16:29:14 <dv_> github also allows you to download a tarball of a specific branch. this is faster, but then you are restricted to this branch.
Apr 16 16:29:26 <dv_> is the git clone approach the generally favored one in OE?
Apr 16 16:32:44 <JaMa> dv_: yes, with PREMIRROR it will do git clone only once
Apr 16 16:32:51 <JaMa> and then download tarball from PREMIRROR
Apr 16 16:33:16 <JaMa> dv_: tarballs generated by github are changing checksums
Apr 16 16:34:06 <dv_> PREMIRROR? oaky
Apr 16 16:34:07 <dv_> *okay
Apr 16 16:42:46 <bluelightning_> dv_: either way is fine, it's up to you as the maintainer of the kernel recipe
Apr 16 16:51:59 <ensc|w> is somebody working on solving the breakage caused by moving udev rules to /sbin/udev, or is oe going to be broken for the next months again?
Apr 16 16:54:24 <bluelightning_> ensc|w: are you sure the rules have actually been moved? when I checked earlier they were still under ${libdir}
Apr 16 16:54:41 <bluelightning_> or rather, ${base_libdir}
Apr 16 16:55:22 <bluelightning_> sure that's not the same as hardcoding it to /lib which appears to be what upstream recommends (and we should probably follow for the non-binary parts)
Apr 16 16:56:19 <ensc|w> bluelightning_: http://pastebin.com/raw.php?i=X2ycGKXq
Apr 16 16:57:11 <bluelightning_> ensc|w: for whatever reason, that's not what I see here
Apr 16 16:57:30 <bluelightning_> ensc|w: I can only suggest, come up with a patch that fixes it and doesn't move the binaries, and it may be accepted
Apr 16 16:57:35 <ensc|w> bluelightning_: do you have systemd?
Apr 16 16:59:18 <bluelightning_> ensc|w: right, in my other tmpdir I do see that
Apr 16 17:01:15 <bluelightning_> bbl
Apr 16 17:02:29 <ensc|w> fwiw, fixing it requires patching of sources because searchpath is based on UDEVLIBEXECDIR
Apr 16 18:51:11 <mario-goulart> is anybody experiencing these errors when building log4j1.2? http://paste.debian.net/249963/
Apr 16 18:51:18 <mario-goulart> -native
Apr 16 18:58:43 <woglinde> args
Apr 16 18:58:50 <woglinde> gnumail strikes back
Apr 16 18:59:12 <woglinde> mario-goulart there is some strange problem where the compiler in gnumail compiles a class 0 byte
Apr 16 18:59:18 <woglinde> and I thought I fixed it
Apr 16 18:59:28 <woglinde> some time ago
Apr 16 18:59:41 <woglinde> mario-goulart whats your building threads?
Apr 16 18:59:49 <woglinde> aeh how many
Apr 16 19:03:54 <mario-goulart> woglinde: I have BB_NUMBER_THREADS = '8' here
Apr 16 19:04:42 <dv_> is there anything that can be done if fetching the kernel times out even after several tries?
Apr 16 19:08:19 <bluelightning> dv_: probably time to contact the repo admin I would think...
Apr 16 19:09:48 <dv_> the admin is github :)
Apr 16 19:13:39 <JaMa> dv_: yes sometimes it happens with github, it was happening a bit more with gitorious before..
Apr 16 19:14:07 <JaMa> but still better then some kernel sources we had in CVS (in oe-classic)
Apr 16 19:14:17 * kergoth wishes git could resume incomplete clones
Apr 16 19:14:40 <JaMa> that would be nice
Apr 16 19:15:20 <JaMa> and sortable index without calling ls-remote | wc -l
Apr 16 19:15:24 <mario-goulart> woglinde: is there any recommended workaround for that issue?
Apr 16 19:18:52 <woglinde> yes recompile it
Apr 16 19:19:13 <woglinde> try -c cleansstate gnumail-native
Apr 16 19:19:51 * mario-goulart tries
Apr 16 19:23:44 <mr_science> well, if yesterday was weird bug day, today is weird lunch day...
Apr 16 19:24:45 <tzanger> just be happy you didn't have weird bugs for lunch
Apr 16 19:25:39 <mario-goulart> woglinde: that did the trick! Thanks!
Apr 16 19:26:39 <mr_science> tzanger: that would make it go-out-for-lunch day...
Apr 16 19:27:05 <tzanger> :-)
Apr 16 19:30:57 <mr_science> although i definitely eat better here than i did on my previous gig
Apr 16 19:31:32 <mr_science> certainly healthier anyway
Apr 16 19:39:17 <woglinde> mario-goulart sorry that I do not find the root cause of this
Apr 16 19:39:34 <woglinde> mario-goulart with -j2 or -j4 it does not happen
Apr 16 19:39:43 <woglinde> and its always the same class
Apr 16 19:41:01 <mario-goulart> woglinde: No problem.  Thanks for providing a workaround.
Apr 16 20:12:44 <waynr> okay i am attempting to build qwt and i get a fetcher failure for: http://downloads.sourceforge.net/qwt/qwt-6.0.1.tar.bz2
Apr 16 20:13:24 <waynr> yet i can find the tar.bz2 file at: http://sourceforge.net/projects/qwt/files/qwt/6.0.1/
Apr 16 20:28:12 <woglinde> waynr fix the recipe and send patches
Apr 16 20:32:39 <waynr> okay, I changed "${SOURCEFORGE_MIRROR}/qwt/qwt-${PV}.tar.bz2;name=qwt" to "http://sourceforge.net/projects/qwt/files/qwt/${PV}/qwt-${PV}.tar.bz2;name=qwt"
Apr 16 20:32:50 <waynr> i'll read up on the patch submission process and take care of that right now
Apr 16 20:34:51 <woglinde> where is qwt now integrated?
Apr 16 20:34:56 <woglinde> oe-core or meta-oe)
Apr 16 20:35:02 <waynr> meta-oe
Apr 16 21:29:32 <waynr> patch sent, though i just realized i submitted the patch witha  different email address than the one with which i subscribed to the list
Apr 16 21:45:16 <waynr> ah, fool that i am
Apr 16 21:45:21 <waynr> i sent a bogus patch to the list
Apr 16 21:47:19 <waynr> hmm, what branch should i be patching against?
Apr 16 21:48:03 <waynr> okay i patched master this time
Apr 16 22:25:27 <apelete> hmmm, does do_stage() used to be executed before do_install() or the other way around ?
Apr 16 22:25:55 <kergoth> do_stage doesn't exist anymore, hasn't in quite a long time
Apr 16 22:26:00 <kergoth> it was legacy even in oe-classic
Apr 16 22:26:26 <JaMa> iirc after
Apr 16 22:27:12 <apelete> kergoth JaMa: moving script code from the do_stage function to the do_install function here, trying to know if I should move the do_stage code before or after the do_install one
Apr 16 22:27:44 <JaMa> apelete: usually it'd do_install_append or end of do_install
Apr 16 22:27:56 <kergoth> that sounds like the wrong approach, though. do_install generally already installs everything necessary
Apr 16 22:29:04 <apelete> kergoth: I'm porting a distro from oe-classic to oe-core, that's why I'm dealing with moving code away from do_stage
Apr 16 22:29:56 <apelete> I'm following this documentation http://www.openembedded.org/wiki/Legacy_staging
Apr 16 22:29:58 <kergoth> doesn't change the fact that do_install still usually installed everything necessary. do_install was usually a superset of do_stage
Apr 16 22:30:08 <kergoth> but as jama says, append if you do find a need to do so
Apr 16 22:30:40 <kergoth> that describes how to do a conversion blindly, without actually seeing what's missing and what isn't, and what's needed and what isn't. I guess it depends on your priorities and what you have time to do, and whether you'll be pushing this upstream
Apr 16 22:32:19 <JaMa> it says "deleting anything that is already handled in the existing do_install" so carefull reader shoulnd't do it blindly :)
Apr 16 22:32:45 <apelete> kergoth: you've got a point there. for now I'm just trying to get it to build, will do more fixes after if needed
Apr 16 22:33:37 <JaMa> apelete: for your original question, legacy do_stage is executed from do_populate_sysroot if exists in oe-classic
Apr 16 22:34:33 <apelete> JaMa: yes, in the case I'm facing it seems I shouldn't delete do_stage() altogether, so I guess I will append it at the end of do_install
Apr 16 22:38:22 <apelete> will move the code into a do_install_append() in fact, seems cleaner and easier to spot in the future
Apr 16 22:38:33 <apelete> JaMa kergoth: thanks
Apr 16 22:41:04 <JaMa> what's the recipe you're working on?
Apr 16 22:43:42 <apelete> JaMa: hubbub recipe in recipes/netsurf/ in oe-classic
Apr 16 22:44:31 <apelete> http://cgit.openembedded.org/openembedded/tree/recipes/netsurf/hubbub_0.0.2.bb?h=2011.03-maintenance
Apr 16 22:48:50 <apelete> JaMa: so, what do you think about it ? does converting to do_install_append() seem a good choice ?
**** ENDING LOGGING AT Wed Apr 17 02:59:58 2013