**** BEGIN LOGGING AT Thu Jan 07 02:59:56 2010 Jan 07 05:26:42 hallo Jan 07 07:30:06 03Martin Jansa  07org.openembedded.dev * rb864411e79 10openembedded.git/recipes/linux/linux-openmoko-2.6.32/om-gta02/defconfig: Jan 07 07:30:06 linux-openmoko-2.6.32: om-gta02/defconfig remove USB_SUSPEND Jan 07 07:30:06 Signed-off-by: Martin Jansa Jan 07 08:04:20 morning Jan 07 08:56:45 what is the best way to maintain a local config file without cluttering up my OE tree? E.g. if I want my own busybox defconfig or my own kernel config. I don't really want to make a full fledged overlay for the recipe as I would like to keep in sync with patches and new version Jan 07 09:00:42 eFfeM: why not commit it in your tree and never push it upstream? its how I do it.. Jan 07 09:01:03 03Koen Kooi  07org.openembedded.dev * ra96a9a1166 10openembedded.git/ (3 files in 2 dirs): Jan 07 09:01:03 netbook-launcher-efl: add 0.2.0.0 Jan 07 09:01:03 liblauncher: add 0.1.8 Jan 07 09:01:04 03Koen Kooi  07org.openembedded.dev * r21fd017229 10openembedded.git/ (2 files in 2 dirs): human-icon-theme: add 0.35 Jan 07 09:01:05 03Koen Kooi  07org.openembedded.dev * r2bc2e6b801 10openembedded.git/ (3 files in 3 dirs): pidgin: update to 2.6.4 Jan 07 09:01:17 good morning Jan 07 09:02:44 eFfeM: overlay is the best (and proper) solution, I am using a tree like this http://www.kaeilos.com/?q=download Jan 07 09:02:48 JaMa: yeah that is probably the best way, is there something like .gitignore (like .cvsignore) that I can use to avoid accidently pushing them? Jan 07 09:03:44 eFfeM: its called .gitignore Jan 07 09:04:12 :-) Jan 07 09:04:22 eFfeM: but it works on files to commit, not files to push Jan 07 09:04:34 eFfeM: make a local branch and never push that is the safeest Jan 07 09:04:37 thought so, problem was never so irritating to dive into it Jan 07 09:05:00 XorA localbranch seems best plan Jan 07 09:05:29 mckoan: overlay afaik requires me to have the whole recipe in the overlay, I don't think I can overlay a single file Jan 07 09:05:53 eFfeM: yes that's right Jan 07 09:06:16 eFfeM: clone busybox bb and customize it Jan 07 09:06:37 but I won't mind to be teached differently (/me forgot the past tense of teach :-) ) Jan 07 09:06:39 eFfeM: I think this has been addressed (overwrite single file)? Jan 07 09:07:04 zecke: ah ok, i've never seen it Jan 07 09:07:26 eFfeM: I don't remember details :) Jan 07 09:07:41 * XorA prefers branches as one quick rebase -i and a local branch can be ready for upstream Jan 07 09:10:29 eFfeM: I have 2 checkouts .. one RO for testing/changes and 2nd RW just for pushing Jan 07 09:10:51 eFfeM: on RO one I always rebase my patch queue with patches for pushing on top Jan 07 09:11:20 eFfeM: and then with format-patch I "export" them for git am -s on RW checkout Jan 07 09:11:28 JaMa: ok, never thougt of doing it that way Jan 07 09:11:33 thanks for the suggestion Jan 07 09:11:42 eFfeM: not sure if that's optimal, but it works pretty good for me Jan 07 09:11:57 JaMa: you could save a step by making one repo a remote for another :-D Jan 07 09:13:27 eFfeM: only think i hate is that i prepare patches on shr/merge branch, but pushing them to oe.dev (updated if needed), then merging oe.dev to srcpv branch (updated if needed), then merging srcpv to shr/merge and then refresh of local RO checkout hoping that it will be the same what I wanted to push through :) Jan 07 09:14:37 XorA: ahh good idea, I didn't think about using remote for adding another local ;) Jan 07 09:27:10 morning Jan 07 09:28:02 hi hrw Jan 07 09:28:40 eFfeM: you can also adapt FILESPATH Jan 07 09:29:13 in local.conf: FILESPATH_pn-busybox = "values:from:oe:your-overlay" Jan 07 09:29:48 ah yes, that is a nice one Jan 07 09:34:15 one more stupid Q: I added PREFERRED_VERSION_busybox = "1.2.1" to my local.conf, still it builds 1.13.something, how come? Jan 07 09:38:07 Hi guys, I still have the problem as described in this thread http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-January/015960.html and putting `virtual/libintl` to `DEPENDS` did not work for me. Jan 07 09:38:43 Could someone of you please try `bitbake vdr` in his setup? Jan 07 09:43:34 let me rephrase my question: I set the preferred version of busybox to 1.2.1 in a local overlay, still I get the one from openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc. bitbake -D shows that local.conf is parsed first, the angstrom preferred version does not have ?=, is this expected/desired behaviour Jan 07 09:44:31 PaulePanter: i've baked it yesterday @ home, but because it took some time I got sidetracked and did not really look at the results, don't recall any failure but not sure if I actually checked Jan 07 09:44:42 will try to remember to look at it tonight Jan 07 09:48:15 by changing the = in openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc to ?= I get 1.2.1 as specified in local.conf, shouldn't local.conf always have the last say ????? Jan 07 09:52:05 PaulePanter: the build fails for me on cortex-a8 Jan 07 09:52:23 PaulePanter: and with -lintl not being found Jan 07 09:53:06 PaulePanter: and vdr is not using autotools? Jan 07 09:54:03 PaulePanter: the -lintl does not need to present with glibc (AFAIK) Jan 07 09:59:59 zecke: Thanks for trying. As far as I know VDR is not using autotools. Jan 07 10:00:40 zecke: I will try to remove the `-lintl` from the call. Jan 07 10:02:24 PaulePanter: it works then. For uclibc and such we need -lintl but not for glibc (AFAIK) Jan 07 10:03:34 zecke: good afternoon Jan 07 10:03:46 pb___: hey! Jan 07 10:04:01 * zecke feels like a child when playing with mod_python in apache Jan 07 10:04:37 Is there a way to only include a file/patch if we build with a certain library (uclibc)? Jan 07 10:05:24 zecke: [OT] You are probably aware of it, but I read that mod_wsgi can perform better than mod_python. Jan 07 10:06:51 PaulePanter: yes, there is a way. It is the overrides system. Or you can start modifying the LDFLAGS inside the recipe handler Jan 07 10:08:39 eFfeM: what exactly do you mean by setting the version "in a local overlay"? if you are setting from local.conf then yes, it is expected that the distro value will take precedence; you can use overrides if this is not what you want. Jan 07 10:16:01 pb___: I have a very strange issue with linux.inc and the logo_linux_clut224.ppm. With >2.6.32, even if I provide the logo in SRC_URI (though in .bz2) this is apparently not found in do_configure_prepend(). No issues with e.g. 2.6.26. Any idea? Jan 07 10:18:42 pb___: I would pretend that in do_configure all the files in SRC_URI are fetched... Jan 07 10:20:54 zecke: Thanks! Jan 07 10:21:47 ant_work: so, does the file actually get copied to the WORKDIR during do_fetch? Jan 07 10:22:10 my idea is it's not yet bunzipped..could it be? Jan 07 10:22:39 the logo is in SRC_URI += Jan 07 10:23:42 it should be unzipped during do_fetch Jan 07 10:23:48 what's strange, I can repeatedly build the 2.6.26 and it has the logo Jan 07 10:23:54 never with 2.6.32+ Jan 07 10:24:01 I think you need to actually inspect the WORKDIR and find out what is happening. there is no point in me sitting here and guessing. Jan 07 10:24:34 I fear possibly the bunzip task is not done. but why..I'll try to see Jan 07 10:24:36 thx Jan 07 10:28:28 03Holger Hans Peter Freyther  07org.openembedded.dev * rd27fb2aec7 10openembedded.git/ (4 files in 4 dirs): Jan 07 10:28:28 qt4x11: Cease out the qt4x11 PROVIDER Jan 07 10:28:28 * The LGPL and Commercial edition are actually the same tarball. Jan 07 10:28:28 * If someone sees the need he can take qt qt4-recipes and specify Jan 07 10:28:28 -commercial in the compilation. Jan 07 10:28:32 03Holger Hans Peter Freyther  07org.openembedded.dev * rd542c62b5a 10openembedded.git/ (6 files in 2 dirs): (log message trimmed) Jan 07 10:28:35 qt4: Make the gles variants for Embedded and X11 provide the normal variant Jan 07 10:28:37 This way a distribution/user can set PREFERRED_PROVIDER_qt4-embedded = "qt4-embedded-gles" Jan 07 10:28:39 to select the GLES/OpenVG runtime. The default is qt4-embedded as GLES require a dedicated Jan 07 10:28:41 library most of the time provided as a binary blob by the vendor requiring the user Jan 07 10:28:43 to manually download and store it at the right place. Jan 07 10:28:45 For X11 we already have a PREFERRED_PROVIDER setting in place and don't need to update. Jan 07 10:28:47 03Holger Hans Peter Freyther  07org.openembedded.dev * rbe4bdd0ffa 10openembedded.git/ (4 files in 2 dirs): Jan 07 10:28:50 qtwebkit-performance-utilities: Add new recipe Jan 07 10:28:52 These are some simple benchmarks and utilities for QtWebKit Jan 07 10:30:35 03Koen Kooi  07org.openembedded.dev * raf57250cfa 10openembedded.git/ (conf/checksums.ini recipes/gimp/gimp_2.6.8.bb): gimp: add 2.6.8 Jan 07 10:36:25 03Marco Cavallini  07org.openembedded.dev * r43bb6f65a7 10openembedded.git/recipes/xorg-xserver/xserver-xorg-conf/ronetix-pm9263/xorg.conf: xorg-xserver/xserver-xorg-conf/ronetix-pm9263/xorg.conf : added mouse support Jan 07 10:39:03 pb__ was afk, didn't think of using overrides, just wanted busybox 1.2.1 and in my overlay in conf/local.conf I specified the preferred version, i expected that that would take precedence from the one from the distro Jan 07 10:50:20 hello to all. i have a problem with building the task opie-image. for some reason i am getting allways the error message out of memory but this can not be the problem. i have enought memory and disk space. does anybody know a solution for this problem ? Jan 07 10:50:51 xperia: who tells you, you are out of memory? Jan 07 10:51:04 bitbake Jan 07 10:51:25 xperia: sure? Jan 07 10:51:36 xperia: what is the message? Jan 07 10:51:57 gime a moment to post the full message, Jan 07 10:52:23 xperia: by post you mean something like a pastebin? Jan 07 10:52:30 lisppaste7: url Jan 07 10:52:31 To use the lisppaste bot, visit http://paste.lisp.org/new/oe and enter your paste. Jan 07 10:52:54 okay :-) Jan 07 10:54:06 zecke: exist a possibilty to get the error log somehow from the build process. i am building oe on a remote machine. Jan 07 10:54:33 xperia: you can use the oestats client Jan 07 10:56:08 03Martin Jansa  07org.openembedded.dev * r611662a494 10openembedded.git/recipes/freesmartphone/libeflvala_git.bb: libeflvala: move from recipes/freesmartphone to recipes/efl Jan 07 10:56:19 03Thomas Zimmermann  07org.openembedded.dev * ree6762f166 10openembedded.git/recipes/connman/ (connman.inc connman_git.bb files/shr/connman): Jan 07 10:56:19 connman: move test utils to separate package, shr config do not disable usb0 on startup Jan 07 10:56:19 Signed-off-by: Klaus Kurzmann Jan 07 10:56:53 xperia: check the comments in classes/oestats*.bbclass to see how to configure Jan 07 10:58:09 zecke: thanks for the answer. the problem is related to Jan 07 10:58:10 shasum-native-1.0-r1.do_setscene Jan 07 10:58:12 coreutils-native-7.2-r1.do_setscene Jan 07 10:58:13 if i am not wrong building coreutils-native is the root of the errors message "Out of Memory" Jan 07 10:58:31 xperia: sorry, post the full message or none. Jan 07 11:06:49 any Xorg exper here? I get some errors like (EE) Failed to load module "glx" (module does not exist, 0) although I don't have any glx module in my org.conf, how could I solve this error? Jan 07 11:09:20 zecke: running task 1 of 2542 (id: 15, .../recipes/shasum/shasum-native.bb, do setscene) Jan 07 11:09:22 running task 2 of 2542 (id: 75, .../recipes/coreutils/coreutils-native_7.2.bb,do setscene) Jan 07 11:09:24 Out of Memory: Kill Process 11335 (python) Jan 07 11:09:26 ERROR: Task 15 shasum-native.bb do setscene failed Jan 07 11:09:56 xperia: *sigh* Jan 07 11:10:33 xperia: this looks like a kernel message to me? Jan 07 11:10:48 mckoan: I think thats normal and harmless these days Jan 07 11:11:04 XorA: thx Jan 07 11:11:05 mckoan: xorg.conf is just additions to what X does automatically now, it is no longer the total config Jan 07 11:11:27 in most cases you can actually do without xorg.conf totally Jan 07 11:11:41 zecke: hmm i have builded it on a ubuntu server and on a debian desktop system. both fails with the same error message. Jan 07 11:11:52 XorA: so I could ignore (EE) FBDEV(0): FBIOBLANK: Invalid argument as well? Jan 07 11:12:15 mckoan: I think that one is harmless as well, I see it a lot on arms Jan 07 11:12:48 XorA: good to know Jan 07 11:13:28 and about touchscreen calibration, what is the suggested tool to use? xtscal looks broken Jan 07 11:15:01 # DISPLAY=:0 xtscal Jan 07 11:15:03 XCALIBRATE extension missing: Success Jan 07 11:15:50 have to do something. will be back. see you all. Jan 07 11:16:55 03Koen Kooi  07org.openembedded.dev * r700fd19cd9 10openembedded.git/ (conf/checksums.ini recipes/fltk/fltk_1.1.10.bb): fltk: add 1.1.10 Jan 07 11:17:32 xjqian: in any case your kernel is killing the python process Jan 07 11:17:46 xjqian: a) you don't have enough ram b) it is doing something weird like eating your ram Jan 07 11:21:56 looks like xtscal is part of GPE, could I use xcalibrate package with xorg? Jan 07 11:23:22 xtscal isn't really "part of" GPE, it just happens that the sources are stored in the gpe svn repository. Jan 07 11:23:30 it doesn't depend on any other gpe components. Jan 07 11:23:56 mickey|office: good morning Jan 07 11:25:43 pb_: thx, do you know any machine successully using it? Jan 07 11:26:05 * * OE Bug 5367 has been created by ospite(AT)studenti.unina.it Jan 07 11:26:07 * * libfsoframework fails to build Jan 07 11:26:09 * * http://bugs.openembedded.org/show_bug.cgi?id=5367 Jan 07 11:26:17 mckoan: with full X.org you mean? Jan 07 11:26:31 hrw: yes with xorg Jan 07 11:27:14 mckoan: not offhand, but it doesn't have anything that's very machine-specific. Jan 07 11:27:25 it should work fine with any xserver that implements XCALIBRATE. Jan 07 11:27:54 * mckoan is thinking if it worth to switch to ts_calibrate instead of xtscal Jan 07 11:28:38 mckoan: as zero people have got it to work, would be nicer if you could debug why Jan 07 11:29:09 pb_: so XCALIBRATE extension missing: means that XCALIBRATE is not implemented somwhere Jan 07 11:29:23 mckoan: yeah, that means that your xserver has been built without XCALIBRATE Jan 07 11:29:33 XorA: I'm working on it now :-) but I need some hints Jan 07 11:30:05 pb_: do you know where it could be specified? Jan 07 11:32:16 openembedded$ grep -r XCALIBRATE recipes/xorg-* Jan 07 11:32:49 looks like everybody has been using it with xserver-kdrive Jan 07 11:32:58 mckoan: recipes/xorg-lib/libxcalibrate Jan 07 11:33:03 nobody uses it with xorg Jan 07 11:34:50 I love pstage Jan 07 11:35:03 mckoan: xserver configure line, I guess Jan 07 11:35:29 xjqian: what do you think is more likely? what does free say about ram? Jan 07 11:37:15 XorA, pb_ : thx I'll take a look later Jan 07 11:37:17 03Martin Jansa  07org.openembedded.dev * r54c6f4eb5e 10openembedded.git/recipes/tasks/task-shr-feed.bb: task-shr-feed: remove usbmode Jan 07 11:37:18 03Martin Jansa  07org.openembedded.dev * rf3472b0f09 10openembedded.git/recipes/freesmartphone/ (3 files in 2 dirs): frameworkd: add patch for shr, merge from shr/merge Jan 07 11:37:23 * mckoan -> bbl Jan 07 11:40:01 I think I found Jan 07 11:40:18 JaMa: are you there? Jan 07 11:41:28 I'm trying to build xorg-xserver 1.7.1 (xorg 7.5) now, but it always complains that glproto is not >= 1.4.9 although 1.4.10 has been built: http://tinderbox.openembedded.org/builds/49501/ Do you have an idea? Jan 07 11:43:07 laibsch whats the config.log really says? Jan 07 11:43:53 glproto >= 1.4.9 gl >= 7.1.0 Jan 07 11:43:58 whtas the gl version? Jan 07 11:44:08 No package 'gl' found Jan 07 11:44:14 glproto is fine Jan 07 11:44:15 gl not Jan 07 11:44:17 The log is on tinderbox Jan 07 11:44:21 I see Jan 07 11:44:26 I thought that was alternative Jan 07 11:44:28 :) Jan 07 11:44:31 nope Jan 07 11:44:31 is it cumulative? Jan 07 11:44:34 jupp Jan 07 11:44:39 I see Jan 07 11:44:40 thanks Jan 07 11:44:44 no prob Jan 07 11:45:30 what package provides gl? "find recipes" did not reveal it to me Jan 07 11:45:39 virtual Jan 07 11:45:49 virtual/gl Jan 07 11:45:55 its mesa Jan 07 11:45:58 ;) Jan 07 11:47:01 Laibsch: imho its mesa Jan 07 11:47:07 hi jama Jan 07 11:47:08 woglinde: :) thanks.. Jan 07 11:48:10 shouldn't "bitbake virtual/gl" build that? Jan 07 11:49:03 look into your staging dir pkgconf Jan 07 11:50:26 seems like it's virtual/libgl Jan 07 11:51:53 03Thomas Zimmermann  07org.openembedded.dev * r2ccd9f2b12 10openembedded.git/recipes/vagalume/ (files/index.theme vagalume_0.7.1.bb): Jan 07 11:51:53 vagalume: add index.theme from shr/merge Jan 07 11:51:53 Signed-off-by: Klaus Kurzmann Jan 07 11:51:56 yes virtual/libgl Jan 07 11:51:57 and it's 7.0.2 version of mesa Jan 07 11:52:01 03Martin Jansa  07org.openembedded.dev * r1700b4c844 10openembedded.git/recipes/pulseaudio/ (3 files in 2 dirs): libcanberra: add libcanberra-increase-buffer-size.patch from shr/import Jan 07 11:52:05 which is built here Jan 07 11:52:19 Laibsch: but check it its right provider for your machine (mesa/mesa-dri/mesa-xlib) Jan 07 11:53:00 Laibsch: that's because newer have DEFAULT_PREFERRENCE = -1 (as filip asked here yesterday) Jan 07 11:53:31 Laibsch: you can add preferred version to 7.6 if it works for your machine.. Jan 07 11:56:39 JaMa: shouldn't that be set in conf/distro/include/preferred-xorg-versions-X11R7.5.inc? Jan 07 11:58:07 Laibsch that is what I feared Jan 07 11:58:20 why feared? Jan 07 11:58:24 laibsch sure otherwise you cant build the xserver Jan 07 11:58:36 *g* maybee feared is not the right word Jan 07 11:58:37 in what section? Jan 07 11:58:39 apps? Jan 07 11:58:47 03Martin Jansa  07org.openembedded.dev * r758da30df2 10openembedded.git/recipes/update-alternatives/ (4 files in 2 dirs): Jan 07 11:58:47 update-alternatives-cworth: use latest installed alternative Jan 07 11:58:47 * if there is more alternatives with higest priority, use the one last Jan 07 11:58:47 in alternatives file (latest installed) Jan 07 11:58:47 * if target exists and its directory, remove link, otherwise new Jan 07 11:58:51 alternative link is created inside that direstory Jan 07 11:58:53 Signed-off-by: Martin Jansa Jan 07 11:58:55 gl is lib Jan 07 11:58:59 OK Jan 07 11:59:11 glxgears is app Jan 07 11:59:12 *g* Jan 07 11:59:26 I ask because it is not in recipes/xorg-lib/ Jan 07 11:59:27 JaMa: opkg is not shipping u-a now? Jan 07 12:00:09 JaMa: I will set the preference to 7.1.0 for now Jan 07 12:00:19 that seems to be the minimum necessary Jan 07 12:00:30 Users are free to override the ?= Jan 07 12:00:50 laibsch jupp Jan 07 12:01:10 Laibsch hm Jan 07 12:01:15 mesa 7.1 is now really old Jan 07 12:02:24 ok, time to check calibration on x.org now Jan 07 12:05:21 calibration? Jan 07 12:05:27 yep Jan 07 12:05:34 I have same problem as Marco Jan 07 12:05:37 other device Jan 07 12:07:52 woglinde: but what other version would you suggest Jan 07 12:07:59 it's the minimum for 7.5 Jan 07 12:08:07 anything above is optional I guess Jan 07 12:10:20 hrw I joined to late Jan 07 12:12:05 woglinde: X.org server from OE lacks xcalibrate extension by default Jan 07 12:12:12 woglinde: so xtscal does not work Jan 07 12:12:28 03Frederik Sdun  07org.openembedded.dev * rcc1c330520 10openembedded.git/recipes/imagemagick/ (files/fix_open_file.patch imagemagick_6.3.5-10.bb): Jan 07 12:12:28 imagemagick:native: fix build error with space Jan 07 12:12:28 Signed-off-by: Frederik 'playya' Sdun Jan 07 12:12:28 Signed-off-by: Klaus Kurzmann Jan 07 12:12:29 03Thomas Zimmermann  07org.openembedded.dev * r9842ab0293 10openembedded.git/recipes/netbase/ (3 files in 3 dirs): Jan 07 12:12:33 netbase: update config files for om-gta* Jan 07 12:12:35 Signed-off-by: Klaus Kurzmann Jan 07 12:12:37 03Martin Jansa  07org.openembedded.dev * r2df4f2cfe7 10openembedded.git/recipes/gpe-icons/ (gpe-icons.inc gpe-theme-neo_git.bb): Jan 07 12:12:40 gpe-theme-neo: add recipe from shr/merge Jan 07 12:12:42 * gpe-icons.inc: for switching gpe icon theme with u-a and merging Jan 07 12:12:44 installed alternatives of together Jan 07 12:12:46 * standard gpe-icons recipe with require gpe-icons.inc will follow Jan 07 12:12:48 later. I need to prepare some switch for distro to choose if u-a Jan 07 12:12:50 should be used for gpe-icons. Jan 07 12:13:38 03Rolf Leggewie  07org.openembedded.dev * radeb84be41 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.5.inc: preferred-xorg-versions-X11R7.5.inc: needs at least 7.1.0 of virtual/libgl Jan 07 12:13:47 hrw hm okay Jan 07 12:13:55 which device needs it? Jan 07 12:14:43 hrw: this patch was already merged to opkg code.. this is just backport for u-a-cworth Jan 07 12:15:10 woglinde: at91sam9263ek, ronetix-*, bug Jan 07 12:15:38 woglinde: no.. at91sam9263ek works fine with evdev for me so no calibrate needed Jan 07 12:23:47 03Martin Jansa  07org.openembedded.dev * r52ac711853 10openembedded.git/recipes/resolvconf/resolvconf_1.45.bb: Jan 07 12:23:47 resolvconf: add version 1.45 from SHR Jan 07 12:23:47 Signed-off-by: Martin Jansa Jan 07 12:23:58 03Martin Jansa  07org.openembedded.dev * r676b651a8b 10openembedded.git/recipes/packagekit/packagekit_0.5.2.bb: packagekit: add version 0.5.2 from SHR Jan 07 12:36:21 why does OE continue to build mesa 7.0.2 despite PREFERRED_VERSION_virtual/libgl ?= "7.2" ? Jan 07 12:36:37 Is PREFERRED_VERSION_virtual/libgl not working the way I expect it to? Jan 07 12:37:06 You can't set preferred versions on virtuals. If virtual/libgl is being provided by mesa, you want to set P_V_mesa. Jan 07 12:38:07 Laibsch: you should add PREFERRED_VERSION_mesa mesa-dri mesa-xlib Jan 07 12:38:22 pb_: if I want to have xserver with calibration support I need to build it properly. Resulting binary will depend on libxcalibrate or not? Jan 07 12:38:27 hrw: no Jan 07 12:39:03 libxcalibrate is the client library Jan 07 12:39:13 JaMa: I was afraid so. Those are the only providers for virtual/libgl? Is there a possibility of more providers in the future? Jan 07 12:40:00 pb_ hm what depends xserver than on for calibration? Jan 07 12:40:03 Laibsch: thats all providers I know about.. and I hope its enough even for future :) Jan 07 12:40:43 pb_: thx Jan 07 12:41:19 Laibsch: but reason why I haven't put P_V for that in that include was because on om-gta02 we need mesa-dri_git with DRM patches and that cannot be forced with P_V-mesa-dri in distroconfig because of posibly floating PV Jan 07 12:41:43 Laibsch: but I've removed p-v-xorg includes from SHR.. so its "ok" for me now Jan 07 12:41:55 You can always override, no? Jan 07 12:42:02 hi djwillis Jan 07 12:43:02 Laibsch: you can but mesa-dri_git has PV with git revision which can change in sanesrcrevs and then the P_V_mesa-dri won't work and some old version will be pulled without noticing :/ Jan 07 12:43:20 woglinde: er? I don't quite understand the question. Jan 07 12:43:36 Laibsch: and for somewone with AUTOREV used for mesa-dri_git it cannot be overriden with P_V at all :/ Jan 07 12:43:56 pb_ dont the xserver needs something to enable ts-calibration? Jan 07 12:44:12 no Jan 07 12:44:17 JaMa: Is there any proper solution? Jan 07 12:44:17 hm okay Jan 07 12:44:20 well, not aside from tslib, and it has that anyway Jan 07 12:44:42 wasnt there a x ts lib or something Jan 07 12:47:40 djwills oe.dev still has EXTRA_OECONF = "--disable-music-mp3 --enable-music-ogg --enable-music-ogg-tremor --enable-music-mp3-mad-gpl" Jan 07 12:47:48 for sdl-mixer Jan 07 12:49:03 03Rolf Leggewie  07org.openembedded.dev * rdcbd24596e 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.5.inc: Jan 07 12:49:03 preferred-xorg-versions-X11R7.5.inc: setting P_V does not actually work for virtual providers Jan 07 12:49:03 * set mesa, mesa-dri and mesa-xlib explicitly. If other providers of virtual/libgl were Jan 07 12:49:03 introduced they would need to be set explicitly, too. Jan 07 12:49:05 * actually 7.2 is the minimal version in OE to fulfill the 7.1.0 requirement for virtual/libgl Jan 07 12:54:28 shit. Jan 07 12:54:31 still missing Jan 07 13:00:01 Laibsch: I guess no.. I proposed P_V with wildcard (patch for bitbake) for case like this, but it wasn't accepted because it would slow things down too much.. Jan 07 13:03:03 well, at the risk of banging on about an old topic, this would not be a problem if you didn't put the git rev in PV. :-} Jan 07 13:03:25 but, more seriously, if a DISTRO wants to use a particular git rev as their preferred version, it is up to that distro to take the appropriate steps to make sure that the revision remains available. Jan 07 13:03:58 pb like uboot and angstroem? Jan 07 13:04:08 woglinde: I don't have commit so that was pulled from my tree, not had a chance to make it an enterprise feature yet (feel free to tweak ;-)) Jan 07 13:05:09 if your distro wants to use a floating git checkout as its preferred version, that's easy: you just set PV to "git" (literally) and then you can use the same string as the PREFERRED_VERSION. Jan 07 13:06:13 pb_: after two glasees of red wine I see now my logo problem: SRC_URI was redefined :/ fetchers are just fine. Sorry for the noise. Jan 07 13:07:00 ant_work: aha, right Jan 07 13:09:34 pb_: my xserver-xorg build has "#define XCALIBRATE 1" in xorg-config.h and it got compiled. any idea why it is not available when X starts? Jan 07 13:20:48 re Jan 07 13:20:59 hi mckoan ! Jan 07 13:21:16 ciao gremlin[it] how are you? Jan 07 13:21:23 OI gremlin[it] Jan 07 13:21:32 djwilis oh hm let me see who this was Jan 07 13:21:54 hrw: no idea offhand, I guess you need to inspect the xserver source to see what has gone wrong Jan 07 13:21:58 koen!!!!!!!!!!! Jan 07 13:22:02 whahahaa Jan 07 13:25:05 woglinde: hrm? Jan 07 13:25:11 Ah. Jan 07 13:25:45 uh? Jan 07 13:26:23 xora? Jan 07 13:26:43 pb_: iirc 'require recipes/x/y.bb' is evil, because it takes the first one in BBPATH. (see kergoth bb5d379aa5a57c54e36b2452baac1135952fda8e). I suppose there are some more hardcoded 'recipes' (see ee7fe8a359d98bbf85a3c3d22ce298c41f0f88b4 ) Jan 07 13:27:14 (this reminds me we need a 'commit-id' filter in cgit.openembedded.org) Jan 07 13:27:25 ant_work: um, why are you telling me this? Jan 07 13:27:37 well, I only know ONE point of view Jan 07 13:27:50 and the patch was acked by many devs Jan 07 13:28:09 I'm unsure I see the issue. is only with collections? Jan 07 13:29:50 yes, it only occurs with collections Jan 07 13:30:32 is it worth to grep and fix the remaining? Jan 07 13:30:55 probably a good idea, yes Jan 07 13:31:19 one QA would be too much, perhaps Jan 07 13:31:24 ant_work: http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=bb5d379aa5a57c54e36b2452baac1135952fda8e works just fine for me Jan 07 13:31:30 though, some of those things look pretty crazy anyway. what is mamona doing with its own private version of gcc? Jan 07 13:31:44 he Jan 07 13:34:44 $ grep PREFERENCE xserver-kdrive_1.5.3.bb Jan 07 13:34:45 DEFAULT_PREFERENCE = "-99" Jan 07 13:34:45 B Jan 07 13:34:47 why? Jan 07 13:35:34 probably means it was very busted Jan 07 13:38:12 aww Jan 07 13:38:12 ok Jan 07 13:39:13 Where is PREFERRED_PROVIDER_xserver set? Jan 07 13:39:54 Laibsch: jlime-2009.1 Jan 07 13:40:15 it's just that kdrive 1.4.2 needs a minor fix for newer X headers Jan 07 13:40:29 didn't know whether to use 1.5.3 or fix 1.4.2 recipe Jan 07 13:40:54 kdrive is basically dead anyway, so pick the most useful one from OE and we will have to maintain it locally anyway Jan 07 13:41:38 gm Jan 07 13:42:04 likewise: hi Jan 07 13:42:23 Laibsch: in some of the distro files, but only by mistake. Jan 07 13:43:09 nothing actually PROVIDES "xserver", and I don't think anything DEPENDS on it either, so setting a PREFERRED_PROVIDER for it will not have any useful effect. Jan 07 13:43:12 pb__ earlier today you suggested overrides to force using my preferred version of busybox and not the one pushed upon me by angstrom, but i fear it is not completely clear to me how that is done Jan 07 13:43:32 eFfeM: PREFERRED_VERSION_busybox_local = "1.2.3" Jan 07 13:43:53 ah ok Jan 07 13:45:47 pb_: what kind of override is local from? Jan 07 13:46:13 likewise: what do you mean? Jan 07 13:46:33 pb_: DISTRO, MACHINE, ... Jan 07 13:46:45 none of those, it's an OVERRIDE in its own right Jan 07 13:46:49 see ${OVERRIDES} in bitbake.conf Jan 07 13:48:54 pb_: The local override is especially useful for overlays/collections, it seems. We should really write a good section to http://docs.openembedded.org/usermanual/usermanual.html#special_overrides Jan 07 13:49:10 pb_: I'm trying to find out why xorg-image in my case builds both xserver-xorg as well as xserver-kdrive (where the latter fails) Jan 07 13:49:38 Laibsch: did you try the bitbake -g approach? Jan 07 13:49:48 sure Jan 07 13:49:57 I'm about to paste depends.dot Jan 07 13:50:03 likewise: yes, that would be a good idea Jan 07 13:50:14 But looking at the files, there were so many variables Jan 07 13:50:21 I kind of didn't see clearly Jan 07 13:50:38 Laibsch: which machine? Jan 07 13:50:45 qemuarm Jan 07 13:51:24 PREFERRED_PROVIDER_xserver = "xserver-kdrive" Jan 07 13:51:27 he.. Jan 07 13:51:34 I see now Jan 07 13:52:04 I thought it was spitz Jan 07 13:55:51 depends.dot is very big, grepping for kdrive results in http://paste.debian.net/55896/ Jan 07 13:56:51 inspecting the angstrom-x11-base-depends bb file did not immediately reveal to me kdrive came into the picture Jan 07 13:56:57 inspecting the angstrom-x11-base-depends bb file did not immediately reveal to me where kdrive came into the picture Jan 07 13:57:12 what's your setting for ${XSERVER}? Jan 07 13:57:32 xorg-image should set that Jan 07 13:57:39 that won't work Jan 07 13:58:26 not? Jan 07 13:58:36 no, there is no sharing of variables between separate recipes. Jan 07 13:58:39 then why does xorg-image.bb try? Jan 07 13:58:50 OK Jan 07 13:59:00 because${XSERVER} is also used in x11-image.bb, which is included directly from xorg-image.bb Jan 07 13:59:01 So, it has to be done in local.conf or the machine definition? Jan 07 13:59:10 right Jan 07 13:59:14 or some conf file, anyway Jan 07 13:59:33 My thinking was that x11-image and the other places only weakly assign Jan 07 13:59:40 whereas xorg-image uses = Jan 07 13:59:59 I don't quite know why angstrom have structured their stuff like that, I guess you'd need to take it up with them. Jan 07 14:00:10  Jan 07 14:00:17 well, the thing is, it's not really angstrom I'm building Jan 07 14:00:34 it's just that it's muddled in OE Jan 07 14:00:38 pb_: xcalibrate.c Copyright © 2003 Philip Blundell, I didn't know that :-D Jan 07 14:00:48 mckoan: heh Jan 07 14:02:08 pb_: unfortunately uses pure X11 APIs aka headache Jan 07 14:04:42 why it's using X11 API headache? Jan 07 14:04:49 it'/is it Jan 07 14:04:53 it's/is it Jan 07 14:04:56 crap Jan 07 14:05:41 pb_: I understand that xtscal uses recipes/xorg-lib/libxcalibrate_git.bb but where is xtscal itself? Jan 07 14:05:50 eFfeM: FILESPATHBASE =. "${TOPDIR}/files"; cd ; mkdir -p files/busybox; cp /path/to/my/busybox/defconfig files/busybox/; bitbake -c clean busybox; bitbake busybox Jan 07 14:06:00 * kergoth slowly catching up on the scrollback.. Jan 07 14:06:05 mckoan: er, recipes/xtscal/...? Jan 07 14:06:19 hey guys Jan 07 14:06:25 * kergoth yawns Jan 07 14:06:31 morning kergoth Jan 07 14:06:55 * mckoan is blushing Jan 07 14:09:06 kergoth: thanks! Jan 07 14:11:15 eFfeM: erm, forgot a trailing : in the FILESPATHBASE, but you get the idea Jan 07 14:11:22 heh Jan 07 14:12:53 yup, tnx Jan 07 14:15:14 I'm trying to compile ibus-anthy in OE. Here is my current ibus-anthy_1.2.0.20091127.bb: http://paste.debian.net/55898/ The do_compile step fails because anthy.h is not found: http://tinderbox.openembedded.net/builds/49541/ Jan 07 14:15:42 anthy.h is available in /data/oe/laibsch/tmp/minimal/org.openembedded.dev/staging/armv5te-oe-linux-gnueabi/usr/include/anthy/anthy.h and /data/oe/laibsch/tmp/minimal/org.openembedded.dev/staging/x86_64-linux/usr/include/anthy/anthy.h Jan 07 14:16:12 I guess for some reason the build system is not looking in the proper place, but I'm not sure where I need to tweak Jan 07 14:17:30 because of -I/usr/include ? Jan 07 14:18:00 but it is looking for anthy/anthy.h Jan 07 14:18:07 so that looks OK to me, no? Jan 07 14:18:18 do you have /usr/include/anthy/anthy.h ? Jan 07 14:18:20 Oh Jan 07 14:18:24 I see Jan 07 14:18:29 it should trigger crosscompile badness, but it's swig I know nothing about Jan 07 14:18:31 Where should that be fixed? Jan 07 14:18:49 fixed or tweaked? Jan 07 14:19:15 well, maybe some sed voodoo Jan 07 14:21:48 I was wondering why I don't get QA logs. Does one have to inherit insane.bbclass for that? Jan 07 14:22:09 I only have QA_LOG = "1" Jan 07 14:22:26 I guess the cross-compile badness warning would have been valuable information here Jan 07 14:23:25 it depends on what are you building Jan 07 14:24:11 grep insane conf/* -R shows kaelios and angstrom only Jan 07 14:26:28 I am building minimal Jan 07 14:28:30 ok, it depends on which distro you're building, not image :) Jan 07 14:29:07 angstrom/kaelios distro use insane Jan 07 15:16:00 jo gnutoo Jan 07 15:27:18 03Martin Jansa  07org.openembedded.dev * r61e5731139 10openembedded.git/recipes/gpe-icons/gpe-theme-neo_git.bb: gpe-theme-neo: kill SRCPV, sorry Jan 07 15:39:33 woglinde, hi Jan 07 15:57:33 denix: Am I mistaken or where you one of the people interested in the collie? Jan 07 16:30:22 :-D Jan 07 16:30:25 GNUtoo: heya Jan 07 16:30:43 GNUtoo: did you see the dolt patch that people has referenced in the ml? Jan 07 16:33:38 * kergoth still doesn't see the point. the prefixing is oe specific, and not particularly necessary Jan 07 16:34:05 dolnt isnt necessary too Jan 07 16:34:16 sure, but dolt does at least serve some purpose Jan 07 16:34:25 whereas, the prefixing is just an annoyance for no gain Jan 07 16:34:26 what? Jan 07 16:34:37 pb_: With libtool 2.x, it doesn't actually help that much Jan 07 16:34:45 I looked into the m4 saw nothing Jan 07 16:34:56 pb_: The gain is that you can be more sure the right libtool is getting used Jan 07 16:35:35 RP: I guess that's true, though I can't think of any packages where using the wrong one has ever been a problem. Jan 07 16:35:45 pb_: I can :/ Jan 07 16:35:49 if its the wrong one, its likely going to fail anyway Jan 07 16:35:59 and i'm certain we could create a sanity check that doesn't require a rename Jan 07 16:36:04 say, appending to the libtool version, or something Jan 07 16:36:11 kergoth: It does make the failure much more obvious... Jan 07 16:36:34 * RP says this as the person who took most of the 1.5 -> 2.x pain Jan 07 16:36:35 and as i just said, there are likely better ways to go about it than something that intrusive Jan 07 16:37:10 kergoth: Is it really that instrusive? Its probably a two line patch to fix dolt... Jan 07 16:37:25 a 2 line patch for something highly oe specific that you're trying to get *upstream* Jan 07 16:37:26 its idiotic Jan 07 16:37:31 you don't send upstream a fix for *our shit* Jan 07 16:37:33 otavio, yes Jan 07 16:37:41 * RP never suggested it go upstream Jan 07 16:38:03 if it doesn't go upstream, then we'll end up having to patch dolt locally forever. that doesn't sound so great either. Jan 07 16:38:05 i'd rather see a better check than adding *extra patches* for no good reason Jan 07 16:38:06 yeah Jan 07 16:38:38 There is a good reason - it makes things fail in a really clear way when the wrong libtool bits make it into a build Jan 07 16:38:48 no, there's no good reason to do it this way Jan 07 16:38:49 kergoth: I sent it upstream (the dolt fix) Jan 07 16:38:53 all you need is a check, not *this check* Jan 07 16:39:00 otavio: i know Jan 07 16:39:04 which again, is silly at best Jan 07 16:39:19 kergoth: ? send patches upstream is silly? Jan 07 16:39:21 kergoth: I don't see how your magic check is going to check for the combinations of failures that rename actually catches Jan 07 16:39:24 * otavio is confused Jan 07 16:39:30 such as mismatched macro files Jan 07 16:39:37 otavio: yes, saying "please, hack around OE specific shit" is fucking stupid. Jan 07 16:39:42 otavio: the prefixing is oe specific, why should they have to work around us? Jan 07 16:39:46 i wouldn't, if i was them Jan 07 16:41:02 RP: there are any number of things we could add to libtool.m4 that would result in the output Jan 07 16:41:30 s/result/end up/ Jan 07 16:41:38 kergoth: You still don't get it - what it we're not actually using our libtool/m4 but the host one? Jan 07 16:41:47 ? Jan 07 16:42:04 if you modify our libtool.m4 to alter the generated libtool in a different way that we can check for, ta da, done Jan 07 16:42:14 of course i get it, i was the one who wrote the fucking thing Jan 07 16:42:14 03Martin Jansa  07org.openembedded.dev * ref45af9139 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Jan 07 16:42:14 Revert "remoko: bump revision in sane-srcrevs for bluez4 support" Jan 07 16:42:14 Sorry pushed by accident, needs changes to recipes before.. Jan 07 16:42:35 kergoth: libtool or the hack? Jan 07 16:42:54 the prefixing hack, was part of the original libtool patches i threw together back when oe first started Jan 07 16:43:04 kergoth: I know the history ;-) Jan 07 16:43:10 apparently you don't Jan 07 16:43:50 kergoth: I'm well aware you wrote the patches. Come the move to 2.x, I forward ported some, binned others and added some new ones Jan 07 16:44:12 if package ships the libtool m4 macros they need to removed anyway Jan 07 16:44:21 if you think i don't know why i wrote the patch, you need to put down the crack pipe Jan 07 16:44:49 kergoth: I'm not suggesting that. I'm suggesting I've seen some modes of failure you perhaps has not considered Jan 07 16:45:18 rp do you have an example? Jan 07 16:45:54 woglinde: An app playing with PATH which meant the libtool from /usr/bin was found in some cases? Jan 07 16:46:06 yeah app is dump Jan 07 16:46:16 like old sdl.m4 macro Jan 07 16:46:32 but how dolt can fix this? Jan 07 16:46:58 woglinde: Its nothing to do with dolt. Its whether the libtool hack that causes problems with dolt is needed Jan 07 16:47:02 hm not the app os dump Jan 07 16:47:14 the braindead developer Jan 07 16:47:26 I'm suggesting it still is to catch dumb apps. kergoth and pb_ are suggesting it serve no purpose which I diagree with Jan 07 16:47:29 * RP shrugs Jan 07 16:50:12 RP: and what about keep using the hack but make a symlink from libtool to ${fancyname}-libtool Jan 07 16:50:14 RP: I'm still not very convinced that libtool is any more significant in that respect than any of the other -native tools that we build. Jan 07 16:50:31 RP: so dolt would be happy about it and we'd not be arguing about it all Jan 07 16:50:32 We don't mangle the names of those just to catch apps that happen to stick "/usr/bin" on the front of $PATH. Jan 07 16:51:20 otavio: it then doesn't have any benefit, may as well drop the patch Jan 07 16:51:37 pb_: There is a school of thought that we should do more of this... Jan 07 16:52:18 grep m4 macros for usr/bin Jan 07 16:52:56 I've just seen it help on several occasions so I don't agree with it being totally useless. More intrusive and problematic than the small number of cases it helps, maybe Jan 07 16:53:58 I'm looking at improving boot speed with some sort of paralelizing init replacement. I don't see a "cinit" recipe. Is there any other oe init replacement that will parallelize startup tasks? Jan 07 16:54:10 upstart Jan 07 16:54:34 thank you. Jan 07 16:55:18 03Michael 'Mickey' Lauer  07org.openembedded.dev * r20e56bce4f 10openembedded.git/recipes/connman/ (connman.inc connman_0.46.bb files/link-against-libnl2.patch): connman: use libnl2 Jan 07 16:55:18 RP: yeah, I guess that is a fair way of describing it. I can see that it might have some value as a debugging aid, if you've got a recipe that's broken (or that you suspect might be), but it doesn't really seem like it is something that we must or should do routinely. Jan 07 17:23:30 btw I've one more fix for abiword: depend on gtkmathview Jan 07 17:24:01 it permit to have the mathml/latex math inside a document Jan 07 17:24:22 (I don't remember the exact name of the plugin it builds but it contain math) Jan 07 17:25:16 awozniak: check insserv maybe Jan 07 17:31:08 Hmmm Jan 07 17:31:24 Stuff like TARGET_LDFLAGS predates sysroot being fully functional in gcc/binutils, right? Jan 07 17:31:38 or at least early sysroot and maybe not fully trusted to do the right thing? Jan 07 17:32:44 can someone remind me what ?= does? Is that "assign if not already assigned"? or is it something else? Jan 07 17:33:21 jupp Jan 07 17:33:42 ?= defines the var if not yet set Jan 07 17:36:58 mmm,I'll ask in another channel how to make assign *permanently* an ip on a ubuntu-based distro....because I bet that's because of that that NFS doesn't work Jan 07 17:37:24 s/nfs/nfsroot Jan 07 17:37:57 networkmanager Jan 07 17:38:00 yeah yeah Jan 07 17:38:30 ah wait a se Jan 07 17:38:31 c Jan 07 17:39:04 /etc/network/interfaces section on eth0 is commented out Jan 07 17:40:16 mmm Jan 07 17:40:38 check if networkmanager runs Jan 07 17:40:40 it comes up then when the device kernel do dhcpcd it comes down Jan 07 17:40:40 and ban it Jan 07 17:40:43 no I killed it Jan 07 17:41:20 mmm Jan 07 17:41:31 nm-something that was not nm-applet was running Jan 07 17:41:48 nm-applet is gui stuff Jan 07 17:41:59 yes I know Jan 07 17:42:30 Laibsch: yes, I was interested in collie at some point, as I still have it. I just don't have time for all the gadgets... :) why are you asking? Jan 07 17:43:13 that's a common problem amongs us :) Jan 07 17:48:36 bye all Jan 07 17:48:56 does it say -13(permission denied) too when the link is downn Jan 07 17:49:02 for nfsroot Jan 07 18:01:37 Tartarus: yeah, those -L and -Wl,-rpath-link options have been in TARGET_LDFLAGS forever. they certainly predate sysroot support in the toolchain. Jan 07 18:15:20 OK, thanks Jan 07 18:15:47 they seem to be messing with my other changes to really be relocatable and reuse our pstaging stuff if $TMPDIR changes Jan 07 18:19:40 denix: bitbake didn't even start building for the collie for me. But it seems to be a problem with the minimal distro. Jan 07 18:19:51 Angstrom seems to be doing better. Jan 07 18:27:45 Laibsch: I see. I haven't tried building for collie for a long time... Jan 07 18:28:14 What's the name of the group working on resurrecting the Zs again? Jan 07 18:29:51 Laibsch: zaurus-devel@lists.linuxtogo.org Jan 07 18:30:55 or http://projects.linuxtogo.org/projects/zaurus/ Jan 07 18:31:20 indeed Jan 07 18:31:22 thanks Jan 07 18:31:28 Laibsch: ah you're memmber :) Jan 07 18:31:36 hehe Jan 07 18:31:37 yes Jan 07 18:31:49 but so little "official" activity that I forget Jan 07 18:32:08 I was never sure it needed an official wrapper outside of OE Jan 07 18:32:14 * Tartarus tries dropping out the -isystem stuff too Jan 07 18:32:14 I'm just spitz owner :) Jan 07 18:33:07 Tartarus: ? Jan 07 18:33:15 JaMa: I have one here, too Jan 07 18:33:19 do you use it? Jan 07 18:34:10 Laibsch: only for testing.. I tested xorg there before pushing and now I'm testing 2.6.33 kernels Jan 07 18:34:12 yes Laibsch? Jan 07 18:34:32 Tartarus: I didn't understand your comment about -isystem Jan 07 18:34:47 oh, sorry, just griping about my own issues :) Jan 07 18:35:04 making pstaging stuff work with a changing TMPDIR name and not have cross/native/sdk stuff be blacklisted Jan 07 18:35:06 Laibsch: I used it a lot at school as remote ssh console for screen running home.. but now I don't need it so much Jan 07 18:36:23 03Andrea Adami  07org.openembedded.dev * r0987059c05 10openembedded.git/recipes/kexecboot/ (2 files in 2 dirs): linux-kexecboot: updated defconfig for 2.6.32 and 2.6.33-rc3 Jan 07 18:36:34 03Andrea Adami  07org.openembedded.dev * r0fb0b4c624 10openembedded.git/recipes/kexecboot/ (3 files): linux-kexecboot: uniform the SRC_URI (defconfig in kernel recipe) Jan 07 18:36:34 03Andrea Adami  07org.openembedded.dev * re34bd279e0 10openembedded.git/recipes/kexecboot/ (3 files): linux-kexecboot_2.6x: fix SRC_URI (origins from linux-kexecboot.inc) Jan 07 18:47:03 woglinde, so can I commit the fix or will it make the possible revert harders? Jan 07 18:48:11 it's just that: Jan 07 18:48:18 -DEPENDS += " libwmf-native " +DEPENDS += " libwmf-native gtkmathview " Jan 07 18:51:37 * Laibsch is looking for a gtk+ expert Jan 07 18:52:06 hrw|gone: I see you upped the default version a couple of months ago to 2.14.2 Jan 07 19:02:41 Good morning :-) Jan 07 19:08:29 what's the "right way" to use upstart? I've tried setting DISTRO_INIT_MANAGER = "upstart" before anything else in my image recipe, but I still seem to get all sysvinit stuff. Jan 07 19:11:01 i don't think anyone is using upstart with OE except Palm Jan 07 19:11:06 you're a pioneer Jan 07 19:11:11 please share your findings once it works Jan 07 19:11:33 =( Is that the only option currently in OE for a parallelizing init? Jan 07 19:13:05 i'm afraid so. it doesn't seem anyone has been interested enough yet in another init system to make it happen in OE Jan 07 19:13:19 ok, thx Jan 07 19:13:21 we ahve to many init systems as it is :) Jan 07 19:13:38 what is available besides sysvinit ? Jan 07 19:15:25 to be honest... nothing Jan 07 19:15:33 upstart may be present in an old form as bb Jan 07 19:15:37 but that doesn't mean you can just switch Jan 07 19:15:45 as there is no support for initscripts != sysvinit Jan 07 19:15:53 ok, thx. Jan 07 19:15:55 so you have to do a bit more work on that Jan 07 19:16:00 but it would be much appreciated Jan 07 19:39:16 03Rolf Leggewie  07org.openembedded.dev * r54ba2e73a4 10openembedded.git/recipes/images/fso2-console-image.bb: fso2-console-image: fso-autorev.inc has to be included for this image to compile Jan 07 19:40:45 Laibsch: ^^ what was missing? Jan 07 19:41:04 Laibsch: all fso versions should be pinned in sane-srcrevs-fso Jan 07 19:43:08 JaMa: Ask Mickey, he should know better. But some stuff needs bleeding edge versions to compile. Mickey updates sane-srcrevs only from time to time. The stuff in fso-autorev.inc is set to, hm, autorev ;-) Jan 07 19:43:43 well Jan 07 19:43:53 updating sane-srcrevs would be preferred Jan 07 19:43:58 but i'm lazy Jan 07 19:44:37 next time i update sane-srcrevs.inc i'll revert that commit Jan 07 19:44:40 ok? Jan 07 19:45:00 I guess it should fail for me the same as shr uses fso2-compilance too Jan 07 19:45:18 but building that image here atm Jan 07 19:45:33 i guess you are having updated sane-srcrevs aren't you? Jan 07 19:45:44 yes about fsotdld Jan 07 19:45:54 and it built ok then Jan 07 19:53:27 mickey|sofa: ready? Jan 07 19:55:07 give me 5 minuts Jan 07 19:57:16 ~logs Jan 07 19:57:17 All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged. Jan 07 19:58:35 !logs Jan 07 19:58:36 Channel logs for #oe are archived at: Jan 07 19:58:37 http://hentges.net/tmp/logs/irc/%23oe Jan 07 19:58:38 Live-logs are available at Jan 07 19:58:39 http://hentges.net/tmp/logs/irc/livelogs/%23oe.livelog Jan 07 19:58:41 See ?? help-logs for usage instructions Jan 07 19:59:44 is that TSC jabber meeting private? or can other OE users join RO? Jan 07 20:00:03 private Jan 07 20:00:42 just so we can get the TSC running, the plan is to hold actual TinkSC meetings publically I th Jan 07 20:00:57 oki Jan 07 20:02:15 XorA: ready, will you invite me or should i try to join the conference? Jan 07 20:02:56 mickey|sofa: just join Jan 07 20:03:02 mickey|sofa: invites dont seem to work Jan 07 20:03:29 hmm Jan 07 20:03:38 "Not acceptable. Jan 07 20:03:38 The recipient or server understands the request but is refusing to process it" Jan 07 20:03:39 fun Jan 07 20:03:48 arse, koen and RP are there Jan 07 20:03:59 let me try "join groupchat" Jan 07 20:04:09 that needs more details though Jan 07 20:04:12 like a room info Jan 07 20:04:50 mickey|sofa: did you get a contacts request from me? Jan 07 20:04:55 not yet Jan 07 20:05:02 maybe I typoed you then Jan 07 20:05:19 mickey@totalueberwachung.de Jan 07 20:28:46 * pb___ wonders idly which of the TSC members is now known as "arse" Jan 07 20:29:00 hm? Jan 07 20:29:29 arse, koen and RP are there Jan 07 20:30:04 probably xora usese this for himself Jan 07 20:30:08 heh Jan 07 20:31:01 well, let's hope they're having a productive meeting Jan 07 20:31:30 :-D Jan 07 20:32:47 I hope too Jan 07 20:33:48 the arse commet was because I arsed up Jan 07 21:11:00 effem please wait with vdr Jan 07 21:11:10 I am making it right this time Jan 07 21:31:10 Crofton: are you managing cgit.openbembedded.org? Jan 07 21:31:32 only the dns Jan 07 21:31:41 I see,thx Jan 07 21:31:57 wo can add a quary based on commit-id ? Jan 07 21:32:02 *query Jan 07 21:32:14 like on ltg? Jan 07 21:33:32 ant__: why not use http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=HASH directly? if you know the commit-id? Jan 07 21:34:09 well, it's easier searching in google :) Jan 07 21:36:54 re Jan 07 21:37:06 hi hrw Jan 07 21:41:36 jo hrw Jan 07 21:41:57 hi all Jan 07 21:42:05 jo florian Jan 07 21:43:44 pb___: Its productive :) Jan 07 21:44:43 * ant__ wonders about pb___ not having been invited... Jan 07 21:46:27 invited? is there a party? Jan 07 21:46:52 RP: very good! Jan 07 21:48:47 XorA: what to drink ? ;D Jan 07 21:49:28 03Stanislav Brabec  07org.openembedded.dev * rffa2af8426 10openembedded.git/recipes/iw/iw_0.9.18.bb: iw: New package: nl80211 based CLI configuration utility for wireless devices. Jan 07 21:52:37 hi ph5 Jan 07 21:52:50 03Stanislav Brabec  07org.openembedded.dev * r5c9878edf2 10openembedded.git/recipes/mc/mc.inc: mc: Properly pass *_FOR_BUILD variables. Jan 07 21:53:12 hej woglinde Jan 07 21:54:27 woglinde: saw your email, decided others would jump on it and didn't have too much time, so didn't work on it. Jan 07 21:55:01 effem :) Jan 07 21:56:03 ah just finished Jan 07 21:56:53 cool Jan 07 21:57:34 got a libc rebuild, got this in the log: Jan 07 21:57:34 NOTE: the following files were installed but not shipped in any package: Jan 07 21:57:34 NOTE: /etc/rpc Jan 07 21:57:34 NOTE: Multiple libraries (libnss_nisplus.so.2, libnss_nis.so.2, libnss_hesiod.so.2) found, but LEAD_SONAME 'libc.so' doesn't match any of them Jan 07 21:58:22 eFfeM1 jupp Jan 07 21:58:26 but its okay Jan 07 21:58:47 libnss have there own package Jan 07 21:59:02 For anyone wondering, there will be a summary of the TSC discussion in the next few days Jan 07 21:59:27 We have reached some agreements on how to do things, we just need to condense the log a bit as its not useful as it is ;-) Jan 07 21:59:57 most important thing we decided to use CVS, git just isnt working for us Jan 07 22:00:00 03Henning Heinold  07org.openembedded.dev * r928760831e 10openembedded.git/recipes/vdr/ (files/libintl.patch files/linkerflags.patch vdr_1.7.10.bb): Jan 07 22:00:00 vdr: fix libintl problem now the right way Jan 07 22:00:00 * bump PR Jan 07 22:00:01 RP thanks for the info Jan 07 22:00:21 XorA: sssh ;-) Jan 07 22:00:24 XorA may I propose to use sccs instead, much smaller :-) Jan 07 22:00:44 eFfeM1: only if we can write rshfs Jan 07 22:00:56 XorA: It was deciding that RCS was a bit too oldhat that surpised me... Jan 07 22:01:27 I was beaten up for trying to get us to use a modern system like VSS Jan 07 22:01:35 03Stanislav Brabec  07org.openembedded.dev * r6c309dec53 10openembedded.git/recipes/imagemagick/ (3 files): imagemagick: Add more probably wanted optional libraries to DEPENDS. Jan 07 22:01:35 03Stanislav Brabec  07org.openembedded.dev * r781670e724 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jan 07 22:01:59 woglinde: not sure if that is why my build failed, rebuilding now, got several screenfuls of package messages so now just did a rebuild of what I wanted to build and see where it fails Jan 07 22:07:59 hm, no idea what was wrong, did a rebuild and everything is ok Jan 07 22:08:13 anyway, calling it a day, stay well everyone Jan 07 22:08:17 effem *g* Jan 07 22:08:23 nite effem Jan 07 22:15:00 03Stanislav Brabec  07org.openembedded.dev * re9dac0c87c 10openembedded.git/conf/checksums.ini: checksums.ini: Added missing iw. Jan 07 22:19:51 I'd suggest we sack the TSC then! Jan 07 22:20:05 except some of them might volunteer :) Jan 07 22:23:35 XorA : In order to keep in sync the "annual" OE change of revision control systems ? :) Jan 07 22:24:30 03Martin Jansa  07org.openembedded.dev * r6962a060a7 10openembedded.git/ (2 files in 2 dirs): Jan 07 22:24:30 sane-srcrevs-fso: update to HEAD, remove autorev-fso from fso2-console-image as it should compile again Jan 07 22:24:30 Signed-off-by: Martin Jansa Jan 07 22:31:51 JaMa: I can't compile the latest libfsoframework: http://tinderbox.openembedded.org/packages/libfsoframework/ Can you? Jan 07 22:34:25 Laibsch: I could before.. now I updated it in sane-srcrevs-fso and it should work now Jan 07 22:35:15 As far as I can see you were not compiling r690 Jan 07 22:35:22 but some other revision Jan 07 22:35:44 but if fso2-console-image works with the current config that is all that matters, really Jan 07 22:39:46 Laibsch: that's because I added my nick to tinderbox about a week ago.. Jan 07 22:40:10 Laibsch: I had it built before as well as shr, ane that revision I just built is the new one from sane-srcrevs-fso Jan 07 22:54:42 great Jan 07 22:57:04 03Rolf Leggewie  07org.openembedded.dev * rdb5e614427 10openembedded.git/recipes/gtk+/ (10 files): gtk+: unify Jan 07 23:04:55 http://www.nvidia.com/docs/IO/86562/NVIDIA_Tegra_200_Series_Developer_Kit_large.jpg Jan 07 23:05:06 ARM A9 + GPU goodies Jan 07 23:09:07 likewise yo tegra is known since last year Jan 07 23:09:29 was announced together with ion Jan 07 23:10:12 I know, this tegra 2nd gen. Jan 07 23:10:46 I hope to see this into a OE project in 2010. :-) Jan 07 23:10:55 oh okay Jan 07 23:14:52 03Stanislav Brabec  07org.openembedded.dev * r2cada8a1fd 10openembedded.git/recipes/lzma/ (lzma-native_4.65.bb lzma.inc): lzma: Stage lzma binary, initramfs-kexecboot-image depends on it (removed do_stage and added NATIVE_INSTALL_WORKS). Jan 07 23:20:38 03Martin Jansa  07org.openembedded.dev * ra3a6a36b29 10openembedded.git/ (3 files in 2 dirs): vala: bump to 0.7.9.4, needed for latest fsonetworkd Jan 07 23:21:18 hi booxter Jan 07 23:21:21 aeh re Jan 07 23:23:28 cbrake: gitweb.openembedded..org is not working as expected. Is that even necessary anymore? Jan 07 23:26:52 03Stanislav Brabec  07org.openembedded.dev * rf5d6a36c34 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jan 07 23:26:54 03Stanislav Brabec  07org.openembedded.dev * rae0eaaddcb 10openembedded.git/recipes/kexecboot/initramfs-kexecboot-image.bb: initramfs-kexecboot-image: DEPENDS on lzma-native. Jan 07 23:31:43 jo raster Jan 07 23:37:27 woglinde: wogz! Jan 07 23:39:54 :-) Jan 08 00:09:31 nites all Jan 08 00:28:29 should BB_NUMBER_THREADS=PARALLEL_MAKE= or BB_NUMBER_THREADS * PARALLEL_MAKE= ? Jan 08 00:29:03 grg: later one Jan 08 00:29:23 grg: actually it could be BB_NUMBER_THREADS * PARALLEL_MAKE= Jan 08 00:30:08 ok, so i'll set BB_NUMBER_THREADS=2 and PARALLEL_MAKE= Jan 08 00:30:15 Well, I use THREADS=cpus, MAKE=cpus*1.5 Jan 08 00:30:26 that seems to max out my stuff Jan 08 00:33:35 grg: how many cores do u have Jan 08 00:33:46 khem, 8 Jan 08 00:33:54 i7 Jan 08 00:36:17 nite Jan 08 00:39:12 grg: wow! you could just beat it to death Jan 08 00:40:20 grg: You could use BB_NUMBER_THREADS=4 PARALLEL_MAKE=4 Jan 08 00:41:06 khem, I'll try a few builds from scratch with various settings and determine the fastest... Jan 08 00:41:13 yeah Jan 08 00:41:29 some packages explicitly ask for -j1 Jan 08 00:42:54 * khem wishes to have a faster machine Jan 08 00:45:30 i've been using a p4 2.4GHz, 1GB ram for the last 6 months. This i7 is a nice change Jan 08 00:57:31 I bet Jan 08 00:57:42 I have 3.04G P4 with 2G Jan 08 00:59:15 heh.. I have a 3.06 P4 with 4G :) Jan 08 01:54:19 my disk space is used full by OE, and the build is not complete. how could I release some space and let the build going on? Jan 08 02:00:43 hrmph, i thought i had rejoined this.. but no, i had joined an empty #oe on the work irc network.. and talked to myself for a bit.. Jan 08 02:00:46 that was helpful. Jan 08 02:06:39 my building process is not complete, it's stopped by disk i/o error, I can't remove work directories, cause I need many of them to process my buildings Jan 08 02:07:26 disk i/o error sounds ominous Jan 08 02:07:41 heh Jan 08 02:07:51 kergoth, you are having senior moments :) Jan 08 02:08:01 heh :) Jan 08 02:08:21 at least i actually step back and take a breather when i get pissed, now, instead of just sitting in here being an ass. progress! Jan 08 02:08:30 now to stop talking to myself and forgetting things.. Jan 08 02:16:18 disk i/o error is caused by full use of disk by oe. Jan 08 02:17:01 eh? no, that's not normal behavior, you probably have a hardware or driver problem Jan 08 02:28:59 oh bite me, net-snmp Jan 08 02:49:57 sorry, I can't follow you. Jan 08 02:53:39 favor, if your disk is full and your build is incomplete, you need a bigger disk Jan 08 02:54:13 oe needs about 40GB for the image i build Jan 08 02:54:17 and an i/o error is quite different from running out of space. the latter is normal, the former is not Jan 08 02:58:11 the build is going on well, except the disk usage is 100%. i only have a 20G disk for OE. if the I/O error is not normal error, why is it cuased after the disk is full used. Jan 08 02:59:01 as grg says, you'll need more space than that, anyway. have you tried INHERIT += "do_work"? Jan 08 02:59:03 er Jan 08 02:59:06 INHERIT += "rm_work" **** ENDING LOGGING AT Fri Jan 08 02:59:57 2010