**** BEGIN LOGGING AT Mon Apr 11 02:59:57 2011 Apr 11 05:37:52 khem ping? Apr 11 07:14:12 weird, rebased git push -f was denied on meta-oe-contrib? iirc it worked few days ago.. or is it different hook (iirc it says different error when pushing rebased branch) remote: + refs/heads/shr meta-openembedded-contrib martin_jansa DENIED by fallthru Apr 11 07:16:53 Is it normal for qt4-x11-free to use up to 3GB of my ram+swap? Apr 11 07:25:51 good morning Apr 11 07:26:55 mornign Apr 11 07:33:15 Hi all Apr 11 07:34:10 ciao mrAlmond Apr 11 07:34:26 ciao...Italiano? Apr 11 07:34:53 mrAlmond: yep ;-) Apr 11 07:34:56 ;-) Apr 11 07:35:46 btw...I was in the poky channel asking for support about the xorg fbdev driver in poky Apr 11 07:36:03 they tell me to ask here because in oe there is already support for that driver Apr 11 07:36:30 My purpose is to have mtdev (multitouch display) support in xorg Apr 11 07:36:30 mrAlmond: poky is dead, it has become yocto Apr 11 07:36:52 mrAlmond: you'd better ast to #xorg Apr 11 07:36:54 are you talking about the channel..or about the package? Apr 11 07:38:00 I'm asking here because in oe there is support for the fbdev driver recipe Apr 11 07:38:05 that is missing in poky Apr 11 07:38:07 poky project i now called yocto Apr 11 07:38:40 yes...but the building system is still poky Apr 11 07:38:43 mrAlmond: yes, but multitouch display support is a xorg related topic Apr 11 07:39:23 as far as I know the mt support is already available if you use the evdev input driver for xorg Apr 11 07:39:49 so my question is...is there a simple way to "port" the fbdev driver to yocto(poky)? Apr 11 07:40:02 because now I'm using the kdrive Xfbdev version Apr 11 07:40:24 that as far as I know doesn't use the xorg input drivers that will support mtdev Apr 11 07:40:25 mrAlmond: good to know, BTW I no longer use xorg, I use Qt/e Apr 11 07:41:09 mrAlmond: AFAIK nobody use kdrive Xfbdev nowadays Apr 11 07:41:13 is old Apr 11 07:41:45 mrAlmond: what is your target machine? Apr 11 07:42:04 arm cortexa8 Apr 11 07:42:12 with fb support Apr 11 07:42:21 I know that is old Apr 11 07:42:27 the Xfbdev Apr 11 07:42:41 but it's the only one I could use with the poky build system Apr 11 07:42:43 now Apr 11 07:43:07 because if I will use xserver-xf86-lite Apr 11 07:43:16 mrAlmond: xf86-video-fbdev driver was pushed today to meta-openembedded layer Apr 11 07:43:31 mrAlmond: you can take it from there Apr 11 07:43:36 today? Apr 11 07:43:38 wow Apr 11 07:43:41 :-D Apr 11 07:43:55 it was few weeks in meta-shr Apr 11 07:44:01 but today it was moved to meta-oe instead Apr 11 07:44:15 is the meta-openembedded layer the same as the "meta" directory in poky? Apr 11 07:44:45 mrAlmond: http://git.openembedded.org/cgit.cgi/meta-openembedded/ Apr 11 07:44:48 because I suppose the receipe will be placed in meta/receipe/recipes-graphics/xorg-driver Apr 11 07:45:07 meta directory in poky is often called openembedded-core and meta-oe is layer on top of it Apr 11 07:45:36 ok thank you for the clarification Apr 11 07:45:53 I will try to pull the meta-openembedded Apr 11 07:47:15 Must I also update poky or will the new receipes be compatible with the "laverne" version? Apr 11 07:49:48 xf86-video-fbdev should be compatible I guess but no idea how old laverne is.. Apr 11 07:50:01 I'm using only oe-core HEAD Apr 11 07:52:14 03Martin Jansa  07master * r2689708b28 10openembedded.git/recipes/linux/ (linux/spitz/defconfig linux_git.bb): Apr 11 07:52:14 linux_git: upgrade to 2.6.39-rc2 Apr 11 07:52:14 Signed-off-by: Martin Jansa Apr 11 07:56:47 JaMa: pls have a look at make_savedefconfig Apr 11 08:05:06 ant_work: what with it? Apr 11 08:05:29 much more readable defconfigs, easier to re-diff for other devices Apr 11 08:05:51 yes but that's only in linux-kexecboot.inc Apr 11 08:06:27 yes, we could need itin linux too Apr 11 08:07:00 size changed from 40kb to 3kb Apr 11 08:07:15 then please add it to linux.inc :) Apr 11 08:09:49 well, you see, linux.inc is deprecated. maybe in the same class with do_menuconfig ? Apr 11 08:10:59 (cml1.bbclass) Apr 11 08:12:19 is it? still used a lot, but kernel/cml1 bbclass should be fine too I agree Apr 11 08:12:40 as I read on oe-core Apr 11 08:12:49 linux.inc is doing too much mangling... Apr 11 08:14:17 right for oe-core Apr 11 08:23:51 Hi guys...I've just updated the meta directory by pulling http://git.openembedded.org/cgit.cgi/meta-openembedded/ and now I always get : NOTE: :variable BBPATH references itself! while evaluating: Apr 11 08:24:11 is there something else I must update? Apr 11 08:27:15 ant_work: btw removing defconfigs from linux-kexecboot in 3eee915a3623b14bd94b236b0fd2aa8c22829469 makes linux-kexecboot_git unusable, is it intentional? Apr 11 08:34:03 yes, there was a scary post: [Zaurus-devel] 2.6.39-rc2 on zaurus: does not build, does not boot (Pavel Machek) Apr 11 08:34:24 so I've cleaned waiting for more mature rc Apr 11 08:34:54 you could take the mini-defconfigs from l-k 2.6.38 Apr 11 08:35:53 as I said on Zaurus-devel rc1 and rc2 builds and boots fine for me Apr 11 08:37:16 that's why I pushed linux_git update now (as I'm also using this as base for om-gta kernels) Apr 11 08:37:20 great news Apr 11 08:38:58 I'll be away tonight, feel free to commit the mini-defconfigs for the _git reecipe. Those should not diiffer form the 2.6.38.2 we have Apr 11 08:39:29 ok, I'll push spitz/defconfig Apr 11 08:40:23 fyi, diff between c7x0 and spitz was just a few lines Apr 11 08:47:22 03Martin Jansa  07master * r69f50f3c03 10openembedded.git/recipes/linux/ (linux-kexecboot/spitz/defconfig linux-kexecboot_git.bb): Apr 11 08:47:22 linux-kexecboot_git: upgrade to 2.6.39-rc2 and add spitz defconfig Apr 11 08:47:22 Signed-off-by: Martin Jansa Apr 11 08:56:45 JaMa: good, thx. What do you think about all that mangling in linux-kexecboot.inc btw? Apr 11 08:57:58 ant_work: honestly I don't like it :) Apr 11 08:58:01 sometimes I think about adding 'definitive' l-k defconfigs instead. We don't care about ABI/OABI/thumb etc. Apr 11 08:58:37 ant_work: I didn't understand why you moved parts of linux.inc to linux-kexecboot.inc instead including it Apr 11 08:58:52 heh, I0've read it is deprecated :) Apr 11 08:59:31 so making two deprecated .inc files makes it better? :) Apr 11 08:59:50 no, but would allow to layer to oe-core Apr 11 08:59:56 morning everyone Apr 11 08:59:59 guys...no ideas about the ":variable BBPATH references itself" exception message while using bitbake ? Apr 11 09:00:34 ant_work: I think that best way would be to share as much as possible between linux and linux-kexecboot recipes Apr 11 09:00:54 ant_work: to point that linux-kexecboot has only different defconfig if possible Apr 11 09:00:55 JaMa: I'm pretty sure linux.inc is doomed :) Apr 11 09:02:04 but yes, being the few machines using it, let the developers forge some sane defconfigs if they need to add their device :p Apr 11 09:02:37 mrAlmond: what do you have BBPATH set to? Apr 11 09:03:06 I've just updated the meta directory by pulling http://git.openembedded.org/cgit.cgi/meta-openembedded/ Apr 11 09:03:14 I'm not setting BBPATH by myself Apr 11 09:03:22 with the old meta dir everything is ok Apr 11 09:03:28 ant_work: it's doomed in oe-core, but in old oe it still makes sense to me Apr 11 09:04:34 what will be 'old oe' in a few months? Apr 11 09:04:34 ant_work: in other words, it needs to be reworked in oe-core, to offer similar functionality like old oe had Apr 11 09:04:56 mrAlmond: which instructions did you follow to set that up btw? Apr 11 09:05:01 ant_work: but duplicating it to linux-kexecboot.inc won't make this rework easier IMHO Apr 11 09:05:21 JaMa: I imagine a linux-kexecboot layer, indipendent Apr 11 09:05:33 I simply pulled the git repository and I've copied all those files in my meta directory Apr 11 09:05:42 otherwise you'll be obliged to add linux.inc to your layer Apr 11 09:05:45 see http://www.mail-archive.com/yocto@yoctoproject.org/msg00868.html Apr 11 09:06:02 I'm using poky laverne Apr 11 09:06:20 ant_work: yes but why keep deprecated mangling in .inc file there when all needed mangling will be resolved in meta-oe layer (hopefully) Apr 11 09:06:40 all the meta-oe files... Apr 11 09:06:43 didn't we agree to remove all that mangling few mins ago ? ;) Apr 11 09:07:05 mrAlmond: hang on a sec, you're using poky laverne with meta-oe? that's probably not going to work out well Apr 11 09:07:17 yes Apr 11 09:07:37 So must I pull poky from the head repository? Apr 11 09:08:02 ant_work: I'm talking about still not understanging why you spitted linux.inc and linux-kexecboot.inc in normal oe.. but nevermind .. Apr 11 09:08:09 splitted :) Apr 11 09:08:18 I was thinking someone will remov elinux.inc from oe too, soon Apr 11 09:08:24 I was wrong Apr 11 09:08:37 it's a horrible mess, fwiw Apr 11 09:08:47 mrAlmond: well, I think the expected configuration is oe-core + bitbake as the base (and poky master kind of matches this) Apr 11 09:08:54 ah I see Apr 11 09:10:00 bluelightning : So what do you suggest to me? Where can I get the poky master? Apr 11 09:10:00 ant_work: and btw: I have linux.inc in meta-shr layer :) Apr 11 09:10:11 lol Apr 11 09:11:25 bluelightning : git clone git://git.pokylinux.org/poky.git ? Apr 11 09:14:48 mrAlmond: that's the one yep Apr 11 09:15:05 bluelightning : thanks! Apr 11 09:58:45 hi pb Apr 11 09:58:52 hi woglinde Apr 11 10:05:02 hm oh khem is holds a talk today too Apr 11 13:14:17 03Martin Jansa  07master * rda403d895d 10openembedded.git/recipes/ (20 files in 6 dirs): Apr 11 13:14:17 xorg: remove older versions Apr 11 13:14:17 * xserver-xorg-1.9.4 is kept for people using xf86-input-tslib Apr 11 13:14:17 Signed-off-by: Martin Jansa Apr 11 13:14:31 03Martin Jansa  07master * ra39e33b7a5 10openembedded.git/recipes/ (26 files in 8 dirs): (log message trimmed) Apr 11 13:14:31 xorg: add new versions Apr 11 13:14:31 * xserver-xorg-1.10 is added with D_P -1 until xf86-input-tslib is Apr 11 13:14:31 ported, so 1.9.4 is still default version Apr 11 13:14:31 * xserver-xorg-1.10, dolt was removed in upstream a769f4c22a9cfb5ba248c924a66c31ec966bd8a0 Apr 11 13:14:31 * xserver-xorg-1.10, randr-support needs to be updated, but maybe won't Apr 11 13:14:32 be needed when new xinput-calibrator with config in xorg.conf.d is Apr 11 14:08:59 03Martin Jansa  07master * r6e48ec031c 10openembedded.git/contrib/gstreamer/generate-packages-dynamic-list.sh: Apr 11 14:08:59 generate-packages-dynamic-list: contrib script to generate disjunctive PACKAGES_DYNAMIC for each pack base/good/bad/ugly Apr 11 14:08:59 Signed-off-by: Martin Jansa Apr 11 14:08:59 Acked-by: Mike Westerhof Apr 11 14:09:01 03Martin Jansa  07master * rdf147659ad 10openembedded.git/recipes/gstreamer/gst-plugins-good_0.10.26.bb: Apr 11 14:09:01 gst-plugins-good-0.10.26: move to obsolete Apr 11 14:09:01 Signed-off-by: Martin Jansa Apr 11 14:09:11 03Martin Jansa  07master * re6d170abad 10openembedded.git/recipes/ (6 files in 2 dirs): (log message trimmed) Apr 11 14:09:11 gst-plugins: define disjunctive PACKAGES_DYNAMIC for each pack base/good/bad/ugly Apr 11 14:09:11 * adds a bit more bits to keep in sync while changing gst-plugins Apr 11 14:09:11 version, but not that much (this patch was mostly prepared by script) Apr 11 14:09:11 * overlap in PACKAGES_DYNAMIC namespace causes notes like this in every build Apr 11 14:09:11 NOTE: multiple providers are available for runtime gst-plugin-autodetect (gst-plugins-bad, gst-plugins-good, gst-plugins-base, gst-plugins-ugly) Apr 11 14:09:12 NOTE: consider defining a PREFERRED_PROVIDER entry to match gst-plugin-autodetect Apr 11 14:09:22 03Klaus Kurzmann  07master * r520a238102 10openembedded.git/recipes/phonet-utils/phonet-utils_git.bb: Apr 11 14:09:22 phonet-utils: new recipe Apr 11 14:09:22 Signed-off-by: Klaus Kurzmann Apr 11 14:09:22 Signed-off-by: Martin Jansa Apr 11 14:09:22 03Klaus Kurzmann  07master * r955d8da659 10openembedded.git/recipes/shr/ (2 files in 2 dirs): Apr 11 14:09:23 initscripts-shr: bringup phonet in nokia-n900-cmt-gpio.sh and RDEPEND on it Apr 11 14:09:24 Signed-off-by: Klaus Kurzmann Apr 11 14:09:24 Signed-off-by: Martin Jansa Apr 11 16:34:44 wow Apr 11 16:34:51 hi jay7 Apr 11 16:34:53 I got payment from CELF Apr 11 16:34:58 nice :) Apr 11 16:35:01 uh Apr 11 16:35:03 for what? Apr 11 16:35:16 kexecboot improvement contract Apr 11 16:35:34 now closed finally :) Apr 11 16:35:50 cool Apr 11 16:37:43 * Jay7 is looking for some other contract Apr 11 16:39:00 hm Apr 11 16:39:12 jay7 so you will hold the talk at elce? Apr 11 16:39:38 woglinde: I hope Apr 11 16:40:08 huhu Apr 11 16:42:54 hi jineld Apr 11 16:47:47 hi morphis Apr 11 16:50:23 hi woglinde Apr 11 16:51:22 woglinde: hey Apr 11 17:08:19 hey Apr 11 17:08:46 i'm having problems with the qt4-tools-native recipe on gentoo, where the system holds include files for all installed packages Apr 11 17:09:17 the problem was already posted at http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg15734.html Apr 11 17:10:02 the question is: is there be any reason to build the native qt4 tools with EGL enabled? Apr 11 17:10:38 *is there any reason ... Apr 11 17:24:59 morning Apr 11 17:25:39 hey kergoth Apr 11 17:25:45 hi Apr 11 17:25:52 kergoth: what are you trying to do with opkg? Apr 11 17:26:01 beat it into submission Apr 11 17:26:05 hehe Apr 11 17:26:06 thus far i'm the one taking the beating Apr 11 17:26:09 :) Apr 11 17:26:10 been there ;) Apr 11 17:26:36 I implemented a web UI with cgi shell scripts that allows to upgrade the system, list packages that can be upgraded etc Apr 11 17:26:41 neat Apr 11 17:26:56 still some open points are left, like propagating error codes to the client or "out" via the API Apr 11 17:27:23 i'm just working on a script to do some particular things with packages, from python, so figured it'd be easier to use the c api than the commandline, but it sounds like 'direct' is more the word, not 'easier' :) Apr 11 17:27:38 plus side, learning cython Apr 11 17:28:17 I wrote some smaller tools that use the opkg library, but basically for listing stuff in JSON format which comes handy for the web UI Apr 11 17:28:39 nice Apr 11 17:28:42 and I do installing using the opkg client, after I saw the API it was clear to me that I'd have to spend a lot of time fixing it if I want to do everything that the client does Apr 11 17:28:46 sounds like that would be generally useful Apr 11 17:28:55 * kergoth nods Apr 11 17:29:15 it really feels like we should just start over..but i tend to lean more toward rewrites than refactoring at a certain point Apr 11 17:29:17 heh Apr 11 17:29:18 I did send a bunch of fixes upstream too (already in trunk), when I started to use the C-API opkg bombed out one time after another Apr 11 17:29:56 the fact that get/set option don't even check for array boundaries doesn't bode well for the quality of the C code, it's no wonder opkg is so flaky at times :P Apr 11 17:30:18 things I fixed were some missing NULL checks that lead to coredumps Apr 11 17:30:24 ouch Apr 11 17:30:25 the C code of opkg is really terrible Apr 11 17:31:08 rewrite would indeed be the cleanest approach Apr 11 17:31:17 but is at the same time a lot of work I guess Apr 11 17:31:28 yeah Apr 11 17:31:35 wonder what license busybox dpkg is under Apr 11 17:31:38 could be a starting point Apr 11 17:31:45 check out sourcemage gnu/linux, it uses sorcery/cast/dispel/quill for package management Apr 11 17:32:23 its not perfect but its in bash shell scripting, and needs only a few modifications imo Apr 11 17:32:41 but is it smart about resource usage? if you look at apt-get for example, it wants to pull everything down, then install it all, so it can back out to previous states, which makes sense, but you really need to work more iteratively when on resource constrained devices Apr 11 17:32:42 mostly for specific apps Apr 11 17:32:59 erm, incrementally is probably a better term there Apr 11 17:33:25 kergoth: btw thats the opkg2json tool http://gitorious.digitalstrom.org/dss-misc/opkg2json and that's the configuration web interface for upgrading and more http://gitorious.digitalstrom.org/dss11-websetup/dss11-websetup if you want to poke around for ideas Apr 11 17:33:28 minimal depends as well, luckily using sourcemage makes that easy Apr 11 17:33:44 Jin^eLD: nice, thanks for the pointers :) Apr 11 17:33:49 np Apr 11 18:08:47 grr Apr 11 18:09:00 qt 4.7.2 doesn't compile on platforms 4.7.1 does Apr 11 18:09:12 | ../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:242:6: error: #error "The cacheFlush support is missing on this platform." Apr 11 18:09:12 (mips, probably others) Apr 11 18:13:03 ... powerpc Apr 11 18:24:13 tartarus hm Apr 11 18:59:29 - Create customizable chroot; Build an image that would be self-hosting Apr 11 18:59:42 nice item from Yocto tech team meeting Apr 11 21:02:19 ooh, lupa is really easy to use Apr 11 21:02:23 (the python module) Apr 11 21:07:10 https://gist.github.com/914343 Apr 11 23:22:21 when does do_install run? On the compiling host when it's building an image, or on the target when the package is actually installed? Apr 11 23:26:07 when building Apr 11 23:33:46 foerster: ty **** ENDING LOGGING AT Tue Apr 12 02:59:57 2011