**** BEGIN LOGGING AT Mon Oct 07 02:59:58 2013 Oct 07 05:44:46 blist Oct 07 05:45:00 sorry - wrong window Oct 07 07:04:54 JaMa: thanks for "qtwebkit: Export RUBYLIB to fix wrong paths hardcoded in native ruby", in both master and dylan ! Oct 07 08:04:39 good morning Oct 07 08:10:31 hi mckoan Oct 07 08:10:58 has some one worked with urt UMSH-8596MD-9T display and its backlight? Oct 07 08:11:04 under linux of course Oct 07 08:26:06 morning all Oct 07 08:28:36 hi silvio Oct 07 08:50:27 hi woglinde Oct 07 08:50:32 hi bluelightning Oct 07 08:56:41 morning woglinde, silvio_, all Oct 07 10:00:21 this is still valid or there is new guidelines?: Oct 07 10:00:22 https://github.com/openembedded/meta-oe/blob/master/contrib/oe-stylize.py Oct 07 10:16:23 Hi. Is it explained somewhere how as a user I am supposed to make use of the PACKAGECONFIG stuff I see in recipes ? Oct 07 10:23:44 jkroon_: well, last time i checked, it was indeed not very obvious for new comers to get it... do you have specific questions? Oct 07 10:25:51 ndec, hmm, not reallt at this point.. i'm still struggling with how DISTRO_FEATURES and IMAGE_INSTALL fit together Oct 07 10:26:21 * rburton quickly files a bug to get that in the documentation Oct 07 10:26:38 ok ;-) well, at least for now you need to know that PACKAGECONFIG is great stuff.... you will like it, when you need it ;-) Oct 07 10:27:17 jkroon_: in a config file - local.conf, your distro.conf, whatever, you can do PACKAGECONFIG_pn-[packagename] = "foo bar" Oct 07 10:27:24 or use _append if you just want to extend it Oct 07 10:27:29 jkroon_: PACKAGECONFIG let package 'author' create multiple possible configuration for a package more easily than before. Oct 07 10:27:35 or, use a bbappend and set PACKAGECONFIG in there Oct 07 10:27:43 then you as a package consumer you will need to pick the configuration you want/need. Oct 07 10:28:04 rburton, ndec, aha, I think that explains it to me. thanks Oct 07 10:28:06 sometimes (often in fact) the 'default' configuration is built up using DISTRO_FEATURES Oct 07 10:29:25 rburton: do you really need '_pn"? Oct 07 10:30:32 ndec: from a general conf, yes afaik Oct 07 10:30:45 rburton: about the documentation bug, i think what's not well explained in current doc is from the perspective of a package consumer. Oct 07 10:31:10 yes Oct 07 10:31:16 that's what i'm writing in the bug now :) Oct 07 10:32:28 ah https://bugzilla.yoctoproject.org/show_bug.cgi?id=5214 Oct 07 10:32:47 one of the bugs that didn't quite make 1.5 Oct 07 10:33:05 ok Oct 07 10:43:38 Can I easily figure out the default PACKAGECONFIG ? I'm trying to understand why qtbase 5.1.0 seems to pull in Gtk+.. Oct 07 10:45:33 there's normally only one assignment to PACKAGECONFIG itself Oct 07 10:46:00 hm, qt pulling in gtk+, I thought that was recently changed to be off by default Oct 07 10:46:04 but its because of gtkstyle Oct 07 10:48:24 I thought gtkstyle only would be active if I have x11 in DISTRO_FEATURES ? Oct 07 10:50:15 Which I'm pretty sure I don't.. Any why I can dump the "final" calculated DISTRO_FEATURES ? Oct 07 10:50:52 This is qt5 from the meta-qt5 layer btw.. Oct 07 10:53:01 jkroon_: bitbake -e |grep DISTRO_FEATURES Oct 07 10:56:15 rburton, ah thanks. so it looks x11 is in by default Oct 07 10:56:21 thats was why Oct 07 10:57:24 Hi, it seems update-alternatives is not run for me when bitbake is installing into sysroot (only when the image is created). Is this expected, or am I missing something? Oct 07 10:57:38 (in my own recipe) Oct 07 10:57:51 Thats one question I have though: Whats the preferred way to manipulate DISTRO_FEATURES ? Rewrite it from scratch in distro.conf, or somehow append/remove features to the default ? Oct 07 11:00:10 I want to remove x11, since it appears to be on by default Oct 07 11:10:46 jkroon_: in dylan and earlier you should just set the value to all of the features except the one you want Oct 07 11:11:58 jkroon_: in master/upcoming dora branch you can use the same method or the _remove operator e.g. DISTRO_FEATURES_remove = "x11" Oct 07 11:12:27 bluelightning, aha, thanks Oct 07 11:21:40 * jkroon_ wonders if zapping DISTRO_FEATURES completely was a good idea Oct 07 11:28:50 jkroon_: there's also DISTRO_FEATURES_DEFAULT you can use if you're on master/dora Oct 07 11:41:09 rburton, thanks. think im starting to get the hang of it Oct 07 13:10:01 http://pastebin.com/J2UW4Puv the last line in this ldd is not good, is it? Oct 07 13:10:25 the compiler uses ld from the host machine. Oct 07 13:17:10 tasslehoff can you start the image? Oct 07 13:17:21 tasslehoff an file is better Oct 07 13:17:35 ldd for targetlibs on host normaly makes no sense Oct 07 13:18:24 woglinde: the problem is a toolchain built on ubuntu 13.04 installed on 12.04 Oct 07 13:18:56 woglinde: it should (I believe) use the ld from the toolchain. when I try to run the compiler I get: Oct 07 13:19:17 arm-angstrom-linux-gnueabi-gcc: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument Oct 07 13:19:42 because it uses the version of ld shipped with 12.04 Oct 07 13:23:10 woglinde: gotta run now, I'll pester the channel more later today Oct 07 14:22:26 cbrake, any chance you can add commits by domain/employer to the weekly report? Oct 07 14:35:38 Crofton|work: so a 2nd report? Oct 07 14:36:19 anything that is easy Oct 07 14:36:22 :) Oct 07 14:36:25 Crofton|work: what are your goals with this? Oct 07 14:36:38 document what companies are contributing to OE Oct 07 14:36:50 sort of like what is done for the Linux kernel Oct 07 14:37:01 Crofton|work: can you point me to those efforts? Oct 07 14:37:09 do not worry if it takes a lot of work Oct 07 14:37:32 Crofton|work: git provides most of what we currently get organized by developer, so there is not a lot of extra code required. Oct 07 14:37:32 ok, I'll look for something Oct 07 14:37:46 yeah, mostly sort by domain Oct 07 14:38:29 Crofton|work: organizing by company would probably require parsing the existing report and re-organizing the info, but who knows -- git does some pretty amazing things ... Oct 07 14:38:59 Crofton|work: I suspect *@gmail.com is by far the largest contributor :-) Oct 07 14:39:49 :) Oct 07 14:40:07 once you start creting these reports, people tend to stop using generic addresses :) Oct 07 14:40:20 Crofton|work: good point :-) Oct 07 14:40:49 You mean management starts to force it upon you to use the company address Oct 07 14:41:08 and deal with exchange Oct 07 14:41:18 hi stefan_schmidt Oct 07 14:41:23 hi woglinde Oct 07 14:41:26 Crofton|work: well, I'll poke around and see what comes out -- perhaps a simple summary at the beginning of +/- lines per company/domain, and leave the detailed changes as is (per developer) Oct 07 14:41:34 Or you do what Greg and co do and collet mappings. Oct 07 14:42:33 yeah Oct 07 14:42:34 broonie: good idea Oct 07 14:42:54 whatever is doable in your free time :) Oct 07 14:43:18 Crofton|work: free time -- I've heard of that ... Oct 07 14:43:46 woglinde: how are things? Oct 07 14:45:22 thanks cbrake Oct 07 14:53:27 Crofton|work: cbrake: i would definitely recommend to start by asking greg KH who he is doing his report. he must have a script/DB for the parsing. Oct 07 14:54:13 ndec, you have seen the existing per person report? Oct 07 14:54:23 no. Oct 07 14:54:43 it is sent to most of the lists weekly (I think) Oct 07 14:55:25 ah. yes, the 'OE changelog' you mena. Oct 07 14:55:26 mean? Oct 07 14:55:44 yes Oct 07 14:55:49 ok, i saw them. Oct 07 14:56:47 for the company report, i think it would make more sense to have them for each 'release'. again if the goal is to have some 'company management' watch them, montly will be too much. Oct 07 14:58:49 you could always use gitstats: http://gitstats.sourceforge.net Oct 07 14:59:16 it has a "Commits by Domains" graph Oct 07 14:59:36 e.g. http://gitstats.sourceforge.net/examples/wine/authors.html Oct 07 15:01:03 I'm just looking for something easy for us :) I know we do not have loads of free time Oct 07 15:02:34 I'll poke at gitstats a little Oct 07 15:05:36 Crofton|work: i use gitstats for my (internal) project. the drawback is that you can't combine multiple trees 'stats' together Oct 07 15:05:57 but I just 'sub-tree' merged all layers i use and then do the gitstats on the resulting tree. Oct 07 15:07:19 maybe we could 'sub-tree' merge all the layer trees into a top level project call oe-classic ;-) Oct 07 15:07:44 hah Oct 07 15:10:07 :) Oct 07 17:42:35 hi! I bitbaked meta-toolchain-qte and installed the SDK on my host to the default /usr/local/oe.... Now I am a bit confused, can you tell me if there is something from this SDK meant to be copied to the root file system on my target board or is the SDK only for the host? Oct 07 17:45:22 the sdk is just for the host, a toolchain + associated libs. if you want a fileystem for the target, you ned to bitbake an image, not an sdk Oct 07 17:46:51 kergoth: thank you, but is there an image that already contains all qt stuff incl. tslib etc? Oct 07 17:50:27 I asked because in /usr/local/oecore-x86_64/sysroots I see two dirs: armv7a.... and x86_64.... I thought that the armv7a.... was for the target Oct 07 18:06:37 I've started building my custom image with only DISTRO_FEATURES="sysvinit". I noticed that gcc-runtime seems to depend on "libc-libm" feature, and that tcp-wrappers seems to depend on "libc-nis" feature Oct 07 18:06:53 Should these dependencies be upstreamed somehow ? Oct 07 18:07:20 I mean, I get build failures unless I make these modifications Oct 07 18:08:25 Or am I crazy trying to build an image with minimal DISTRO_FEATURES Oct 07 18:13:48 jkroon_: generally, use DISTRO_FEATURES = '${DISTRO_FEATURES_LIBC your-features' with dylan, or modify DISTRO_FEATURES_DEFAULT in master Oct 07 18:14:37 initmgr can be set by VIRTUAL-RUNTIME_init_manager Oct 07 18:15:25 Right, I'm just getting the feeling that some dependencies are missing here Oct 07 18:15:53 This is with master btw Oct 07 19:22:58 Is #oe logged somewhere? Oct 07 19:23:46 nevermind. found it. Oct 07 19:24:50 Anyone got a clue about the toolchain-Q I asked earlier today? About gcc using ld on the host machine, rather than the one shipped with the sdk Oct 07 19:25:12 I've an interesting problem where two recipes download different files, but with the same filename... Oct 07 19:25:27 is there a way of letting the downloader rename the downloaded file? Oct 07 19:26:43 re tasslehoff Oct 07 19:27:07 roric_ uhm which file? Oct 07 19:27:13 hi woglinde Oct 07 19:35:44 woglinde, its some source to 01.org releases Oct 07 19:36:25 woglinde, I grab them from there github and they are named as the tag.. Oct 07 19:43:39 hm Oct 07 19:44:02 do you control it Oct 07 19:44:13 because github now allows release files Oct 07 19:44:16 woglinde, well I pull it from the git instead now... but just though of it... Oct 07 19:44:42 woglinde, it's not my files! Just came across the issue with oe when it messed up the source files :) Oct 07 19:44:56 no problem of oe Oct 07 19:45:08 upstream should solve it Oct 07 19:47:11 woglinde, well could be kind of hard to guarantee uniqness on all filenames... let say patches Oct 07 20:00:24 I trying to compile xf86-video-omapfb_git.bb but this link is down git://git.pingu.fi/xf86-video-omapfb;protocol=http Oct 07 20:00:49 http://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb Oct 07 20:01:34 Pingu's git repositories are removed, please contact the authors for new locations. Oct 07 20:22:59 tholm update your stuff Oct 07 20:23:00 http://patches.openembedded.org/patch/38899/ Oct 07 20:33:52 thx woglinde **** ENDING LOGGING AT Tue Oct 08 02:59:59 2013