**** BEGIN LOGGING AT Fri Feb 19 02:59:57 2010 Feb 19 06:24:33 03Martin Jansa  07org.openembedded.dev * r5dc20028e1 10openembedded.git/ (3 files in 3 dirs): Feb 19 06:24:33 libphone-utils, python-phoneutils: bump SRCREV, move it to recipe Feb 19 06:24:33 Signed-off-by: Martin Jansa Feb 19 07:08:26 while am bitbaking clutter getting error like Feb 19 07:08:28 NOTE: Tasks Summary: Attempted 2054 tasks of which 2054 didn't need to be rerun and 1 failed. Feb 19 07:08:28 ERROR: '/home/siji/OE/openembedded/recipes/powervr-drivers/libgles-omap3_3.00.00.09.bb' failed Feb 19 07:08:38 Log file is also blank Feb 19 07:08:43 how to fix this? Feb 19 07:21:08 help pls Feb 19 07:21:10 ;( Feb 19 07:35:44 I got the solution Feb 19 07:35:46 ;) Feb 19 07:52:18 03Martin Jansa  07org.openembedded.dev * r8e6fa2fa14 10openembedded.git/recipes/xorg-xserver/xserver-xorg_git.bb: Feb 19 07:52:18 xserver-xorg_git: add hack for ignoring fbdev return mode Feb 19 07:52:18 Signed-off-by: Martin Jansa Feb 19 07:54:51 gm Feb 19 08:18:15 good morning Feb 19 08:18:17 or day Feb 19 08:20:22 Im planning of adding support for the sigma smp86xx into OE Feb 19 08:20:36 But I have some question about their hardware abstraction layer, howto deal with that. Feb 19 08:21:06 license technically Feb 19 09:10:45 morning Feb 19 09:11:39 is pkg_resources some standard python module? with bitbake master I get: Feb 19 09:11:41 File "/usr/lib64/python2.6/site-packages/bb/parse/parse_py/ConfHandler.py", line 42, in init Feb 19 09:11:44 from pkg_resources import Requirement, resource_filename Feb 19 09:14:49 ahh it's provided by setuptools so it should be added as bitbake dependency in ebuild Feb 19 09:15:18 ebuild? Feb 19 09:15:52 mickey|office: gentoo "package" Feb 19 09:15:55 hi , did someone used directfb on angstrom ? and microxwin ? Feb 19 09:16:15 JaMa|Wrk: ah, you're working w/ gentoo Feb 19 09:16:40 mickey|office: as I'm using that minimal chroot.. I got minimal system where setuptools weren't installed Feb 19 09:17:01 mickey|office: and bitbake-1.8 works ok and bitbake master is lacking this pkg_resources .. Feb 19 09:17:08 pb_: good morning. fwiw, i have now added a thread that reads blocking from this broken driver ;) perhaps it's going to be fixed when it comes in mainline Feb 19 09:17:20 JaMa|Wrk: i see, makes sense Feb 19 09:17:22 mickey|office: good morning. heh, right, good plan. Feb 19 09:17:58 mickey|office: interesting that bitbake use setuptools to install itself.. and it wasn't installed :) Feb 19 09:18:27 *nod* Feb 19 09:18:33 * mickey|office yawns... 4h sleep is not enough Feb 19 09:18:46 * JaMa|Wrk agree Feb 19 10:07:19 good morning Feb 19 10:09:33 hey florian Feb 19 10:09:58 hi Feb 19 10:25:30 ~logs Feb 19 10:25:31 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. Feb 19 10:33:20 XorA: thanks. learned soemthing today, namely that lines starting with spaces are not logged :-) Feb 19 10:34:41 eFfeM-work: actually ibot isnt logging anymore it seems Feb 19 10:37:10 XorA: hm indeed, maybe send an email to tim Feb 19 10:37:13 XorA: eh? yesterday's log is there. Feb 19 10:37:16 riker Feb 19 10:37:27 http://ibot.rikers.org/%23oe/20100218.html.gz Feb 19 10:37:38 pb_: all I see is logins and outs Feb 19 10:37:41 pb_: no chat Feb 19 10:37:57 er, weird. I see all the chat just fine. Feb 19 10:38:00 same for other channels Feb 19 10:38:02 23:46.48 Tartarus task-sdk-native Feb 19 10:38:02 23:47.02 Tartarus Some of the naming stuff drives me crazy, but i suck at names :) Feb 19 10:38:02 23:50.43 tharvey Tartarus, thx - I'll give that a shot Feb 19 10:38:13 those are the last three lines from ibot's log, which roughly matches what I see in my xchat scrollback Feb 19 10:38:15 pb_: odd I do now Feb 19 10:40:25 ah, found it, the link from pb_ contains %23oe/ if you go to the page as given by the bot and click on a date in the calendar you get a page without %23oe/ in the url Feb 19 10:40:44 will drop tim an email Feb 19 10:44:11 Actually wont, if you exactly do what it says it is ok Feb 19 10:44:19 http://ibot.rikers.org/%23oe/ does work as expected Feb 19 10:44:37 http://ibot.rikers.org/#oe/ does not Feb 19 10:45:14 and ~logs indeed mentions the %23 Feb 19 10:45:35 my fault then :-) Feb 19 10:54:36 XorA: fell into that one too once Feb 19 12:04:42 morning Feb 19 12:09:01 hi hrw Feb 19 13:32:03 03Martin Jansa  07org.openembedded.dev * r33a15ddec7 10openembedded.git/recipes/udev/ (files/shr/mount.blacklist udev_151.bb): Feb 19 13:32:03 udev: blacklist mmcblk mounting for SHR Feb 19 13:32:03 Signed-off-by: Martin Jansa Feb 19 14:07:37 re Feb 19 14:14:55 ;] Feb 19 16:07:44 bye Feb 19 16:31:48 hi all - can anyone point me in the right direction for a channel for discussing jtag adapters? Feb 19 16:32:24 (specifically, i'm trying to find out about whether it's practical to use jtag to trace execution within an Atom, and if so, what people use to do so) Feb 19 16:35:35 when should you use RDEPENDS_${PN} vs RDEPENDS? I assumed setting RDEPENDS in a recipe was correct but found that it didn't take until I changed it to RDEPENDS_${PN} Feb 19 16:37:21 RDEPENDS affects *all* binary packages, not just hte main one Feb 19 16:37:31 unless you plan on making your docs and debug fiels depend on it too, its wrong Feb 19 16:40:10 ah... ok, that makes sense, but I still wonder why in my case the values did not get put into the pkg depends - perhaps its overridden somewhere in a class? Feb 19 16:40:31 could be, though classes shouldn't be setting it either :) Feb 19 16:41:04 INHERIT += "recipe_sanity" .. bitbake -c recipe_sanity foo (or -c recipe_sanity-all) will warn you if RDEPENDS is set to anything, among other things Feb 19 16:43:10 cool - sounds like thats a great check to run before commiting a recipe Feb 19 16:45:38 still looking into a possible dependency issue with gtk+ recipe: looks like there is some auto-native magic that allows a normal recipe to be built as 'foo-native' as well instead of requiring a foo-native.bb - is that correct? Feb 19 16:48:38 tharvey, BBCLASSEXTEND = "native" in the recipe. Feb 19 16:48:56 recipes are slowly being switched to it Feb 19 16:50:05 ok, so in that case the gtk+ recipe uses that, and thus gtk+-native exists as well. However that recipe needs jpeg-native as a dep, but since its a generic recipe it just has 'jpeg' as a dep - should the BBCLASSEXTEND = "native" magic be adding all -native deps automagically too then? Feb 19 16:54:55 tharvey, yeah, exactly, it goes over the deps and automatically adds the -natives to them Feb 19 17:05:54 03kergoth  07org.openembedded.dev * reb0440f81b 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): Feb 19 17:05:54 xserver-kdrive: apply vm86_masks.patch to 1.4.2 also Feb 19 17:05:54 Signed-off-by: kergoth Feb 19 17:06:11 bah, forgot to fix my info in .gitconfig :P Feb 19 17:11:23 kergoth, then something must be broken because virtual?native:org.openembedded.dev/recipes/gtk+/gtk+_2.18.6.bb do_configure is failing because libjpeg is missing (jpeg-native is not getting built prior even though jpeg is a DEPENDS of that recipe) Feb 19 17:11:37 well, check DEPENDS with bitbake -e, then Feb 19 17:11:44 bitbake -e gtk+-native|grep \^DEPENDS= Feb 19 17:11:50 see if its what you think it is :) Feb 19 17:11:53 I see DEPENDS_virtclass-native defined in that recipe - seems like perhaps that is where 'jpeg-native' (and a couple others) should be added Feb 19 17:12:12 ah, yes, its overridding it for the bbextendclass native case Feb 19 17:13:04 ok, then the following should be added 'jpeg-native', 'libext-native', 'libxrender-native' Feb 19 17:13:23 well, the question is, why is it being overridden to begin with? :) Feb 19 17:13:30 was just going to ask that ;P Feb 19 17:13:42 is there something the bbextendclass is not adding that it should be adding? if that's the case, it can _append_virtclass-native instead.. Feb 19 17:13:48 heh Feb 19 17:13:49 perhaps because some of the DEPENDS really are not deps for the native case? dunno why that would be Feb 19 17:14:00 possible Feb 19 17:14:10 * kergoth shrugs Feb 19 17:14:13 the real interesting question is why this is an issue for me on one build machine but not another heh Feb 19 17:14:35 heh Feb 19 17:14:38 good question Feb 19 17:15:10 I bet there are a ton of dep issues in recipes that get missed because of other things that are built in your task/images Feb 19 17:15:58 ultimate recipe test would be to foreach recipe in recipes rm -rf $TMPDIR; bitbake recipe Feb 19 17:16:30 even that woudln't be quite enough to catch every case.. that woudl catch the missing dep case, but there's also build ordering issues where something enables functionality conditionally, only if recipe FOO was built before it Feb 19 17:16:43 * kergoth got bit by that a lot trying to use pstage packages :\ Feb 19 17:17:28 true Feb 19 17:17:48 has any work been done on setting up automatic test systems for org.openembedded.dev? Feb 19 17:18:36 i think zecke and others have done some work on automatic builds with the buildbot and stuff, but i don't know how much people have looked into trying to find issues like this Feb 19 17:18:42 * kergoth shrugs, would be nice Feb 19 17:18:56 would be nice to set up automatic builds on a variety of virtual machines, too, to test with a variety of distributions Feb 19 17:19:03 with varying amounts of installed software Feb 19 17:28:53 cbrake, whenever you're around, can you add that new public key version of me to the bitbake repo too? :) Feb 19 17:29:09 cbrake, or give me access to the gitosis ;) Feb 19 17:29:23 * kergoth grumbles, computer hates him today Feb 19 17:34:24 kergoth: added you to gitosis-admin and bitbake Feb 19 17:39:56 hmm. Feb 19 17:40:42 cbrake, think you could remove the kergoth/* branches from bitbake on the git server for me? i don't think the hooks will allow me to push a removal. going to use a separate repo for my proof of concept stuff instead Feb 19 17:40:45 :) Feb 19 17:49:55 oh, hah Feb 19 17:50:09 the hooks let you delete a remote branch, but not update it to a non-fast-forward? Feb 19 17:50:14 where's the logic there? :) Feb 19 17:52:11 pb_: ping Feb 19 17:52:52 pb_: what's the purpose of PKGV? how is it different from PV? :) thanks Feb 19 17:54:46 denix: it's exactly what it sounds like, the version for the binary package. iirc, PKGV/PKGR is how DISTRO_PR gets into the package, but without altering PR Feb 19 17:55:02 i think pb wants to use PKGV as the place where the git/srcrev stuff goes, rather than PV changing Feb 19 17:55:31 * kergoth knows pb will have a better answer, but figured he'd throw out what he does know in case pb isn't around Feb 19 17:58:19 03Thomas Zimmermann  07org.openembedded.dev * r0a831e2cd1 10openembedded.git/recipes/eglibc/ (eglibc-package.bbclass eglibc.inc): (log message trimmed) Feb 19 17:58:19 eglibc: unbash ldd and add libpthread_nonshared.a to -dev Feb 19 17:58:19 * replace shebang of ldd by /bin/sh, so ldd doesn't depend on bash Feb 19 17:58:19 anymore. Tested with busybox sh. Feb 19 17:58:19 * added to do_configure_prepend because do_patch is only a python function Feb 19 17:58:20 * add libpthread_nonshared.a to eglibc-dev. Now it's possible to Feb 19 17:58:21 compile multithreaded applications on the device. Feb 19 17:59:51 yeah, pretty much what kergoth said. PKGV is to PV like PKG is to PN. Feb 19 18:00:04 kergoth: yes, had to change PV=x.y.z to PKGV=x.y.z to alter the version of my package, but why? Feb 19 18:00:23 eh, PKGV defaults to PV.. Feb 19 18:00:26 see package.bbclass Feb 19 18:00:38 kergoth: yes and no Feb 19 18:01:06 kergoth: PV gets set from recipe name, PKGV = PV. then if you change PV in the recipe, it won't take it Feb 19 18:01:30 ? Feb 19 18:01:33 that doesn't make any sense. Feb 19 18:01:34 it should do. it's not a := assignment. Feb 19 18:01:39 what's the case that is actually failing for you? Feb 19 18:01:59 if there is a specific recipe that is going wrong then I will certainly have a look at it. Feb 19 18:02:50 I have an external-toolchain-csl recipe, which repackages codesourcery into gcc, glibc etc. I used to set PV_glibc=2.8 and it carried over to the binary IPK. no it doesn't work, had to change to PKGV_glibc=2.8 instead Feb 19 18:03:31 the main PV of the recipe is different though... Feb 19 18:03:35 oh, I see, you are trying to override PV for subpackages. yeah, I could believe that that doesn't work anymore. Feb 19 18:04:05 ah, that would make sense then Feb 19 18:04:16 is it a bug or feature? :) Feb 19 18:04:23 setting PV for a subpackage never made a great deal of semantic sense (just the same as setting PN_subpackage would be slightly nonsensical) so, in that sense, the new behaviour is a feature. Feb 19 18:05:42 it would be possible to introduce a backwards compatibility hack if you really need to retain the old behaviour though. Feb 19 18:06:07 bbiab, gotta go pick up my sister-in-law from the train station Feb 19 18:06:23 ah, I see the point. to change the name of the package we do use PKG_subpkg=name, hence the PKGV natation... makes sense! Feb 19 18:06:59 pb_: I personally don't care for compatibilty, just needed to understand myself :) thanks! Feb 19 18:08:25 Anyone know a way to build a kernel using a config which is not a defconfig, maybe using KBUILD_DEFCONFIG? I patch arch/arm/configs/omap3_evm_defconfig in my recipe but would prefer to leave the original Feb 19 18:10:23 hoj: actually, standard kernel recipes come with own defconfigs and don't use arch/arm/configs ones... Feb 19 18:11:10 denix: hm I thought I had to bonk the defconfig.. Feb 19 18:11:37 hoj: which kernel recipe are you using? Feb 19 18:11:59 arago/recipes/linux/linux-omap3_psp3.0.0.3.bb Feb 19 18:12:15 hmmm... i should think about making some more ast nodes in master Feb 19 18:13:00 ah :) I see... that's "special" as it was required to use config from arch/arm/configs through "make defconfig"... unfortunately Feb 19 18:14:09 hoj: that's the recipe for TI PSP kernel and they insisted on this way. I guess I can fix that for you... Feb 19 18:15:46 hoj: by default, standard OE kernel recipes provide their own defconfig instead. like files/omap3evm/defconfig... so it's outside of the kernel tree, next to the recipe and easier to modify Feb 19 18:16:39 denix: I'll stick with my ugly patching for now. The non-special kernels sound nicer :) Feb 19 19:11:57 03Tom Rini  07org.openembedded.dev * rac71f240bf 10openembedded.git/recipes/dt/ (dt.inc dt_15.14.bb files/no_aio.patch): Feb 19 19:11:57 dt: convert to .inc, add no_aio patch for uclibc Feb 19 19:11:57 Signed-off-by: Tom Rini Feb 19 19:11:57 Signed-off-by: Chris Larson Feb 19 19:12:07 03Tom Rini  07org.openembedded.dev * rbd711cfab0 10openembedded.git/classes/package.bbclass: Feb 19 19:12:07 package.bbclass: when running 'file', be explicit about the path to the magic Feb 19 19:12:07 This works around one relocation issue. Feb 19 19:12:07 Signed-off-by: Tom Rini Feb 19 19:12:08 Signed-off-by: Chris Larson Feb 19 19:12:16 er.. damnit, that wasn't supposed to go Feb 19 19:12:18 * kergoth grumbles Feb 19 19:12:21 heh Feb 19 19:13:05 03Chris Larson  07org.openembedded.dev * r40eae51811 10openembedded.git/classes/package.bbclass: Feb 19 19:13:05 Revert "package.bbclass: when running 'file', be explicit about the path to the magic" Feb 19 19:13:05 Forgot to check a git status / log before pushing :) Feb 19 19:13:05 This reverts commit bd711cfab09394b6f3064eaed24b8761edc19f19. Feb 19 19:20:35 re Feb 19 19:22:25 JaMa|GoNe: ping, seen any issues with images failing moaning about missing libdrm2 (>= 2.4.17) since your libdrm bump? Feb 19 19:25:46 DJWillis: why whould it be missing? Feb 19 19:26:12 DJWillis: 2.4.18 should be available and build if needed (only for mesa-dri_git now) Feb 19 19:26:51 DJWillis: which recipe is failing for you? Feb 19 19:27:29 JaMa|GoNe: no idea, yep, confused the hell out of me :(, crept in since the bump and I can't track it down without reverting to a clean temp. It's a custom 'task' I have in my overlay just to make things painful to debug ;). Feb 19 19:37:27 DJWillis: I have an idea.. if you build libdrm is _git.bb or 2.4.18.bb built for you? Feb 19 19:38:14 DJWillis: hmm but _git.bb has D_P = -1 so it shouldn't be pulled for you Feb 19 19:55:50 Anyone around that would have an opinion on busybox + hwclock.sh de-suck? Feb 19 19:56:00 assuming it hasnt been fixed in the last month or so Feb 19 20:08:59 at some point of time someone should go over all initscripts Feb 19 20:09:06 many of them are containing ancient cruft Feb 19 20:09:12 that contradicts kernel work Feb 19 20:09:28 rtc and devtmpfs for example Feb 19 20:09:34 but there's more Feb 19 20:12:45 woohooo!!!! Feb 19 20:13:47 Oh yes, that too Feb 19 20:13:54 But that also gets into a min kernel cutoff kind of thing Feb 19 20:14:20 hwclock.sh has two problems, i think Feb 19 20:14:35 the one i can test quickly is doing HWCLOCKACESS=no, per machine, or so Feb 19 20:15:00 The other is using -f /dev/rtc0 or not since we're defaulting to devfs name Feb 19 20:16:33 * chouimat is listening to Realm Of Darkness by Darkwell on Suspiria [Amarok2] Feb 19 20:16:37 oops Feb 19 20:20:36 kergoth: hi Feb 19 20:21:40 hey kergoth Feb 19 20:22:18 hey Feb 19 20:35:35 how do I specify a postinstall script for a package that gets run on the target after bootup? seems like pkg_postinst is run on the image at buildtime and not runtime? Feb 19 20:35:54 I need to run 'dot -c' to register plugins with graphviz on target Feb 19 20:36:08 is there simple way to call build for every package built in tmp/ ? Feb 19 20:38:04 tharvey, if the postinst fails at build time, it'll be run on first boot. grep the repo for checks of $D in the pkg_postinst. if that var is non-empty, it's build time Feb 19 20:39:31 kergoth, thx sounds like what I need - hmm... how to do a grep of contents of pkg_postinst functions in bb's? do you know of any example recipes off-hand? Feb 19 20:41:38 ah I see one - xserver-nodm-init.bb - thanks Feb 19 20:41:49 git grep '$D'.. i doubt its used anywhere else Feb 19 20:41:53 np Feb 19 21:12:02 cbrake, think we can get the cia notification hook installed in the bitbake repository, the way it is in the OE repository? looks like the last notification to CIA for bitbake was november 10th, 2009 :) Feb 19 22:21:26 03Tom Rini  07org.openembedded.dev * r2b132068b1 10openembedded.git/recipes/xorg-app/xdm_1.1.9.bb: xdm: need to pass paths to wtmp/utmp, bump PR Feb 19 23:00:32 03Denys Dmytriyenko  07org.openembedded.dev * r5114a4e19d 10openembedded.git/recipes/meta/external-toolchain-csl.bb: Feb 19 23:00:32 external-toolchain-csl: add gconv/locale split magic Feb 19 23:00:32 Signed-off-by: Denys Dmytriyenko Feb 19 23:11:15 03Bernhard Kaindl  07org.openembedded.dev * r4f0d9f93c1 10openembedded.git/recipes/meta/ (external-toolchain-generic.bb external-toolchain.bb): (log message trimmed) Feb 19 23:11:15 external-toolchain: Really accept toolchains built by meta-toolchain.bb Feb 19 23:11:15 external-toolchain-generic, Feb 19 23:11:15 external-toolchain: Feb 19 23:11:15 * The current external-toolchain recipes which are documented to accept Feb 19 23:11:16 toolchains built by meta-toolchain actually do not accept such because Feb 19 23:11:17 they expect ${prefix}/package-status to exist which is provieded by Feb 19 23:27:55 03Denys Dmytriyenko  07org.openembedded.dev * rbbe55bc6a4 10openembedded.git/recipes/meta/meta-toolchain.bb: (log message trimmed) Feb 19 23:27:55 meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script Feb 19 23:27:55 Do not hard-code SDK location into all the libtool's .la files and other Feb 19 23:27:55 libtool, pkg-config and opkg service variables and aliases. Use $SDK_PATH Feb 19 23:27:55 environment variable instead, which is set once in the main environment-setup Feb 19 23:27:55 script, allowing easy SDK relocation by adjusting a single variable. Feb 19 23:27:56 This patch does not address gcc relocatability, if any. **** ENDING LOGGING AT Sat Feb 20 02:59:57 2010