**** BEGIN LOGGING AT Wed May 04 02:59:58 2011 May 04 04:21:02 grg , uboot works on regular pc ? May 04 04:28:39 JDuke128, dunno, never bothered to find out May 04 04:28:56 you could use grub or lilo on a x86/x86_64 May 04 04:29:39 same thing applies, you just need your app to update the default os to boot and trigger a reboot. May 04 07:23:56 is this the right channel to ask help with building openembedded? May 04 07:27:54 usually...europe is just waking up. May 04 07:30:57 I'm behind a proxy. I get parsing errors like "fatal: unable to connect a socket (Connection timed out)". Even though I have wget properly configured. I have the proxy specified in ~/.wgetrc and it works great. But when running tcpdump, I see direct references to projects.goldelico.com.git. So I'm unsure what I'm to do May 04 07:32:02 so it's not wget's fault, I guess. Is it git? But I've clonned openembedded successfully May 04 07:33:57 what are you trying to "git"? May 04 07:34:00 a package? May 04 07:34:13 Hi guys May 04 07:34:24 http://pastebin.com/WgDRwJbN this is the log of building May 04 07:34:49 Which is the best way in yocto to add a package configure option only for a certain machine ? May 04 07:37:34 slidercrank, bbfetch...better wait for someone from .eu on that one. May 04 07:37:48 mrAlmond, did you ask in #yocto? May 04 07:39:03 okay finished packing...3hrs of sleep and then outta here... May 04 07:39:07 laters. May 04 07:40:23 ka6sox-work : I didn't ask in yocto because we speak about yocto/poky/oe also here May 04 07:40:40 good morning May 04 07:40:52 mckoan: hi! May 04 07:46:56 hi guys ... with a latest git pull i get alot of those errors ? May 04 07:46:59 ERROR: EOL while scanning string literal (, line 1) while parsing /data/devel/oe/openembedded-next/recipes/uclibc/uclibc_0.9.30.3.bb May 04 08:18:47 mickeyl thanks for the pyqt update May 04 08:39:10 hiya May 04 08:39:30 kgilmer_: konnichiwa May 04 08:39:32 he kgilmer May 04 08:39:36 hi mckoan May 04 08:39:37 is there a naming convention for recipes that do not compile, just bring in some binary thing for the rootfs? May 04 08:39:43 hi mckoan woglinde May 04 08:39:44 ? May 04 08:39:54 no May 04 08:39:59 call it as you want May 04 08:40:04 woglinde, ok May 04 08:40:10 ups name it May 04 08:40:27 woglinde, http://leafcutter.org/ May 04 08:41:01 thx for your help last year w/ openjdk recipes on armv6 May 04 08:41:40 kgilmer ,) May 04 10:06:10 I had a builded a filesystem with rdesktop using buildroot for MIPS..... and I had ported on development board ... but when I try to connect rdesktop.... at first attempt it doesnot connect with right username and password ......why it is so? can anyone help me... at first attempt it always give me a segmentation fault........ May 04 10:37:01 mickeyl: good morning May 04 10:37:38 woglinde: you're welcome. May 04 10:37:42 good morning pb_ May 04 10:49:53 hi. i'm getting a compilation issue when building virtual/kernel for beagleboard. the package perl-native fails with undefined references to pthread and math functions May 04 10:50:25 the linker command doesn't have -lpthread or -lm May 04 10:50:48 this is on ubuntu 11.04 following these instructions http://www.angstrom-distribution.org/building-angstrom May 04 10:55:25 guys I've done some temporary modifications to source code in the tmp/work directory...how can I force the recompilation with bitbake without cleaning the whole package? May 04 10:58:36 mickeyl I wonder why it worked you May 04 10:58:46 my last tries didnt worked May 04 10:58:57 but that was 3/4 year ago May 04 11:01:45 hi woglinde May 04 11:01:54 he pb May 04 11:20:34 how can i see what files are inside a .ipk file? May 04 11:21:16 dpkg --contents May 04 11:21:49 mrAlmond bitbake -f -c compile foo May 04 11:23:58 thanks May 04 11:26:30 i'm a bit confused as to how i select packages for an image May 04 11:26:40 i have a recipe which creates multiple packages May 04 11:27:06 but if i add the name of the recipe directory in the IMAGE_INSTALL list of the image, only one of those packages gets installed in the image May 04 11:27:39 you have to choose the package names May 04 11:27:54 or the get dragged in by either automatic or forced dep May 04 11:28:14 ok. then the problem is that i don't really know what is the "package name" May 04 11:28:36 i've tried the base names of the ipk files the recipe generates, but bb says it can't find such packages May 04 11:29:34 is IMAGE_INSTALL the correct place to add packages for the image? May 04 11:29:47 do bitbake -e foo > foo.txt 2>&1 May 04 11:29:54 and grep for the line packages May 04 11:29:59 ups PACKAGES May 04 11:30:05 or grep -i packages May 04 11:32:02 woglinde, hi, were you using opie as environment? you told me something the other day but grep can't find it May 04 11:33:08 gnutoo not your May 04 11:33:11 ups yet May 04 11:33:23 maybee this evening I will try a build May 04 11:33:25 woglinde: thanks May 04 11:34:59 woglinde, what FB based env where you using then? May 04 11:35:06 opie still compile May 04 11:35:08 ? May 04 11:35:15 normal fb May 04 11:35:48 yes but you run something like qtopia,opie or something like that right? May 04 11:36:03 * GNUtoo|laptop wanted to try new environments May 04 11:36:34 opie has its own startscript May 04 11:37:51 yes I know May 04 11:38:16 I bitbaken opie just to try it May 04 11:38:22 and it has an opkg frontend May 04 11:38:36 and it's well integrated May 04 11:38:41 but I wonder about the games May 04 11:38:46 is there any good opie games? May 04 11:41:35 dont know what you define under good May 04 11:42:31 i tried also xfce46 image on nokia900 May 04 11:43:40 (opie was tried on htcdream since 800x480 is not supported) May 04 11:48:45 woglinde : tnx! May 04 11:55:51 GNUoo|n900: re opie games, agreed, depends what you define as good... there is a qte version of SDL that should allow you to play SDL-based games May 04 11:56:11 although there's a pending fix from anarsoul I haven't yet had time to look into May 04 11:56:29 plus there's the usual board type games... nothing particularly earth shattering there though May 04 12:00:12 good means like supertux,wesnoth etc... not like card games or kdegames May 04 12:01:16 lol May 04 12:03:00 03Paul Menzel  07master * rcd15fbacb6 10openembedded.git/recipes/proftpd/proftpd_1.3.3c.bb: (log message trimmed) May 04 12:03:00 proftpd 1.3.3c: add checksums May 04 12:03:00 Task fetch failed with the following error. May 04 12:03:00 NOTE: This package has no checksums, please add to recipe May 04 12:03:00 NOTE: May 04 12:03:00 SRC_URI[md5sum] = "4f2c554d6273b8145095837913ba9e5d" May 04 12:03:00 SRC_URI[sha256sum] = "44be095ed063df93278928cf665ad7b9b38e2c8d0cca97fb51307ec3a390a591" May 04 12:03:05 03Paul Menzel  07master * r457a9c0ffe 10openembedded.git/recipes/ushare/ushare_1.1a.bb: (log message trimmed) May 04 12:03:05 ushare: RDEPENDS → RDEPENDS_${PN} May 04 12:03:05 This is a fix up for commit 0fd385ef [1]. May 04 12:03:05 commit 0fd385ef5512def0db880139b1c9fa78f652f494 May 04 12:03:05 Author: Florian Boor May 04 12:03:05 Date: Fri Jan 29 13:11:18 2010 +0100 May 04 12:03:06 ushare: We need lsb-base in the filesystem. May 04 12:07:44 woglinde: (pyqt) well... it took me a couple of days to adjust to the changes they did upstream. Basically we're not using their buildsystem, but doing all on our own, otherwise we would not get it done anyways, since they're doing too much autodetection (self-written buildscript that mangles self-defined build-files resulting in qmake pro files which are then compiled w/ qmake... crazy stuff) May 04 12:08:06 mickeyl buildsystem yes I modelled it after your way May 04 12:08:15 and it compiled, but runtime was a mess May 04 12:09:11 with sip 5 they'll be changing it completely again :D May 04 12:09:15 already annonuced May 04 12:09:22 it may get better then May 04 12:09:30 hm we will see May 04 12:09:35 (or worse ;) May 04 12:09:36 what about pyside? May 04 12:09:49 we managed to get it done May 04 12:09:57 it's for review in our tree May 04 12:10:00 will submit soon May 04 12:10:11 s/submit/commit/ May 04 12:10:35 pushing cmake into shape wasn't easy either May 04 12:10:50 all that works fine... unless you start w/ cross May 04 12:10:54 then it gets ugly May 04 12:11:01 with their automisdetection May 04 12:12:12 thats why cmake suckz a lot too May 04 12:12:37 so you got crofton happy today May 04 12:12:39 ;) May 04 12:12:55 maybee he should have asked you before May 04 12:13:07 ka6sox-work: hi May 04 12:13:14 getting his hands dirty on pyqt and sip May 04 12:14:14 pyside has slight advantages when you want to make it work with QML May 04 12:14:26 although it's still a tad bit slower than PyQt May 04 12:16:10 hm the qml example on the riverside site doesnt looks this bad May 04 12:16:26 I need more time May 04 12:16:30 *nod* May 04 12:16:40 didnt yet played with qml for a project in real May 04 12:17:02 it's great. morphis and me just started to make a FSO client with it May 04 12:17:30 sure I saw the videos from last qt-days May 04 12:17:47 the software renderer could be a bit faster, but with the opengl engine it's a breeze May 04 12:18:02 unfortunately we don't have any foss gl on our devices May 04 12:18:22 * GNUtoo|laptop feared for a moment May 04 12:19:46 of course it's always depending on how many pixels to fill May 04 12:20:15 mickeyl gles you mean May 04 12:20:21 ya May 04 12:20:26 ;) May 04 12:27:41 ah I remember one thing about opie, maybe I didn't add the right inc file in the local.conf but the screenshot things pointed to handhelds.org if I remember well May 04 12:29:33 GNUtoo|laptop: yes that's a problem... I looked at updating to post to linuxtogo but their screenshot service does not use the same protocol, so it wasn't a 5-minute job May 04 12:29:57 ah ok May 04 12:30:27 I should probably at least create an opie bug report about that May 04 12:30:33 ok May 04 12:30:41 opie is still developped? May 04 12:30:55 yes, I'm still working on it May 04 12:30:58 (at least it compiles and runs) May 04 12:31:02 ok May 04 12:31:12 am trying to iron out the bluetooth stuff atm May 04 12:31:14 you're the one that has made the linuxtogo post then May 04 12:31:15 ok May 04 12:31:28 the linuxtogo post? May 04 12:31:34 let me find it May 04 12:31:39 on the planet May 04 12:31:54 oh yes, that's me May 04 12:32:37 http://bluelightningnz.blogspot.com/2011/03/opie-stuff.html May 04 12:32:39 yes May 04 12:32:39 ok May 04 12:33:45 is opie 1.2.5 the default in oe? May 04 12:36:41 seem that I bitbaken 1.2.4 May 04 12:36:50 I'll include the inc file May 04 12:37:06 I guess angstrom still points to 1.2.4 May 04 12:39:00 angstrom or SHR May 04 12:39:32 interesting, I was not aware SHR supported Opie... well, it does at least include the preferred version inc file May 04 12:54:47 bluelightning, it doesn't support it, I just built under SHR and it worked, that's all May 04 12:55:01 it doesn't support in the sense that opie doesn't use freesmartphone.org May 04 12:55:08 GNUtoo|laptop: right, ok May 04 12:55:23 so for instance wifi and bluetooth on om-gta02 won't work out of the box May 04 12:55:33 and in fact they don't May 04 12:55:43 hmm May 04 12:55:54 well, patches welcome :) May 04 12:56:27 in 1.2.6 having dbus and up-to-date bluetooth should make it easy to fix those issues however May 04 12:57:13 I'm still a bit unsure on how to support enabling/disabling bluetooth in a way that works for lots of different devices May 04 12:57:20 bluez doesn't really help out there May 04 12:57:39 hmmm May 04 12:58:15 bluelightning: rfkill! :) May 04 12:58:25 it works for lots of different devices May 04 12:58:59 does the rfkill system allow you to just turn off bluetooth? I thought it was "kill all RF devices"-only May 04 12:59:09 bluelightning no May 04 12:59:19 bluelightning: nope, you can turn off only bluetooth May 04 12:59:22 or only wifi May 04 12:59:22 what about stuff like that: May 04 12:59:25 bluelightning you can "soft" kill every device seperatly May 04 12:59:36 htcattach foo May 04 12:59:47 or echo > /some/sysfs/ May 04 12:59:56 GNUtoo|laptop: that's what I'm talking about, it's different for different devices May 04 13:00:07 bluelightning: it's common for rfkill May 04 13:00:10 for USB it's easy now, it just happens automatically via udev May 04 13:00:12 fso handle that but only for fso supported phones May 04 13:00:28 look through every /sys/class/rfkill/* entry, and find one for bluetooth (type == bluetooth) May 04 13:00:37 and then use it for turning on/off bluetooth May 04 13:00:57 anarsoul: but does rfkill work for enabling bluetooth on hciattach-requiring devices? I can't see how it could May 04 13:01:25 bluelightning: it does, for example ipaq h1940 uses its own rfkill driver for bluetooth May 04 13:01:39 however, you still need to do hciattach May 04 13:01:41 :) May 04 13:01:46 right, there's the problem May 04 13:02:02 I need to know how I can detect when hciattach needs to be run and what settings to run it with May 04 13:02:27 at some point there was a config file for that but I don't know whether it's something that's considered standard May 04 13:03:44 I really want to avoid the old crap in the opie code where it does "if device = blah then do this, if other device then do that, ...." May 04 13:04:19 which rapidly gets out of date May 04 13:04:25 hmm May 04 13:05:22 maybe at this stage it will have to be an opie-specific file but I'm surprised nobody has ironed out these details already May 04 13:05:52 gpe does already have an equivalent file, I guess it would be nice if they could be the same thing. May 04 13:07:49 pb_: that would be my preferred solution May 04 13:08:51 iirc, the package which writes it out is blueprobe May 04 13:10:05 pb_: is that maintained? May 04 13:10:44 good question. I'm not entirely sure. May 04 13:11:58 pb_: actually the code looks pretty straightforward, it's possible it doesn't need too much in the way of maintenance May 04 13:12:34 yeah May 04 13:12:38 seems to me though we could easily have pre-defined files for most machines (with built in bluetooth) May 04 13:12:45 I can certainly apply patches and make new releases if necessary May 04 13:13:11 ok, cool May 04 13:13:26 yes, indeed. the original requirement for blueprobe came about because the ipaq h39xx has optional bluetooth May 04 13:13:36 (and h54xx too, I think) May 04 13:13:52 ah yes May 04 13:13:58 most machines could just have a static file, you're right May 04 13:14:44 so I wonder if we can rely on blueprobe/static file + rfkill... will that be enough? May 04 13:15:06 will depend on whether we have to support old kernels that don't have rfkill I guess, since it's pretty new AFAIK May 04 13:15:34 I guess the only other obvious case is cf/sdio/usb adapters which would need supporting somehow May 04 13:15:40 but otherwise yes May 04 13:17:43 well those sorts of devices ought to be taken care of by udev May 04 13:18:01 I know there are scripts to handle pcmcia cards that need hciattach at least May 04 13:18:58 right May 04 13:19:10 I guess it isn't all that important to support "turn off bluetooth" on those devices since you can just pull them out. May 04 13:19:29 iirc, that's the approach we took with gpe-bluetooth as well, the software control only worked for internal bluetooth May 04 13:20:07 ok May 04 13:20:41 I would like to support turning on/off bluetooth without removing the device, but that's really a bonus feature I guess May 04 13:21:38 thanks for the pointers though everyone, very helpful :) May 04 13:30:10 interesting, on my laptop there are two bluetooth rfkill devices, one for the switch which also affects the hardware, and one for hci0 May 04 13:30:40 they both work but the switch is the nicest as the LED also goes out May 04 13:31:02 unfortunately I can't see an easy link between the two that I could detect in code May 04 13:36:57 maybe just look for the first bluetooth one marked "persistent" first, or if none could be found then the first non-persistent one May 04 14:45:45 could i suppress all "NOTE: package " message and only get the "NOTE: Running task X of XX" May 04 14:50:45 currently, you'd have to modify bitbake/lib/bb/ui/knotty.py. it emits those in response to events the server sends May 04 14:51:12 we're looking to make it easier to plug into the bitbake logging so you can customize what goes where May 04 14:53:30 kergoth: you get your machine back functioning? I just upgraded my laptop from 10.04 -> 11.04 with no problems (though I hate the new "unity" desktop so far) May 04 14:53:58 yeah, every time i tried to install 11.04, even from scratch, resulted in the same behavior. went back to 10.10, worked fine May 04 14:54:00 strange. May 04 14:54:30 yea, odd. May 04 14:55:42 i love vmware, though. this box is dual boot, i can sit in windows happily and reinstall linux on the linux partitions on the same hard drives windows is on with vmware and then reboot into it if i need to May 04 14:55:44 :) May 04 14:59:05 heyho May 04 14:59:16 anybody here knows about using the rpath in OE? May 04 14:59:27 you'll need to elaborate on that May 04 14:59:34 as I don't find any place where it is striped out of the binaries May 04 15:00:03 kergoth: ok, I have a recipe for generatorruner-native May 04 15:00:06 it uses cmake May 04 15:00:11 it builds fine May 04 15:01:00 then I have another recipe for the target which uses generatorrunner-native to build May 04 15:01:07 typical, yes May 04 15:01:16 the build fails as the generatorrunner does not find it's runtime library May 04 15:01:48 and cmake does not set a rpath in it's default configuration May 04 15:02:37 I'd say either fix it to do so, or generate a wrapper script to work around it May 04 15:02:44 ok May 04 15:02:58 current I do the following within the generatorrunner-native recipe: May 04 15:02:59 echo "set( CMAKE_INSTALL_RPATH ${STAGING_DIR}${libdir} )" >> ${WORKDIR}/toolchain.cmake May 04 15:03:28 quick question re -dbg packages May 04 15:03:36 seems reasonable. would be better to use $ORIGIN, but that'll work May 04 15:03:52 and I am asking me if it's useful to add it to cmake.bbclass May 04 15:04:04 let's say i want to debug a shared library.... May 04 15:04:22 I install a dbg package, and copy over the .debug/lib.so to ./lib.so ? May 04 15:04:28 no postinst script that handles that? May 04 15:05:27 ah. well, the thing is, you'd probably want ${libdir}, not ${STAGING_DIR}${libdir}, otherwise you'll end up with staging bits in your target packages. and native sets libdir to point at staging already, so in natives the above will end up with staging duplicated May 04 15:05:30 unless cmake is handled specially May 04 15:05:34 jconnolly: uh, NO May 04 15:05:39 jconnolly: the .debug file isn't the library May 04 15:05:43 it's *only* the debug symbols May 04 15:05:47 ah May 04 15:05:47 which gdb knows to use as is May 04 15:05:54 install and go May 04 15:05:58 sweet May 04 15:06:01 :) May 04 15:07:45 when doing a fresh build, x264 do_configure is running before the cross compiler is built and it pukes b/c it wants to test the compiler. x264 seems to have no dependencies listed - should it depend on virtual/libc or something to prevent this? May 04 15:08:20 foerster: base.bbclass adds the libc, etc deps May 04 15:08:26 unless it sets INHIBIT_DEFAULT_DEPS May 04 15:08:45 hmm... Doesn't seem to be happening for some reason May 04 15:08:47 first, bitbake -e x264|grep DEPENDS=, see what's really going on May 04 15:08:57 ah, i see May 04 15:09:16 DEPENDS_x86 = "yasm-native" May 04 15:09:17 kergoth: but if I only set ${libdir} as rpath the sysroot path will prefixed during the build? May 04 15:09:24 that's clearing the other DEPENDS May 04 15:09:27 ah, so the override is likely blowing away what base.bbclass is doing May 04 15:09:29 due to evaluation order May 04 15:09:41 does DEPENDS also = yasm-native? May 04 15:09:46 no May 04 15:09:51 just x86 May 04 15:09:58 what's DEPENDS? May 04 15:10:01 nothing May 04 15:10:08 well, nothing in the bb May 04 15:10:16 can't check -e right now, build running May 04 15:10:18 morphis: as i said, for native/nativesdk, libdir points at the sysroot already. May 04 15:10:26 morphis: go ahead and look. bitbake -e foo-native|grep libdir= May 04 15:10:28 I made it DEPENDS_append_x86 here and started it again. May 04 15:10:37 cool May 04 15:10:44 kergoth: ok, thanks May 04 15:11:02 kergoth: is that the more proper method: DEPENDS_append_x86 ? May 04 15:11:10 foerster: depends on what you're trying to do. May 04 15:11:20 _override blows away the original variable contents by design.. May 04 15:11:27 so as usual it depends on the intent May 04 15:12:22 it looks they're trying to use inline assembly on x86 arch since it's available, so they want yasm May 04 15:12:49 I don't even know what's causing this to be built at the moment, but it was boning me so I had to figure out why May 04 15:13:23 kergoth: only ${libdir} works too, ok May 04 15:13:34 foerster: append sounds like what they really wanted, then :) May 04 15:14:06 kergoth: ok, I'll send a patch to fix it at some point May 04 15:18:22 kergoth: do you think the line "echo "set( CMAKE_INSTALL_RPATH ${STAGING_DIR}${libdir} )" >> ${WORKDIR}/toolchain.cmake" should go into cmake.bbclass as I don't have the overview to decide that May 04 15:19:27 with ${STAGING_DIR} removed, perhaps. I'd strongly suggest checking the sanity of the rpaths in the binaries generated by at least native, cross, and target packages first May 04 15:19:33 also, that line is problematic May 04 15:19:44 erm, no, i guess not May 04 15:19:47 nevermind May 04 15:20:25 * foerster is again pondering migrating to oe-core, though my previous attempt didn't go so well May 04 15:20:58 i do most of my day to day work there, though I then have to migrate what i do into both oe and my work trees May 04 15:20:59 heh May 04 15:22:30 i'm trying to ready a platform for release - I don't want to set up all my local infrastructure with oe.dev if it's going to be left for dead soon May 04 15:22:45 kergoth: yes, the STAGING_DIR should be removed, I just copied the line from above May 04 15:24:38 kergoth: "generatorrunner: RPATH=$ORIGIN/../lib:$ORIGIN/../lib" May 04 15:24:44 looks fine for me May 04 15:24:54 i doubt it'll be entirely dead anytime soon, if ever. it'll be a *long* time before everything gets migrated. it'll likely always exist as a recipe store May 04 15:24:55 heh May 04 15:25:15 but yes, that's certainly a concern May 04 15:25:23 i wonder when more companies will move to it May 04 15:25:33 kergoth: when there are some instructions ;) May 04 15:25:47 hehe May 04 15:26:32 my last attempt of oe-core + meta-oe wouldn't even parse, bitbake puked out trying to parse. May 04 15:26:35 that was a month ago May 04 15:27:05 https://github.com/kergoth/reloc-tests is an example build directory with just oe-core, using submodules, including the setup.sh. git clone --recursive the repo, . ./setup.sh, bitbake foo May 04 15:27:25 course that's not using the standard env bits from the oe-core scripts, i like to do my own thing May 04 15:28:35 My problem was probably that I didn't use the env-init script, and I didnt' set anything different than with oe.dev May 04 15:28:48 yep, that'd do it, in multiple ways May 04 15:29:11 Is there a way to set up an SDK build to produce 32-bit output rather than 64-bit from a 64-bit environment? May 04 15:29:19 first, you should really be using bblayers rather than BBPATH/BBFILES directly. second, you need to run the bitbake wrapper script in oe-core/scripts, not bitbake directly May 04 15:29:37 https://github.com/kergoth/reloc-tests/blob/master/setup.sh May 04 15:29:47 also need export BBFETCH2=1 in there May 04 15:29:49 * kergoth clones to fix May 04 15:29:58 kergoth: good to know. I ran bitbake directly, that probably killed me May 04 15:30:07 it will. nowadays it will error about it May 04 15:30:11 warn you if your un without it May 04 15:30:24 the thing is May 04 15:30:28 yes, it warned, but i said "meh, what do you know..." May 04 15:30:29 :) May 04 15:30:30 with oe-core, the *entire* builds runs underneither pseudo May 04 15:30:36 but it doesn't get enabled until the task fork May 04 15:30:44 this means even python tasks run under a fakeroot-like context May 04 15:30:55 and it means perms, etc survive between do_install and packaging May 04 15:32:18 correct.. pseudo is preloaded -- but not actively intercepting calls until it's enabled via an environment variable on a fork (or exec) call May 04 15:32:28 * kergoth nods May 04 15:33:21 this is the first step at fixing some significant bugs on user/group ownership.. hopefully we'll be able to fix the additional ones in the next few months.. May 04 15:33:40 (plus pseudo is starting to have things like MacOS X support.. so we can move beyond Linux hosts) May 04 15:34:22 hm.. looks like perl-native fix for ubuntu 11.04 needs imported from oe-core to oe.dev. May 04 16:05:58 hmm the new opie image has a big issue on om-gta02: May 04 16:06:03 PTY allocation request failed on channel 0 May 04 16:06:08 bluelightning, ^^^ May 04 16:06:34 result: cannot ssh in it and cannot run the internal console May 04 16:06:38 GNUtoo: hmm so this was not an issue with 1.2.4? May 04 16:06:43 no May 04 16:06:48 I remember ssh-ing into it May 04 16:06:56 what could Opie be doing to cause that...? May 04 16:06:59 and running the console May 04 16:07:01 no idea May 04 16:07:04 maybe it's not opie May 04 16:07:10 maybe it's the kernel defconfig May 04 16:09:27 well, I'm guessing it's not an opie issue, but I'm happy to be proven wrong May 04 16:09:57 the serial console is very hard to use on that device May 04 16:10:03 since mine is half-broken May 04 16:10:45 you need the funky add-on board for that right? May 04 16:11:32 GNUtoo: similar error is shown without /dev or /proc mounted May 04 16:11:42 ok May 04 16:12:28 /dev and /proc seem there May 04 16:15:15 is /dev/pts mounted? May 04 16:15:54 I'll look May 04 16:16:50 good catch May 04 16:16:53 it's not mounted May 04 16:16:56 and /dev/ is strange May 04 16:17:30 *dev is mounted but /dev/pts is empty May 04 16:26:24 devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620) May 04 16:26:36 but /dev/pts is empty May 04 16:27:10 sorry for typing slowly but I've to hold the half-broken cable May 04 16:35:22 umount /dev/pts/ May 04 16:35:23 umount: /dev/pts: not mounted May 04 16:37:26 Linux om-gta02 2.6.34.8 #1 Fri Apr 1 22:14:22 CEST 2011 armv4tl GNU/Linux May 04 16:37:29 strange May 04 16:57:32 blindvt, maybe nfs-utils-1.2.3 and drop the rest May 04 17:41:47 ka6sox-work: garnet should be 64bit May 04 17:41:53 gm all May 04 17:46:03 it's a PITA that the libc-kernel-headers are always out of sync WRT the kernel. Why did we need the separate thing again for any versions that do not need manual sanitization -- i.e. all somewhat recent? May 04 17:47:01 blindvt`: well they are and they are not May 04 17:47:07 its how you look at it May 04 17:47:16 (except for fux0ring up our view on what syscalls are available, for example ;) May 04 17:47:17 if you have multiple sub families you love it May 04 17:48:12 but if its just one machine you care about then it evens out May 04 17:48:51 well i care about qemu* machines May 04 17:50:10 khem: still, it's a pita that the normal kernel recipe does not automagically provide the corresponding headers. I'm not arguing about having a choice to use a different version for the headers but that i have to always have 2 recipes :/ May 04 17:50:39 its the need in the build order May 04 17:51:03 glibc/uclibc needs to know about them as you know May 04 17:51:10 .. as they tend to go out of sync like we have ATM WRT .38 (or at least my checkout) May 04 17:51:53 I many times thought of deriving the kernel header recipes from kernel recipes and even put them along side kernel May 04 17:52:03 but then dropped the idea May 04 17:52:39 i know that libc needs them, but unpacking the tarball is not a problem and so is installing and packaging the darn headers May 04 17:53:40 but anyway. I'll stop that rant for now. ;) May 04 17:59:50 blindvt`: on a different note we should cut 0.9.32 now May 04 17:59:55 mips issues are resolved May 04 18:00:04 I dont think there is much pending May 04 18:00:19 moving forward them I can do a nptl sync May 04 18:00:26 and merge prelink branch May 04 18:03:06 khem: well yea, I'm currently (resp will in the evening) hunting an odd miscompilation in the old vfprintf in _fp_out_narrow for O>0 May 04 18:07:20 khem: can you double-check and runtime check that the qemu arches work ok for current master (with 4.6.x and 2.21)? That'd be awesome.. May 04 18:30:20 blindvt`: I already use 4.6.x and 2.21 May 04 18:30:24 and it wrks May 04 18:35:52 khem: i've created a personal branch to push eventual fixes to, fwiw May 04 18:40:39 Did someone mess with S30pvr-init lalely? May 04 18:40:48 /etc/rc5.d/S30pvr-init: line 33: function: not found May 04 18:40:53 and a few other errors May 04 19:00:17 morning May 04 20:28:26 bummer. Seems too many pieces are missing from oe-core + meta-oe to make migration possible for me at this time. May 04 20:30:18 then migrate missing pieces :) May 04 20:30:56 Crofton: btw: what happen with that nm patch? May 04 20:31:14 urg May 04 20:31:19 I need to commit May 04 20:31:40 do you need it in a hurry? May 04 20:32:47 JaMa|Off: no time at this point. Product must ship at the end of the month, so little time for messing around :( May 04 20:33:06 I got caught up in oe admin work, real work and some other stuff and forgot all about it May 04 20:37:03 Crofton: not at all, just curious May 04 20:37:52 hmm, I fixed the patch May 04 20:37:58 will test against git May 04 20:38:12 need to check agasint the other version to make sure it applies May 04 20:45:40 bother, combined patch does not work May 04 20:45:46 need to fix May 04 20:46:33 I hung a sticky note at my desk May 04 20:47:38 er, unless i'm missing something, inheriting distutils doesn't result in a dep on python-native for native recipes. this seems liek it'd be problematic for the same reason we had issues with perl-native May 04 20:47:53 either it needs to always be used, or never be, otherwise it just shows up and hoses things May 04 20:56:03 god, the depends vs bbclassextend handling is such voodoo May 04 21:01:34 khem: in case you missed it http://blog.flameeyes.eu/2011/05/03/surviving-without-libtool-archives May 04 21:03:54 kergoth: yes and broken for long :/ May 04 21:04:00 ant__: heh, we could use an _MASK equivalent May 04 21:04:42 Diego declared war long ago, deploying 'lafilefixer' tool May 04 21:04:52 noiw sounds more radical May 04 21:05:31 kergoth: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/39211 May 04 21:05:33 03Simon Busch  07master * r33ca9bebac 10openembedded.git/ (3 files in 2 dirs): May 04 21:05:33 palmpre: remove unused components May 04 21:05:33 * tellbootie: does not work and isn't required for working reboot/shutdown anymore May 04 21:05:33 * palmpre-system-deps-native: the required dependencies are now part of the relevant May 04 21:05:33 components May 04 21:05:33 Signed-off-by: Simon Busch May 04 21:05:39 03Simon Busch  07master * rd03f0be719 10openembedded.git/recipes/connman/connman_0.73.bb: May 04 21:05:39 connman: add recipe for the latest released version 0.73 May 04 21:05:39 Signed-off-by: Simon Busch May 04 21:06:16 khem: second comment is very promising...and then an env file for the following packages to allow .la files for them:.. May 04 21:06:18 JaMa|Off: guh. there has to be a better way to get this done May 04 21:07:58 kergoth: yes, I hope so.. RP found the same issue last month.. so maybe he is working on something already May 04 21:09:10 anyone had an issue with using the bzr fetcher where it fails to grab a new revision if an old one already exists in the downloads dir? May 04 21:09:24 or rather, anyone know a solution to that problem May 04 21:10:50 * kergoth ponders May 04 21:11:12 bzr: ERROR: No pull location known or specified. May 04 21:11:37 if I nuke the downloads/bzr/ area, it will work May 04 21:12:03 but then if I go to fetch a newer rev at some later point, it gives that error May 04 21:12:53 odd May 04 21:13:14 how many recipes using bzr fetcher? May 04 21:13:22 iirc was a recent addition May 04 21:14:20 I don't know, but we just transitioned our internal repos from svn to bzr May 04 21:14:24 hbeck: pls give us the concrete case May 04 21:14:32 ah May 04 21:15:23 in this case: SRC_URI = "bzr://linserv:8091/softplc;proto=http \ May 04 21:15:34 using AUTOREV, since it is internal stuff May 04 21:21:21 well, it looks like there is only one recipe using bazaar fetcher: May 04 21:21:23 ./recipes/openmoko-3rdparty/babiloo-efl_bzr.bb:PV = "2.0.9-bzrr${SRCPV}" May 04 21:21:23 ./recipes/openmoko-3rdparty/babiloo-efl_bzr.bb:SRC_URI = "bzr://bazaar.launchpad.net/~vaudano/babiloo/efl" May 04 21:22:18 other than this, seems only used by -mirrors.bblclass May 04 21:22:48 so is very probable nobody even noticed issues wrt bzr :) May 04 21:23:21 me for one May 04 21:23:23 heh May 04 21:24:08 I wonder if it's an issue of trying to pull into a location that is already a repo May 04 21:24:41 in which case pull --overwrite would work, per bzr help (I think) May 04 21:25:56 where is the bzr fetcher implemented? May 04 21:26:26 ./conf/bitbake.conf May 04 21:27:12 bitbake/lib/bb/fetch/bzr.py most likely May 04 21:27:23 bitbake.conf only contains the base commands the fetchers run May 04 21:27:33 I hope is smthg obvious :) May 04 21:31:55 ~seen blindvt May 04 21:31:58 blindvt is currently on #oe (7d 1h 4m 14s) #uclibc (7d 1h 4m 14s). Has said a total of 1 messages. Is idling for 5d 7h 49m 18s, last said: 'woglinde, -ENOPATCH for libgcc_eh libubacktrace'. May 04 21:32:22 Anyone with an idea where to put a webkit-gtk recipe in meta-oe/oe-core? There is a version in oe-core/meta/recipes-sato, but it's unstable 1.3 series which I found was horribly leaky. I may try to bring a 1.2 version from oe.dev over, but not sure where best to put it. May 04 21:32:42 foerster ask on oe-core? May 04 21:33:22 woglinde: you mean on ml? May 04 21:33:27 yes May 04 21:33:48 could. Was just curious if anyone here had thoughts. May 04 21:33:55 i'd think recipes-graphics in meta-oe May 04 21:34:01 but don't really know the current policies May 04 21:34:22 yes if you want to override recipes in oe-core thats the best way May 04 21:34:28 so there is less confusion May 04 21:35:27 what the hell is sato, anyway/ May 04 21:35:38 webkit-gtk 1.3.x leaked memory something horrible when I tried it. It seemed to eat 1GB of memory quickly. I switched to 1.2.x stable and it resolved. May 04 21:35:56 having things like rxvt-unicode in recipes-sato rather than recipes-graphics or something doesn't make any sense to me at all May 04 21:37:01 kergoth: according to poky docs: An important component integrated within Poky is Sato, a GNOME Mobile based user interface environment. May 04 21:37:14 foerster: webkit is a hell of a testcase for linker and compiler May 04 21:37:25 right, but i use rxvt-unicode as my main terminal on my desktop, it's not exactly bound to that May 04 21:37:26 they generate objects sized 250M+ May 04 21:37:34 it just happens to be that's default May 04 21:37:39 and linker is linking 100s of them May 04 21:37:43 khem: wow May 04 21:37:47 jupp May 04 21:37:49 wow May 04 21:38:04 and interestingly they are emitted into .lib May 04 21:38:17 and rm_work does not delete dir with . May 04 21:38:21 you need 7 gig or so for building May 04 21:38:32 so you end up with a objdir of like 20G more May 04 21:38:42 uhm May 04 21:38:43 hm May 04 21:38:46 i'm using webkit-gtk as my gui interface. 1.3 series seemed to leak miserably with ajax calls May 04 21:38:47 woglinde: gcc 4.5 ? May 04 21:38:55 should be even bigger due to debugging stuff May 04 21:38:59 khem I am trying to stay way May 04 21:39:15 khem but we need some updated chromium support May 04 21:39:18 woglinde: not that its bad its good stuff though May 04 21:39:25 rm_work should really remove all of WORKDIR but ${T} excluded explicitly May 04 21:39:27 woglinde: I hate UIs May 04 21:39:30 i guess May 04 21:39:31 hrm May 04 21:39:42 * kergoth mutters May 04 21:39:46 khem I know my friend is commiter and reviewer for webkit May 04 21:39:47 I like to use them but I dont like to look at how they are coded it blows my mind May 04 21:40:16 woglinde: :) ask him to rewrite it May 04 21:40:36 and teach c++ to webkit devs May 04 21:40:53 lol May 04 21:41:07 kergoth: whats ${T} May 04 21:41:14 is it that bad May 04 21:41:18 /temp/ May 04 21:41:19 didnt looked at the code yet May 04 21:41:30 woglinde: its not bad per say May 04 21:41:30 good evening May 04 21:41:37 but its structured bad May 04 21:41:47 you know, it could be nice to just move ${T} out of workdir May 04 21:41:48 kgilmer dont you just awake? May 04 21:41:56 kergoth: hmmm May 04 21:42:04 ${TMPDIR}/someappropriatename/${PF}/ May 04 21:42:04 instead May 04 21:42:11 would make it a lot easier to get to logs May 04 21:42:12 khem any chance this patch goes to the rc32 release? http://git.uclibc.org/uClibc/commit/?h=future&id=00c44b9f566f34d1fa3f2889771730b8496b6f95 May 04 21:42:13 heh May 04 21:42:23 yep woglinde May 04 21:42:27 kergoth: I did not get it are you taking about the objdirs inside the workdir May 04 21:42:32 which all are under tmpdir May 04 21:42:36 no, i'm talking about ${WORKDIR}/temp/ May 04 21:42:49 which is the only part of workdir that can't be removed by rm_work, for debugging reasons May 04 21:43:25 khem, i am also bitten by this: http://lists.berlios.de/pipermail/bitbake-dev/2011-March/000868.html May 04 21:43:33 woglinde: peter's commits needs testing May 04 21:43:36 and a lot of it May 04 21:43:40 python newbie question: is there a way I can execute bitbake so that it will show me what it is doing, or passing to the functions? specifically I want to see whether this bzr fetcher is doing a fetch or update May 04 21:44:00 khem without this patch you wont be able to compile systemd May 04 21:44:00 hbeck: http://docs.python.org/library/trace.html May 04 21:44:03 kgilmer_: that problem has always eluded me May 04 21:44:10 kergoth: thanks May 04 21:44:16 woglinde: I am ok if it does not go in May 04 21:44:17 khem btw. carmelo commited my patch May 04 21:44:21 alternatively, you could just add prints to the code ;) May 04 21:44:29 woglinde: yes that patch was fine May 04 21:44:38 i tried setting PREFERRED_PROVIDER_virtual/psplash to my local.conf, but it has no effect. May 04 21:44:48 woglinde: mentioned to carmelo offline May 04 21:45:00 khem for oe I splitted the lib into is own package May 04 21:45:52 woglinde: did u commit the patch ? May 04 21:46:04 oh May 04 21:46:06 the only solution i've found that works is to delete all psplash-*.bb except for psplash_svn May 04 21:46:06 woglinde: actually they could go into -dev May 04 21:46:10 khem not yet May 04 21:46:22 args I now the see the epoll commit has not arm part May 04 21:46:24 woglinde: I would be interested to have a look at it May 04 21:46:45 woglinde: and see the commit message its totally misleading May 04 21:47:14 khem no firefox is depending on it May 04 21:47:39 I dont want to have -dev pulled in for it May 04 21:47:54 oh you are mentioning about .so ? May 04 21:48:02 thats fine May 04 21:48:26 kergoth: is there a way to feed the command line style invocation of trace to a call to bitbake, or would I have to make changes in the .py file either way? May 04 21:50:04 ? May 04 21:50:08 it tells you exactly what to do May 04 21:50:16 python -m trace May 04 21:50:23 python -m trace $(which bitbake) May 04 21:50:24 ta da May 04 21:51:08 okay have to go May 04 21:51:10 good nite May 04 21:51:17 night May 04 21:51:31 maybee tomorrow I will find the time to test the epoll stuff May 04 21:51:42 hm hm May 04 21:51:50 I can test it at work maybee May 04 21:51:54 compile at least May 04 21:54:43 kergoth: err, no, I mean like run "bitbake myrecipe" and get python trace out of that, which obviously goes into multiple .py files May 04 21:54:52 yes.. May 04 21:55:12 python -m trace $(which bitbake) myrecipe May 04 21:55:15 not seeing the problem May 04 21:55:21 bitbake is one python script, which imports other python modules May 04 21:55:24 it's not magic May 04 21:55:32 * L-Strife89 is attempting to get Angstrom fully working on his hx4700 May 04 21:55:41 trace accepts a single python script, which is what the bitbake command is May 04 21:55:49 now, i don't know how trace will handle the forking May 04 21:56:11 so i could see a need for it if you need tracing inside of tasks, didn't think about that part May 04 21:58:09 where by 'it' i mean inserting calls to trace in the code May 04 22:02:31 right. hm, doesn't seem to be recognizing my environment setup. in bitbake, try: import bb fails saying no module May 04 22:04:03 hmm, that's odd. bitbake manipulates sys.path, it's strange that that manipulation would be lost when running under trace May 04 22:04:12 you can always explicitly add bitbake/lib to your PYTHONPATH May 04 22:04:19 PYTHONPATH=/path/to/bitbake/lib python -m trace.... May 04 22:04:28 that should get you past that particular error May 04 22:05:29 in bzr.py: logger.debug(1, "BZR Update %s", loc) - can I turn this on with -D fed to bitbake? May 04 22:06:02 yep May 04 22:06:10 but, -D also turns on a *ton* more May 04 22:06:14 right May 04 22:06:30 you might try bitbake -l Fetch instead May 04 22:06:38 that bumps the debug level just in the fetchers May 04 22:06:45 (thats lowercase L) May 04 22:06:51 (logging domain) May 04 22:07:13 huh, cool. May 04 22:08:33 Fetch instead of fetch? May 04 22:09:09 yep May 04 22:09:21 grep logger\ = bitbake/lib/bb/fetch/__init__.py May 04 22:12:27 -l Fetch didn't seem to do it. No additional output May 04 22:12:52 hmm, odd May 04 22:13:45 -D got it May 04 22:20:27 what is fetch2 vs fetch under bitbake/lib/bb/ ? May 04 22:31:48 hbeck: fetch2 is a fetcher rewrite May 04 22:31:55 you can use either May 04 22:33:54 if you set export BBFETCH2=True in yout env the fetch2 will be used May 04 22:43:36 Looks like quite some bits do not fetch any more since the debian release May 04 22:43:42 * florian fixes fakeroot May 04 22:54:52 hi! i'm just getting started looking at getting an openembedded build going for an iMX28 target, and noticed that there just happened to be a couple patches submitted to the mailing list adding support for this target. I was wondering what the process/timeline typically might be for seeing those merged into git May 04 22:58:45 liamMT: you can merge them in your local tree if desides May 04 23:00:20 liamMT: by now they are stale so if you refresh them and resubmit May 04 23:00:24 that would be the way to go May 04 23:16:14 I just fetched QT 4.7.2 and it has a different md5sum. Something seems wrong. I tested it twice so it seems to not be a download error but a tarball change. Can someone confirm it? May 04 23:17:32 otavio, khem: thanks, I think I'll give it a shot. I was also curious to understand what process those patches might go through before being accepted - any additional verification, etc? May 04 23:18:01 liamMT: you're welcome. May 04 23:18:20 People, I am leaving... if someone finds out what happened with qt tarball let me know :-D May 04 23:18:24 cheers May 04 23:29:39 think I found the issue in the bzr fetcher, basically 'pull' requires a location to be specified and it doesn't have one. There was a patch submitted back in 2009: http://lists.berlios.de/pipermail/bitbake-dev/2009-November/000472.html ... doesn't seem to have ever been accepted/applied May 04 23:30:10 hbeck: remind kergoth May 04 23:30:27 alternatively, could just replace 'pull' with 'update' which I think is more appropriate May 04 23:41:14 * kergoth knows nothing about bzr May 05 00:01:17 03Philip Balister  07org.openembedded.dev * r73593c5b1c 10openembedded.git/recipes/networkmanager/ (3 files in 2 dirs): May 05 00:01:17 networkmanager_git: fix build with static libnl1 May 05 00:01:17 * Fix flags for dns-manager also May 05 00:01:17 Signed-off-by: Philip Balister May 05 00:13:07 kergoth: ok, so that patch I found is actually a very, very bad solution! May 05 00:35:26 kergoth: heh, or maybe not. confusing terminology first getting into this bzr stuff. May 05 01:24:54 I'm running oe for angstrom-2010.x from git master on ubuntu 11.04 and getting an error during recipe parsing, suggested fix is to install 'makeinfo', though no package of that name seems to exist via apt-get. any hints? May 05 01:28:58 http://stackoverflow.com/questions/338317/what-is-makeinfo-and-how-do-i-get-it May 05 01:31:32 doh - thanks **** ENDING LOGGING AT Thu May 05 02:59:57 2011