**** BEGIN LOGGING AT Wed May 27 02:59:57 2009 May 27 05:28:59 Hello! May 27 05:29:27 Have anyone got experience linux development with blackfin processor ? May 27 06:41:26 good morning May 27 06:47:06 Good morning May 27 08:12:52 morning May 27 08:22:31 hi hrw May 27 08:25:31 <|AbsyntH|> goodmorning May 27 08:47:17 03Daniel Willmann  07shr/import * r7f19da7749 10openembedded.git/conf/checksums.ini: conf/checksums.ini: Add mofi.0.02.tar.gz May 27 08:47:28 03Daniel Willmann  07shr/import * rae9fe62136 10openembedded.git/conf/checksums.ini: checksums.ini: Add vala-0.7.3-fso1 May 27 09:03:47 good morning May 27 09:03:51 hi pvanhoof May 27 09:03:58 hey florian May 27 09:04:36 Aloha! May 27 09:07:30 hi sbaturzioAtWork May 27 09:07:51 florian: Ciao! May 27 09:14:13 03Julien 'Ainulindale' Cassignol  07shr/import * r631f073e75 10openembedded.git/recipes/images/shr-image.inc: May 27 09:14:13 shr-image.inc: Changed IMAGE_LINGUAS = to IMAGE_LINGUAS ?= in order to allow user configurable LINGUAS for image May 27 09:14:13 generation through configuration files. May 27 09:44:07 florian: good morning May 27 09:44:19 hey pb_ May 27 09:49:41 03Didier 'Ptitjes  07shr/import * r2c31a82dd7 10openembedded.git/ (4 files in 3 dirs): May 27 09:49:41 Use libgee from git (to get the Vala 0.7 build fix) May 27 09:49:41 Signed-off-by: Didier 'Ptitjes May 27 09:51:44 03Julien 'Ainulindale' Cassignol  07shr/import * rd0a9bc0e71 10openembedded.git/recipes/libgee/libgee_git.bb: libgee_git: Removed useless PR. May 27 09:54:59 what do I need to create sdk packages successfully? I try to create qt4-tools-sdk package for including into toolchain to create workable qmake/gnu environment. For this, I require qt4-tools-native_${PV}.bb and inherit sdk. What else should I do? For now, no qt4-tools-sdk contents are included into the resulted toolchain tarball. May 27 09:56:27 fscking x11 May 27 09:56:45 my keyboard stopped working in x11 again (works on console perfectly) May 27 09:56:51 :s/s/u/g :) May 27 09:58:59 ;d May 27 10:01:04 03Klaus 'mrmoku' Kurzmann  07shr/import * r0f85137e22 10openembedded.git/recipes/xchat/ (2 files in 2 dirs): (log message trimmed) May 27 10:01:04 resend xchat May 27 10:01:04 as Ainulindale did not yet apply it... resending it inline which is much nicer :) May 27 10:01:04 Klaus 'mrmoku' Kurzmann May 27 10:01:04 -- May 27 10:01:05 From 38eb2e60a4088d3409b4762a86d1d1fad5effc90 Mon Sep 17 00:00:00 2001 May 27 10:01:07 From: Klaus Kurzmann May 27 10:01:40 Damn dumb commit message. May 27 10:01:56 +1 :-\ May 27 10:13:21 * rkirti chuckles May 27 10:13:43 seen gremlin[it] May 27 10:13:59 ~seen gremlin[it] May 27 10:14:02 gremlin[it] was last seen on IRC in channel #oe, 1d 15h 38m 22s ago, saying: 'ping mckoan|away '. May 27 10:18:04 what are ladybird icons in tinderbox? May 27 10:29:25 where is ${D} specified? May 27 10:30:57 my qt4tools-native-sdk requires qt4-tools-native_${PV}.bb (which inherits native) and then inherits sdk, and then my ${D} is /usr/local/angstrom/x86_64, though I need /usr/local/angstrom/arm May 27 10:31:35 qt4tools-native-sdk? May 27 10:31:40 not qt4tools-sdk? May 27 10:32:46 ow, sdk of course May 27 10:33:04 there is no such package currently, I'm trying to implement it now May 27 10:47:56 where can I find setting of internal bb vars? :-\ May 27 10:48:14 grepping for "D" is not the easiest thing to do :( May 27 10:48:47 what do you mean by "internal"? May 27 10:48:53 ${D} is set in bitbake.conf unless you override it somewhere else. May 27 10:48:54 ow, I found... bitbake.conf May 27 10:49:28 fwiw, grep -r '^D =' would probably be a fairly painless way to find these things. May 27 10:56:23 please clarify if all the toolchain files should be placed into single directory found in /usr/local/angstrom/ ? May 27 10:56:43 or should x86_64 bits be placed into x86_64, and arm into arm? May 27 10:58:08 booxter: it usually is /usr/local/angstrom/TARGET_ARCH/ May 27 11:00:16 ok. my qt4-tools-sdk package is fetched through TOOLCHAIN_HOST_TASK -> RDEPENDS. Is it the right way of doing the thing? My qmake/moc/uic... stuff should be placed into arm toolchain but to be an x86_64 binaries. Any suggestions? May 27 11:00:28 03Koen Kooi  07org.openembedded.dev * re46ff459fa 10openembedded.git/recipes/xorg-driver/xf86-video-omapfb_git.bb: xf86-video-omapfb: bump SRCREV and use overlay 2 instead of overlay 1 May 27 11:53:36 03Julien 'Ainulindale' Cassignol  07shr/import * r42201eeabb 10openembedded.git/recipes/libsdl/libsdl-mixer_1.2.6.bb: libsdl-mixer_1.2.6: Build fix (added configure_prepend). May 27 12:05:47 Would someone be able to tell me what would be the best practices to override EXTRA_OECONF according to an override defined in my distro.conf? May 27 12:06:03 Should I put it in the package file? In an autorev file? May 27 12:10:30 03Julien 'Ainulindale' Cassignol  07shr/import * r2a741fbda4 10openembedded.git/conf/distro/shr.conf: May 27 12:10:30 shr.conf: Added shr to the OVERRIDES. May 27 12:10:30 Targeted qemu for arm using EXTRA_OECONF. May 27 12:11:13 Ainulindale: you know that DISTRO is in OVERRIDES? May 27 12:11:37 FUCK May 27 12:11:48 ! May 27 12:12:05 hrw: well nah I didn't :-) May 27 12:12:06 I just removed nice set of newer x11 libs recipes May 27 12:12:18 but I didn't see it in mine May 27 12:12:22 Hence my adding May 27 12:12:26 Ainulindale: so for next time use "bitbake -b recipe.bb -e|grep ^OVERRIDES" May 27 12:14:03 I recently updated OE using git pull. The main difference that I saw was a new udev but there were probably others. Anyway, I try to mount the new root filesystem using NFS and all I see is eth0: link down when init starts which obviously kills my NFS mount. Sometimes I also see udev start before I see eth0: link down. How can I figure out which init script is messing up eth0? I'm using angstrom on at91sam9g20 and console-image build. May 27 12:17:02 03Marcin Juszkiewicz  07org.openembedded.dev * r1b8cae12f8 10openembedded.git/recipes/xorg-lib/ (xtrans-native_1.2.3.bb xtrans-sdk_1.2.3.bb xtrans_1.2.3.bb): xtrans: added 1.2.3 May 27 12:17:02 03Marcin Juszkiewicz  07org.openembedded.dev * r03161d38e2 10openembedded.git/recipes/xorg-proto/applewmproto_1.2.0.bb: applewmproto: added 1.2.0 May 27 12:17:04 03Marcin Juszkiewicz  07org.openembedded.dev * rf07fc58075 10openembedded.git/recipes/xorg-proto/dri2proto_2.0.bb: dri2proto: added 2.0 May 27 12:17:04 03Marcin Juszkiewicz  07org.openembedded.dev * r52176d806c 10openembedded.git/conf/checksums.ini: checksums.ini: added some X.org tarballs May 27 12:17:06 03Marcin Juszkiewicz  07org.openembedded.dev * rc3df09da0b 10openembedded.git/recipes/xorg-proto/ (inputproto-native_1.5.0.bb inputproto-sdk_1.5.0.bb): inputproto: added 1.5.0 May 27 12:17:09 03Marcin Juszkiewicz  07org.openembedded.dev * r6b0e4ce328 10openembedded.git/recipes/xorg-proto/randrproto_1.3.0.bb: randrproto: added 1.3.0 May 27 12:17:12 03Marcin Juszkiewicz  07org.openembedded.dev * r5396479c1f 10openembedded.git/recipes/busybox/ (busybox-1.13.2/angstrom/defconfig busybox_1.13.2.bb): busybox: enabled stat in 1.13.2/angstrom May 27 12:17:15 03Marcin Juszkiewicz  07org.openembedded.dev * r463ae17437 10openembedded.git/recipes/xorg-proto/ (3 files): xextproto: added 7.0.5 May 27 12:17:18 03Marcin Juszkiewicz  07org.openembedded.dev * r80fb286dd2 10openembedded.git/recipes/xorg-proto/ (3 files): xproto: added 7.0.15 May 27 12:17:51 heh.. I started SHR on neo1973... awesome waste of space during first boot May 27 12:18:10 hrw: that is? May 27 12:18:14 hrw: I'm interested in that :-) May 27 12:18:20 I didn't have time yet to test it on my GTA01 May 27 12:18:50 Ainulindale: first time requesters should occupy whole screen May 27 12:20:36 first time requesters, you mean the e thing? May 27 12:20:40 hrw: Waste of space by what? May 27 12:20:41 illume language selection & all? May 27 12:20:55 Ainulindale: yes May 27 12:21:14 leonardo_, just a guess May 27 12:21:22 look in /etc/network/interfaces May 27 12:21:30 and comment out the line auto eth0 May 27 12:21:32 hrw: well it's the same on every device sadly May 27 12:23:55 Crofton|work: oh yeah, i totally forgot about that May 27 12:24:09 is that something that needs to be fixed somehow? May 27 12:24:25 I'm not sure May 27 12:24:38 I don't really understand that script May 27 12:24:49 I just now it bites you on nfs root :) May 27 12:26:19 yeah, and I had done that in my previous fs May 27 12:28:09 03Julien 'Ainulindale' Cassignol  07shr/import * rcdf550b244 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): xserver-kdrive-glamo: Fix crash with composite. May 27 12:28:10 03Julien 'Ainulindale' Cassignol  07shr/import * r418c48e8bb 10openembedded.git/: Merge branch 'shr/import' of ssh://git@git.openembedded.net/openembedded into shr/import May 27 12:28:11 03Julien 'Ainulindale' Cassignol  07shr/import * r89624963f0 10openembedded.git/recipes/xserver-kdrive-common/ (3 files in 3 dirs): May 27 12:28:11 xserver-kdrive-common: Do not display black screen if xsplash is enabled. May 27 12:28:13 Duplicated openmoko subdir according to new distro "SHR". May 27 12:39:03 bb in 0,5h\ May 27 13:19:32 03Julien 'Ainulindale' Cassignol  07shr/import * r99b1794a8b 10openembedded.git/recipes/efl1/ecore.inc: ecore.inc: Fixed patch typo in SRC_URI. May 27 13:27:35 what LFLAGS should I use for building qt4-tools-sdk (where binaries should be built for host system not target one)? I have some do_populate_staging problems reported: http://pastebin.com/m604ff32d May 27 13:28:36 I already achieved building host binaries but these staging warnings should be fixed I think? May 27 13:30:21 for qt4-tools-native, I have the following in recipe: LFLAGS="-L${STAGING_LIBDIR_NATIVE}" ./configure ${EXTRA_OECONF}. What should I specify there for sdk part? May 27 13:33:06 the same, probably May 27 13:33:22 perhaps with an extra -rpath or something May 27 13:33:59 what does sdk.bbclass use for ${LDFLAGS}? May 27 13:37:29 Has the git repository changed key? May 27 13:38:01 hello all- May 27 13:38:31 quick question: I need to set an env var prior to running a ./configure in a .bb file May 27 13:38:44 kristoffer: might be possible... it has moved to a different machine May 27 13:38:48 but it uses autotools bbclass May 27 13:39:19 florian, oki, got some warnings about that. May 27 13:39:23 do i have to replicate the entire do_configure function? May 27 13:39:45 kitno: you can provide your own do_configure and run the one from autotools.bbclass in there May 27 13:39:47 or can i set the var and then call autotools_do_configure May 27 13:40:02 yes that shoudl do the trick imo May 27 13:40:07 florian, i'm a real noob here- how do i set the var? May 27 13:40:10 kitno: you can probably just put it in EXTRA_OECONF May 27 13:40:23 or provide a do_configure_prepend, or what florian said May 27 13:40:49 env vars set in an earlier stage survive? May 27 13:41:32 not between tasks, but they do between shell functions within a task May 27 13:41:40 great. May 27 13:41:56 now, stupid question- how to set the var (syntax?) May 27 13:42:05 myvar = "myvalue" May 27 13:42:12 no need to call set? May 27 13:42:47 actually, you can't have the spaces. just myvar="myvalue" May 27 13:42:53 it's basically just a bash script May 27 13:43:05 no, no need to call set May 27 13:43:29 cool. I was not sure what language this was :) May 27 13:43:32 I do suggest that you try EXTRA_OECONF first, though, that's probably an easier solution if it works May 27 13:43:43 just define that in my local.conf? May 27 13:44:57 no in the bb May 27 13:45:29 ahh, at the top, with all the LICENSE and such? May 27 13:45:57 if you like :-) May 27 13:46:29 hmm- my var has spaces and " in it- what is proper escape sequence here? May 27 13:47:00 EXTRA_OECONF = "BACKENDS=\"fujitsu\"" May 27 13:47:46 more accurate: May 27 13:47:59 EXTRA_OECONF = "BACKENDS=\"fujitsu canon_dr\"" May 27 13:48:20 does that seem correct? May 27 13:50:29 hmm- EXTRA_OECONF seems to be arguments to ./configure, not env vars set beforehand. I dont know if configure cares though May 27 13:51:05 kitno: -DBACKENDS would be more right, IIRC May 27 13:51:13 I may be mistaken though May 27 13:52:07 kitno: generally, configure will accept variables in either place. May 27 13:52:12 Ainulindale, i'll try that too :) May 27 13:52:38 there might be some instances where it doesn't work to pass variables in EXTRA_OECONF (i.e. as arguments, not in the environment), but usually it should do. May 27 13:52:50 also yes, what Ainulindale said May 27 13:52:53 pb_, ok, I'll try May 27 13:53:13 Good thing is May 27 13:53:21 bitbake -c unpack -b yourrecipe.bb May 27 13:53:30 then bitbake -c devshell -b yourrecipe.bb May 27 13:53:42 Try to launch the configure as you would do it manually May 27 13:53:47 Then just copy the extra opts May 27 13:54:43 Ainulindale, you just flew way over my head :) May 27 13:55:12 I've not used OE in a couple of years May 27 14:12:23 Aloha! May 27 14:13:12 <|AbsyntH|> hola sbaturzioAtWork May 27 14:13:16 just for curiosity: have someone already tried this kind of hardware? http://www.uniconsys.com/index.php/products-pdks May 27 14:13:30 are there alternatives that could be used with oe? May 27 14:13:37 |AbsyntH|: ciao :) May 27 14:16:11 Hmm- i added a package to DISTRO_EXTRA_RDEPENDS, and it built May 27 14:16:17 but i dont see it in the rootfs May 27 14:17:46 do not use DISTRO_EXTRA_RDEPENDS May 27 14:17:49 03Marcin Juszkiewicz  07org.openembedded.dev * r8b807abe4a 10openembedded.git/recipes/xorg-driver/xf86-input-mouse_1.4.0.bb: xf86-input-mouse: added 1.4.0 May 27 14:17:49 03Marcin Juszkiewicz  07org.openembedded.dev * r82922b867c 10openembedded.git/recipes/xorg-util/ (util-macros-native_1.2.1.bb util-macros_1.2.1.bb): util-macros: added 1.2.1 May 27 14:17:51 03Marcin Juszkiewicz  07org.openembedded.dev * r7b71257e22 10openembedded.git/recipes/xorg-driver/xf86-input-evdev_2.2.2.bb: xf86-input-evdev: added 2.2.2 May 27 14:17:53 I'm replacing a few git admin components on the server with packaged versions -- git may be unavailable for 5-10 minutes May 27 14:18:11 hrw- what should i use? May 27 14:18:12 kitno: http://marcin.juszkiewicz.com.pl/2007/08/23/why-using-of-distromachine-variables-in-localconf-is-wrong/ May 27 14:18:25 03Thomas Zimmermann  07shr/import * rb32d3b7a72 10openembedded.git/ (4 files in 3 dirs): woosh: New recipe. May 27 14:20:05 got it May 27 14:20:50 hrw- should i make a derivative distro then? May 27 14:20:53 03Marcin Juszkiewicz  07org.openembedded.dev * r62190cac2b 10openembedded.git/recipes/xorg-xserver/ (xserver-xorg-1.6.1/drmfix.patch xserver-xorg_1.6.1.bb): xorg-xserver: added 1.6.1 (tested only on armv6/glibc) May 27 14:21:00 kitno: no, you need image own May 27 14:21:48 sorry- come again? May 27 14:22:36 kitno: http://www.pokylinux.org/releases/pinky-3.1/doc/poky-handbook.html#usingpoky-extend-customimage May 27 14:22:41 kitno: user IS NOT ALLOWED to use DISTRO_ and MACHINE_ variables in local.conf file. if you WANT something EXTRA in image then CREATE own image recipe - it is very very very very very very simple May 27 14:22:48 booxter: exactly May 27 14:22:55 kitno: that's the way you should add new packages to your custom image May 27 14:22:57 * hrw wrote that part of manual ;D May 27 14:23:35 hrw: That's a bit annoying for tracking other changes in the underlying image. May 27 14:23:43 hrw: poky manual is very good. pitty that oe doesn't have the same. but good that oe and poky are almost the same :) May 27 14:24:09 booxter: added link May 27 14:24:55 broonie: then just copy the whole image dependency stack to your overlay - and have a nice day: noone will alter your image (and fix your bugs too) May 27 14:25:11 do i have to do anything special to the existing image to make it 'inheritable'? May 27 14:25:16 (I mean, recipes/images/*) May 27 14:25:36 kitno, just require it May 27 14:25:55 inherit is for openembedded/classes/*.bbclass thing May 27 14:25:55 broonie: yeah, agreed, it does seem like a slightly silly (and rather artificial) restriction May 27 14:26:00 cat kitno-image.bb: require console-image.bb\nIMAGE_INSTALL += "awesome-stuff-which-kitno-needs but-do-not know-how-to add-it" May 27 14:27:02 right- i'll try that May 27 14:29:19 if I export PRE_BUILT="/path" from shell, can/how do I refer to it from local.conf ? May 27 14:30:37 aanishn: it should show up as ${PRE_BUILT}, though you might need to adjust BB_ENV_WHITELIST or similiar in order to stop bitbake from stomping on it. May 27 14:44:13 marbert: can you try your git access again? May 27 14:46:27 something weird here- I'm trying to add libcurl to my image. i dont really need curl binary. if i put libcurl in my IMAGE_INSTALL, it builds a curl-sdk package, but does not put anytinhg in rootfs May 27 14:46:58 that is rather weird. it shouldn't be building curl-sdk for you. May 27 14:47:11 it also builds slib-sdk May 27 14:47:15 are you sure 'libcurl' is the right thing to be installing? if you're using debian style name mangling then it's probably libcurl4 or some such May 27 14:47:16 zlib sorry May 27 14:47:35 hmm- i looked in the bb file, and it said libcurl May 27 14:47:38 it shouldn't be building any -sdk packages, unless you've asked for an sdk May 27 14:47:48 those are quite different to the "normal" packages May 27 14:47:53 yeah- i noticed May 27 14:47:55 :) May 27 14:47:59 heh May 27 14:48:23 how do i get naming convention? this is slugos May 27 14:48:52 the easiest thing is probably to look in your tmp/deploy/ipk/* directory and see what the names of the library packages are like May 27 14:49:24 I don't suppose anyone has documented experiences with supporting new LCDs in an OE based product? May 27 14:49:55 jimsheldon: I haven't heard of any such documentation. generally, supporting new LCDs is more of a kernel problem than anything to do with OE. May 27 14:50:03 I'm about to go down that path and would love to read about others experiences May 27 14:50:12 right, true May 27 14:50:44 libc6-dev_2.6.1-r15_armv5teb.ipk May 27 14:50:57 plus, your experience will depend very much on what sort of panel you're trying to add, and how different it is from the ones that your kernel already supports. May 27 14:51:05 kitno: in that case you are using debian type naming May 27 14:51:15 it'd be called glibc-dev otherwise May 27 14:51:28 right- i see libcurl4 May 27 14:51:43 pb_: right, that's what I figured, thanks May 27 14:51:58 weird that libcurl is a valid target in that case. May 27 14:52:21 it is a bit. May 27 14:52:34 I don't know where that's coming from, some crazy bitbake thing presumably. May 27 14:53:23 how can i know what the number will be ahead of time? May 27 14:53:48 you can't, unfortunately. May 27 14:54:04 cbrake: I'll try, just a sec... May 27 14:54:05 usually, you wouldn't want or need to refer directly to a library package though May 27 14:54:20 (since the library isn't much use unless you have an application that uses it) May 27 14:55:09 and, application packages don't get mangled in the same way so there's no problem with calling them in by name May 27 14:55:50 if you genuinely do want to install libcurl as an orphan then, apart from turning off debian name mangling (which will be a bit of a backwards compatibility wrench) there aren't really any good solutions. May 27 14:55:59 right- if i make my application.bb require the libs with the normal name, it will figure it out? May 27 14:56:06 yes May 27 14:56:13 cbrake: it's downloading, thus looks fine... May 27 14:56:30 any libraries that the application needs will "just work", oe will sort that out under the covers. May 27 14:56:57 marbert: great, thanks May 27 14:58:06 pb_, so i just set DEPENDS = "libcurl whateverotherlibs etc" May 27 14:58:27 kitno: I think DEPENDS = "curl" is what you want here May 27 14:58:41 oh, its like -l ? May 27 14:58:54 adds the 'lib'? May 27 14:59:03 cause there is a separate binary called curl May 27 14:59:04 no, but it's the name of the .bb file that matters here May 27 14:59:14 libcurl is built by curl.bb, so it's "curl" that you need to mention in DEPENDS May 27 14:59:23 then will it install the curl binary too? May 27 14:59:26 no May 27 14:59:46 DEPENDS is just a build-time dependency. it'll compile the curl binary, and it'll even build a curl.ipk with the binary in, but it won't get shipped in your image. May 27 15:00:27 then when does it include the libcurl.so? May 27 15:00:42 do i need a run-time dependency? May 27 15:00:47 presumably your application has "-lcurl" somewhere in its makefiles May 27 15:01:18 this will cause the linker to put a DT_NEEDED record in your output binary saying that it requires libcurl.so.4 (you can see this with "readelf -a" if you're interested) May 27 15:01:19 yes. and bb will inspect that, and install the lib as a part of my ipkg too? May 27 15:01:45 morning May 27 15:01:56 oe will detect that DT_NEEDED record, locate the binary package that contains libcurl.so.4 (which would be libcurl4.ipk in this case) and then record that as a packaging dependency for your application. May 27 15:01:57 kergoth, hello! May 27 15:02:24 then, when you ask ipkg to install your application, it in turn will notice this dependency (via the Depends line in the .ipk file) and bring in libcurl4.ipk as well May 27 15:02:43 holy shit comes to mind :) May 27 15:02:56 it all sounds rather complicated when you explain it, but you don't really need to know about any of this stuff to use it. May 27 15:03:18 ok May 27 15:03:21 if you just put DEPENDS = "curl" in your application .bb file, and add your application to IMAGE_INSTALL somehow, everything else should just work by magic. May 27 15:03:33 hey kergoth May 27 15:04:01 cool May 27 15:05:06 hm, how can I "formalize" the hardcoded string May 27 15:05:12 May 27 15:05:26 shit, X paste is a mess May 27 15:06:09 hm, how can I "formalize" the hardcoded string /usr/local/angstrom/arm/arm-angstrom-linux/usr in my recipe to work "not only for that fucking build" :) May 27 15:06:12 ? May 27 15:07:22 the first thing is probably ${SDK_PATH}. But what is this arm-angstrom-linux thing? May 27 15:07:32 ${SDK_PATH}/${TARGET_SYS}/${prefix}? May 27 15:07:43 it's a bit hard to say without knowing where you're actually encountering that string. May 27 15:07:50 pb_, when i rebuild the image a second time it says libcurl4 is unbuildable, so i think i will have to move it to the app.bb May 27 15:08:16 pb_: I think ${prefix} is not a good thing - I think inherit sdk has substituted it with some value May 27 15:08:46 pb_: it's needed for qt4-tools-sdk ./configure -prefix May 27 15:09:05 to make qmake2 know where target libraries are laid in oe toolchain May 27 15:09:15 oh, yeah, probably. might need to use ${layout_prefix} or something in that case, or even better train sdk.bbclass to make the unmolested version available somewhere. May 27 15:09:30 by default, it searches for qt libs in its prefix which is not the needed case May 27 15:09:42 it's a bit unwholesome to use ${layout_foo} in recipes, I think, but there might not be any real option if sdk.bbclass is stomping on ${prefix} May 27 15:10:58 pb_: what is layout_prefix? May 27 15:11:21 layout_prefix is what's used by both staging and target for the layout of the filesystem, i think May 27 15:11:25 Would any of you guys know if there are problems for git am between 1.6.0.* & 1.6.2.*? May 27 15:11:33 I can't git am a patch whereas it seems fine May 27 15:12:00 checked line endings? was the patch mangled? can you apply it with patch --dry-run? May 27 15:12:52 git patch --dry-run? May 27 15:12:54 or just patch? May 27 15:13:03 kergoth: sorry, but I don't get what you said. Can you explain? May 27 15:13:30 booxter: I'm not sure how i can make it any clearer. May 27 15:13:33 kergoth: because in any case as it's formated by git I guess that patch will tell me I'm not good :-) May 27 15:13:33 booxter: read bitbake.conf. May 27 15:14:13 well anyway, dry run complains May 27 15:14:34 * kergoth shrugs, maybe git apply --check --verbose? May 27 15:14:56 Well, I tried that. What's weird is that supposedly the sender used git send-format-patch May 27 15:15:03 so... /usr/local/angstrom/arm/arm-angstrom-linux/usr = ${SDK_PATH}/${TARGET_SYS}/${layout_prefix}, isn't it? May 27 15:15:11 booxter: it seems a bit weird that you're trying to pass that directory as an argument to ./configure. surely it won't exist at the point you're building the package, since you haven't installed the sdk in place yet. May 27 15:15:13 Ainulindale: that is weird indeed :\ May 27 15:15:21 and, indeed, you might never deploy the sdk on the build host May 27 15:15:23 can anyone tell me a solution for building optimized for arm7a and still being able to generate glibc locales? is there something I can add to the glibc recipe to make it generate locales with an unoptimized arm5 executable or so? May 27 15:15:55 pb_: that's a prefix where qmake2 will search for qt libs. It's not a prefix for qmake2 libs May 27 15:16:13 NekoXP, I wonder if that's still true w/ qemu 0.10.x May 27 15:16:43 NekoXP: well, I guess the best solution would be to fix qemu to work with armv7a, and/or provide a little stub library to emulate whatever qemu is missing. May 27 15:16:48 what's the specific instruction that's causing you a problem? May 27 15:16:56 booxter: so it isn't actually used at build time? May 27 15:17:09 pb_: yeap May 27 15:17:13 Tartarus, yes :( May 27 15:17:30 right, fair enough. I would have thought there must be an existing variable for the path you need, but I don't know offhand what it would be. May 27 15:17:34 might need to poke around in sdk.bbclass a bit May 27 15:17:40 I try to create host qmake that searches for target libs - that's it May 27 15:18:15 I built 0.10.5 native and it still seems to fail May 27 15:18:36 kergoth: hmm seems there are spaces in the formatted patch, tabs in the actual file May 27 15:18:42 Which might actually cause the issue I guess May 27 15:18:58 figured it might be something like that, so it got corrupted along the way somehow May 27 15:19:03 those are a pain in the ass May 27 15:19:26 NekoXP: failing that, you could consider just building glibc for armv5, depending on whether you actually need the armv7a bits. or you could just build the locales once and then ship them as golden binaries, or you could make a special, parallel build of glibc that's used only for locale generation. May 27 15:19:28 though if they used send-email, i don't see how itd get screwed up, unless it was your email client, or their mailserver or something :) May 27 15:19:53 could even consider just generating locales with your host tools and hoping for the best. there are some patches floating around on the eglibc list to deal with the most obvious incompatibilities like byte ordering May 27 15:19:58 kergoth: Heh, I know why. May 27 15:20:05 I copied it over using vim and this freaking bastard expanded my tabs. May 27 15:20:06 pb_, that's what I considered.. May 27 15:20:08 I think some folks are using them with reasonably good success though I haven't tried myself May 27 15:20:13 Hence, vim is sucky. May 27 15:20:22 that doesn't make a whole lot of sense May 27 15:20:23 Ainulindale, :set noexpandtab May 27 15:20:52 personally, my vim settings dont screw with an existing file at all, ever, they only affect my changes. May 27 15:21:07 did you paste into vim and forget to use :set paste? May 27 15:21:23 it sounds more like user error than a vim problem, really May 27 15:21:32 or did you yank the lines into a buffer and paste them? May 27 15:22:11 03Sebastian Spaeth  07shr/import * r8fd09682c5 10openembedded.git/recipes/tasks/task-shr-feed.bb: May 27 15:22:11 dosbox: add to feed. closes SHR #442 May 27 15:22:11 Signed-off-by: Sebastian Spaeth May 27 15:22:11 kergoth: indeed, but it was just a good way for me to whine :-) May 27 15:22:16 :) May 27 15:23:48 OK- so my attempt to pass env vars to do_configure via do_configure_prepend did not work May 27 15:24:03 perhaps they are reset afterall? May 27 15:24:49 that's odd. can you paste your bb file so that we can see what exactly you were doing? May 27 15:25:19 could also inspect the run.do_configure script (in tmp/work/...) which is the half-digested output that gets actually passed to the shell May 27 15:26:40 it is sane-backends-1.0.19, i'm just trying to prune the list of drivers it will build May 27 15:26:51 using the existing .bb file May 27 15:27:55 pb_, how can I force glibc to build for arm5 on its own without changing too much? is there a variable I can set in local.conf to force cflags for a certain package? May 27 15:28:39 NekoXP: try TARGET_CC_ARCH_glibc = "-march=armv5te -mfpu=vfp -mfloat-abi=softfp" May 27 15:28:52 oh, not quite, needs to be TARGET_CC_ARCH_pn-glibc May 27 15:29:11 pb_, the run.configure includes this: May 27 15:29:18 BACKENDS="fujitsu canon_dr" May 27 15:29:23 autotools_do_configure May 27 15:29:25 ~lart us for bad design of OVERRIDES May 27 15:29:25 * ibot blasts us to oblivion with a kamehameha wave for bad design of OVERRIDES May 27 15:29:58 kitno: you probably need to export BACKENDS for configure to see it May 27 15:30:06 just setting it locally in the shell isn't going to do the job May 27 15:30:11 pn? May 27 15:30:17 yes- all other vars seem to be exported May 27 15:30:18 NekoXP: yup May 27 15:30:26 where did that come from? :] May 27 15:30:37 see the definition of OVERRIDES in bitbake.conf May 27 15:31:19 'pn-' is just a namespacing prefix to avoid different types of overrides getting mixed up with each other May 27 15:31:30 ah okay May 27 15:31:31 I see it May 27 15:31:38 if you didn't have that, it would be a disaster to have a package with the same name as a MACHINE, or a DISTRO May 27 15:31:42 or "fail-fast" :-} May 27 15:31:45 hehe May 27 15:33:30 cbrake: still downloading (slow connection), I assume everything's fine now, thank you! May 27 15:35:15 off it builds, lets see how this goes then :D May 27 15:39:17 pb_: configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails sanity check May 27 15:40:15 where does config.log get dumped on this kind of error? May 27 15:40:32 NekoXP: You are rebuilding glibc, right? May 27 15:40:42 yes May 27 15:41:06 I have seen this effect too some time ago. May 27 15:41:19 03Koen Kooi  07org.openembedded.dev * rf18b565b69 10openembedded.git/recipes/xorg-proto/xorg-proto-common.inc: xorg proto common: depend on util-macros May 27 15:41:20 03Koen Kooi  07org.openembedded.dev * r528989b924 10openembedded.git/recipes/xorg-proto/xextproto-native_7.0.5.bb: xextproto-native: add util-macros DEPENDS May 27 15:41:22 03Koen Kooi  07org.openembedded.dev * r900c4aa7c3 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom 2009.X: require newer util-macros May 27 15:41:22 03Koen Kooi  07org.openembedded.dev * rfc10c6b949 10openembedded.git/recipes/angstrom/ (angstrom-led-config.bb angstrom-led-config/sheevaplug/leds): angstrom-led-config: add sheevaplug support May 27 15:41:47 florian, usually if it gets that bad I do a complete clean from scratch and start again but... 600 packages before it is a lot of packages to rebuild :D May 27 15:41:56 right May 27 15:42:11 btw what's the official way to do a clean clean May 27 15:42:13 bitbake -c clean world? May 27 15:42:27 I had to clean all gcc and glibc things in the chain before and it worked May 27 15:43:56 <|AbsyntH|> anybody that have compiled openwrt for a mpc8343e ? May 27 16:00:19 NekoXP: in tmp/work/... May 27 16:00:57 find . -name config.log didn't find anything at all :/ May 27 16:01:08 never mind, I am doing a full clean anyway May 27 16:01:22 I have plenty of other stuff to do while it churns for a couple hours :D May 27 16:03:26 hmm for armv7 fpu shouldn't be soft should it? :/ May 27 16:04:23 at least it can be ;] May 27 16:05:04 does bitbake report the mfloat-abi value or just "soft" and "hard"? May 27 16:11:36 03Klaus Kurzmann  07shr/import * rd3e81f71dc 10openembedded.git/recipes/e17/e-wm_svn.bb: May 27 16:11:36 e-wm: apply illume-disable-screensaver.patch for the shr distro too May 27 16:11:36 Signed-off-by: Klaus Kurzmann May 27 16:11:36 03Klaus Kurzmann  07shr/import * r3ad71dd53e 10openembedded.git/recipes/fbreader/fbreader_0.8.2a.bb: May 27 16:11:36 fbreader: apply fbreader-openmoko.patch for the shr distro too May 27 16:11:40 Signed-off-by: Klaus Kurzmann May 27 16:24:03 03Marcin Juszkiewicz  07org.openembedded.dev * r46bbb83622 10openembedded.git/recipes/xorg-driver/ (xf86-input-tslib/xserver16.patch xf86-input-tslib_0.0.5.bb): xf86-input-tslib: make it build against XServer 1.6 May 27 16:25:49 03Julien 'Ainulindale' Cassignol  07shr/import * r8948517b6b 10openembedded.git/recipes/libgee/libgee_git.bb: May 27 16:25:49 Revert "libgee_git: Removed useless PR." May 27 16:25:49 This reverts commit d0a9bc0e71fba688e7dea939e6b52864ba0791a2, per the nice comment of Mike Westerhof (see http://docs.openembedded.org/usermanual/usermanual.html#recipes_versioning ) May 27 16:25:50 03Julien 'Ainulindale' Cassignol  07shr/import * r8cea6c51c0 10openembedded.git/: Merge branch 'shr/import' of ssh://git@git.openembedded.net/openembedded into shr/import May 27 16:44:28 Ok guys- basic oe question May 27 16:44:43 how do i set exactly which version of a package gets used May 27 16:44:58 03Didier 'Ptitjes  07shr/import * re239e44bb9 10openembedded.git/classes/girepository.bbclass: May 27 16:44:58 Add a girepository bbclass May 27 16:44:58 Signed-off-by: Didier 'Ptitjes May 27 16:44:59 03Julien 'Ainulindale' Cassignol  07shr/import * rc48d635c05 10openembedded.git/classes/girepository.bbclass: girrepository.bbclass: Comment out *.gir in FILES for -dev. May 27 16:45:01 03Didier 'Ptitjes  07shr/import * r2dd0cff037 10openembedded.git/recipes/vala/vala-native_0.7.2+fso1.bb: May 27 16:45:04 vala/vala-native: Factorize fso's vala version number May 27 16:45:06 Signed-off-by: Didier 'Ptitjes May 27 16:45:07 kitno: PREFERRED_VERSION_packagename = "1.1.1" May 27 16:45:08 03Didier 'Ptitjes  07shr/import * r98bd3cb691 10openembedded.git/recipes/freesmartphone/libfso-glib_git.bb: May 27 16:45:11 freesmartphone/libfso-glib: Rework to use vala and girepository bbclasses May 27 16:45:12 i'm having some problems with libusb1 May 27 16:45:13 Signed-off-by: Didier 'Ptitjes May 27 16:45:15 03Didier 'Ptitjes  07shr/import * r7bc7142240 10openembedded.git/recipes/shr/ (libmodulo_git.bb ophonekitd-vala_git.bb): May 27 16:45:18 shr/libmodulo, shr/ophonekitd-vala: Inherit from vala and girepository bbclasses and replace references to libvala by libgee May 27 16:45:21 Signed-off-by: Didier 'Ptitjes May 27 16:45:25 03Koen Kooi  07org.openembedded.dev * r90ef9bdd07 10openembedded.git/recipes/xorg-driver/ (6 files): xorg drivers: bump PR for xorg 1.6.x changes May 27 16:45:30 03Koen Kooi  07org.openembedded.dev * reea3ac59f1 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom 2009.X: prefer Xorg-xserver 1.6.1 May 27 16:45:30 booxter, where should I set that? May 27 16:45:48 kitno: in your local.conf or better machine config file May 27 16:48:20 heh, I see CF cards have gotten a bit bigger since last time I bought one. May 27 16:48:39 :-) May 27 16:48:48 * hrw|meeting -> off May 27 16:49:03 pb_: got 4GB instead of 512M one? May 27 16:49:35 8GB actually, but yeah May 27 16:49:45 the largest one I owned previously was 256MB :-} May 27 16:50:50 damn, they've gotten large indeed May 27 16:51:11 florian: I just found my old SLR in a cupboard and decided to buy a digital body to go with it. May 27 16:51:19 I forgot where I have 256M one May 27 16:51:32 though, funnily enough, today I've been thinking that it would be fun to start taking photos with film again. I should see if I can find anybody around here that still sells HP5. May 27 16:51:37 alix has 2GB one just for grub and /boot/ May 27 16:51:53 kergoth: yah, you can buy 32GB cards nowadays. May 27 16:51:57 fairly expensive though May 27 16:52:00 pb_: that's a good idea. May 27 16:52:02 pb_: contact Koen about using film for photos.. he use such stuff May 27 16:52:12 pb_: you can get cards which do 40MB/s even May 27 16:52:35 yeah, the sandisk extreme iv ones are meant to be 40MB/s May 27 16:52:54 they cost about four times as much as the next performance level down, though, so I decided to stick with the 30MB/s ones May 27 16:55:15 florian: is it easy to scan B&W negatives and then print them digitally? the thing that has always put me off shooting film is that, although I do have an enlarger stashed away somewhere, it'd be a bit of a pain to set up everything that I need for traditional printing. May 27 16:55:58 it'd be nice to be able to just develop the negatives, scan them, look at them on the computer and then only print the ones that are worthwhile rather than all that messing around with contact sheets. May 27 16:57:31 pb_: ask Koen May 27 16:57:32 ;) May 27 16:57:43 pb_, i dont know much about film, but i know a fair bit about scanning May 27 16:57:49 and yes- you can do what you want May 27 16:58:06 pb_: it depends... I haven't done this for quite a while. For b&w it shouldn't be that hard unless you have a large format and need a matching scanner :) May 27 16:58:14 you just need a good scanner May 27 16:58:35 I guess for an acceptable quality you need a good film scanner. May 27 16:58:38 unfortunately, film scanning is generally better supported on windows May 27 16:58:39 heh May 27 16:58:59 florian: yah, mine would all be 35mm. I guess a standard scanner doesn't have enough resolution to deal with negatives that small. May 27 16:59:37 obviously easier for you medium-format people :-} May 27 16:59:42 pb_: yes for 35mm it shouldn't be hatd to find one for an acceptable proce. May 27 16:59:46 you will want things like dust removal too, so a specialized scanner is nice May 27 17:00:02 okay, cool. May 27 17:00:19 that requires an ir channel May 27 17:00:41 pb_: no... medium format people want medium format resolution and therefore need special scanners too. May 27 17:00:52 pb_: that's why I don't have one... May 27 17:00:59 kitno: good point May 27 17:01:03 epson is up to 6400dpi on some of their flatbeds, but they are not supported by sane May 27 17:01:11 florian: ah yes, I guess that's true May 27 17:01:29 I knew there must be a reason why people shot on medium format :-} May 27 17:01:57 its not because they like to carry heavy lenses ;) May 27 17:02:13 heh May 27 17:02:57 Its a shame that its ages ago I used any film... May 27 17:06:37 guys- even when i remove all the stamps, bb insists on not rebuilding a package. is there something else i have to touch? May 27 17:07:05 use bitbake -c clean package May 27 17:37:50 hi isn't our openssh version a bit old? May 27 17:38:04 there was a flaw recently... May 27 17:38:29 sort of man in the middle attack May 27 17:38:37 patches welcome :P May 27 17:38:45 yes May 27 17:38:47 and review too May 27 17:38:55 because it's a critical part isn't it? May 27 17:39:04 even if most of people uses dropbear May 27 17:39:16 but dropbear doesn't have all openssh's features May 27 17:39:22 Gnutoo: the recent "bug" is *not* really worth patching :) May 27 17:39:24 I'll try to craft somehting May 27 17:39:28 ah ok May 27 17:39:41 but bumping the version is always a good thing I think May 27 17:40:04 ok I'll try to cross-compile it May 27 17:40:09 pb_ that pn-glibc trick seems to have worked! May 27 17:43:29 I'll update openssh later...I have to eat and go to the supermarket May 27 17:45:29 ok. guys- i cannot seem to get libusb-0.1.12 to install properly May 27 17:45:45 or at least, the apps that depend on it cannot find the headers at build time May 27 17:46:13 is there some magic to get it to install headers? May 27 17:49:43 Isnt anybody getting this? /usr/include/asm/sigcontext.h:28: error: expected specifier-qualifier-list before '__u64' May 27 17:49:43 | /usr/include/asm/sigcontext.h:191: error: expected specifier-qualifier-list before '__u64' May 27 17:50:03 kitno, why are you trying to install libusb-0.1.12? May 27 17:50:27 because libusb compat is borked on bigendian with sane May 27 17:51:00 basically, there is no easy way to do this atm May 27 17:51:04 grr May 27 17:51:12 * Crofton|work has a patch I use for gnuradio May 27 17:51:17 yeah May 27 17:51:39 hmm, what does the patch entail? May 27 17:51:46 we badly need a way to switch, for these reasons May 27 17:52:10 I'm going to dredge it up and send it to the list May 27 17:52:17 well, it actually builds correctly if i change the prefered version May 27 17:52:22 libusb builds May 27 17:52:30 I also tried building a copy in the recipe that needs it and linking statically May 27 17:52:37 but, I can't figure out how to do it May 27 17:52:53 the depends all force libusb-compat to build May 27 17:53:10 and libusb-compat and libusb install files with the same name May 27 17:53:14 chaos enues May 27 17:53:18 ensues May 27 17:53:25 well, if we could install libusb second, it would overwrite May 27 17:53:46 yeah, but then stuff built against compat tends to not work May 27 17:54:09 why would that happen? May 27 17:54:15 compat uses the same api? May 27 17:54:30 I'm told chaos ensues May 27 17:54:46 I suspect things aren't exactly the same May 27 17:55:03 nah- that is the whole point of compat May 27 17:55:23 progs compiled against 0.1.12 should not notice the difference May 27 17:55:26 well, I'm told it leads to insanity May 27 17:55:33 ok May 27 17:55:34 have you tried it? May 27 17:55:41 i am about to... May 27 17:55:51 ok May 27 17:55:57 let me know what happens May 27 17:56:13 if that doesn't work ping me to circulate the patch May 27 17:56:53 ok- forgive me, but how should i ping you? May 27 17:58:02 here May 27 17:58:09 ahh May 27 17:58:47 another option is to try and fix libusb May 27 17:58:56 http://www.nabble.com/build-libusb-for-big-endian-target---how-to-and-a-recommended-patch-td22956999.html May 27 17:58:58 -compat? May 27 17:58:59 yes May 27 18:07:06 * * OE Bug 5130 has been created by kristoffer.ericson(AT)gmail.com May 27 18:07:08 * * Coreutils-native_7.2 fails to compile May 27 18:07:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5130 May 27 18:12:25 anyone working with ar71xx processors? May 27 18:14:14 NekoXP: very good May 27 18:17:30 building xorg now hooray May 27 18:29:42 03Koen Kooi  07stable/2009 * r85b9a71a9c 10openembedded.git/ (242 files in 18 dirs): May 27 18:29:42 linux-omap: sync everything with .dev May 27 18:29:42 * also sync the machine files to match the kernels May 27 18:29:42 Acked-by: Tom Rini May 27 18:29:42 Signed-off-by: Koen Kooi May 27 18:34:05 re May 27 18:34:17 re May 27 18:35:57 flo_lap: wb May 27 19:00:18 Quick question, anyone having build/requirements issues since XOrg 1.6.1 hit .dev? Mainly the fact that OE seems to carry older versions of some of the component (well after a quick look it seems that way). May 27 19:07:22 * cbrake adds some news to http://wiki.openembedded.net/index.php/Main_Page May 27 19:10:33 cbrake: cool! May 27 19:11:05 jimsheldon: yes, very May 27 19:11:46 now I want to check out their SDK... May 27 19:12:02 oh cool! May 27 19:12:05 webOS that is, montavistat is cool too May 27 19:12:09 *montavista May 27 19:12:43 cbrake: is there a press release from Palm mentioning OE? May 27 19:13:18 jimsheldon: no, the information is direct from their developers, and I just go permission to post the news May 27 19:13:25 cbrake: did you try their sdk? May 27 19:13:27 oh wow May 27 19:13:33 flo_lap: not yet, have you? May 27 19:13:51 flo_lap: btw, what do I have to do to get oe-commits mails to work? May 27 19:13:55 cbrake: not yet... sounds liek its time for a review :) May 27 19:14:08 flo_lap: yes, I agree May 27 19:14:27 03Koen Kooi  07org.openembedded.dev * r5f8a94ba44 10openembedded.git/conf/distro/angstrom-2008.1.conf: angstrom 2009.X: remove some useless preffered_version files May 27 19:14:33 flo_lap: I recently moved the git repo to a new server May 27 19:14:34 03Koen Kooi  07org.openembedded.dev * r576f968665 10openembedded.git/conf/machine/include/omap3.inc: omap3: bump MACHINE_KERNEL_PR May 27 19:15:50 flo_lap: mails are currently coming from git@new.openembedded.org, I'll change to git@git.openembedded.org May 27 19:16:50 cbrake: I do not know much about the git server unluckily. I guess once the address the mails come from matches it should just work... May 27 19:17:31 hmmm, maybe this news means I should have waited for the Pre instead of getting the G1 ... May 27 19:18:41 cbrake: now that is interesting news, seems a lot of devices are using OE in the embedded space these days. May 27 19:18:46 flo_lap: the mails used to come from: GIT User account May 27 19:19:42 flo_lap: now they are coming from git@git.openembedded.org May 27 19:19:56 flo_lap: do you manage the mail lists at linuxtogo? May 27 19:20:02 flo_lap: or do I need to talk to someone else? May 27 19:20:25 cbrake: Yes I would have the power to do whatever we need. May 27 19:20:33 Who owns the list? May 27 19:20:41 flo_lap: I have no idea May 27 19:21:02 flo_lap: but I now admin the git server May 27 19:21:10 flo_lap: so would like to get the commit mails working again May 27 19:21:31 * flo_lap wants to avoid doing changes to project stuff as admin May 27 19:22:03 Crofton, ping! May 27 19:22:04 flo_lap: is there any way I can get access to the mail list config? May 27 19:22:22 flo_lap: is that part of gforge or something? May 27 19:22:40 kitno, libusb attempt failed? May 27 19:22:56 i built a patch that works for libusb1 May 27 19:22:57 what about patching libusb1 per the email? May 27 19:23:02 awesome! May 27 19:23:03 yeap May 27 19:23:33 cbrake: not really... its somehow related to gforge but managed by mailamn May 27 19:23:43 03Koen Kooi  07org.openembedded.dev * r88f1746e04 10openembedded.git/recipes/xorg-lib/libx11_1.1.5.bb: libx11 1.1.5: the old "floating point exeception" problem has arrived again, bump MIN_REHASH to 16 to get around it May 27 19:23:59 i know its not the right way to do things, but if libusb is too stupid to determine the endianess, i just clubbed it with a stick May 27 19:24:31 aha May 27 19:24:33 "Openembedded-commits list run by mickeyl at linuxtogo.org" May 27 19:24:53 mickey|zzZZzz: ping! May 27 19:25:12 flo_lap: ok, thanks -- I'll email mickey May 27 19:25:58 cbrake: If he doesn't know how to help I can take a look May 27 19:26:08 flo_lap: ok, thanks! May 27 19:27:18 cbrake: yw May 27 19:28:26 hi mickeyl May 27 19:28:40 morning May 27 19:29:43 hi mickeyl May 27 19:32:28 03Koen Kooi  07stable/2009 * r0c3538f216 10openembedded.git/recipes/powervr-drivers/omap3-sgx-modules_1.3.13.1397.bb: May 27 19:32:28 omap3sgx-modules: sync with .dev May 27 19:32:28 * update to build against newer kernels May 27 19:32:28 * switch to MACHINE_KERNEL_PR May 27 19:32:28 Acked-by: Philip Balister May 27 19:32:30 Signed-off-by: Koen Kooi May 27 19:45:22 DJWillis: agreed, OE does seem to be getting a lot of use. Android and Ubuntu/Debian seem to be the other ones to watch, but I've not yet found them useful for my work yet. May 27 19:45:51 cbrake, we will crush them :) May 27 19:49:18 :-) May 27 19:51:33 03Martin Dietze  07org.openembedded.dev * r7cab51e1cf 10openembedded.git/recipes/netbase/netbase/ (mtx-1/interfaces mtx-2/interfaces): netbase: updated etc/network/interfaces files for mtx-[12] * since hostap and madwifi drivers are installed, the system will pick the config for whatever wlan card is found May 27 19:51:33 03Martin Dietze  07org.openembedded.dev * r83f70f58f4 10openembedded.git/recipes/binutils/ (2 files in 2 dirs): Fixed broken configure script which lead to invalid prefix for cross executables in some cases * the sed substitutions for flags like `--program-transform-name' were not global, they are now May 27 19:51:34 03Martin Dietze  07org.openembedded.dev * r5bb0928493 10openembedded.git/recipes/elvis/elvis_2.2.0.bb: Fixed broken download URL for elvis May 27 19:51:37 03Martin Dietze  07org.openembedded.dev * r362a06a51e 10openembedded.git/recipes/glibc/ (7 files in 4 dirs): May 27 19:51:40 Patches to get glibc 2.3.2 and 2.3.3 compile for nylon * disable check of gcc May 27 19:51:42 version in configure script * add definition of macro _ABIO32 for mipsel May 27 19:51:44 architecture in sysdeps/mips/sgidefs.h * added missing ld.so.conf for above May 27 19:51:46 glibc versions May 27 19:51:48 03Martin Dietze  07org.openembedded.dev * r782df95b7d 10openembedded.git/recipes/openswan/ (openswan_2.2.0.bb openswan_2.4.7.bb): openswan: fixed broken download URL May 27 19:51:51 03Martin Dietze  07org.openembedded.dev * r46df71fbf9 10openembedded.git/recipes/hostap/ (3 files in 2 dirs): hostap: nylon-specific patches * for hostap-daemon 0.4.4, the MADWIFI_BSD macro is unset * for hostap-daemon 0.5.10, dependency and include dirs for madwifi are added May 27 19:52:01 03Martin Dietze  07org.openembedded.dev * reabb7e3ab0 10openembedded.git/recipes/libusb/ (6 files in 4 dirs): libusb: added patch to allow compiling with gcc 3, used by nylon distro * the gcc flags -fvisibility=hidden and -Wno-pointer-sign are removed from configure script and Makefile templates May 27 19:52:05 03Martin Dietze  07org.openembedded.dev * r29d2dd362d 10openembedded.git/recipes/linux-libc-headers/ (2 files): linux-libc-headers: nylon-specific addition to do_stage May 27 19:52:08 03Martin Dietze  07org.openembedded.dev * r6e975fb667 10openembedded.git/recipes/mobilemesh/mobilemesh_1.2.bb: mobilemesh: fixed broken download URL May 27 19:52:12 03Martin Dietze  07org.openembedded.dev * r80e14557ae 10openembedded.git/recipes/wlan-ng/wlan-ng-utils.inc: wlan-ng: ARM-binary usbctl is only installed on ARM architectures May 27 19:52:18 03Martin Dietze  07org.openembedded.dev * r919e3fcdd6 10openembedded.git/recipes/logrotate-script/logrotate-script_cvs.bb: logrotate-script: fixed broken download URL May 27 19:52:21 03Martin Dietze  07org.openembedded.dev * r207d019413 10openembedded.git/recipes/meta/nylon-feed.inc: nylon-feed: removed usbutils from nylon feed May 27 19:52:24 03Martin Dietze  07org.openembedded.dev * rcb90146438 10openembedded.git/recipes/initscripts/initscripts-1.0/bootmisc.sh: initscripts: fixed bootmisc.sh so that hwclock.sh is only called if installed May 27 19:52:30 03Martin Dietze  07org.openembedded.dev * r4103b643af 10openembedded.git/recipes/linux-hotplug/ (2 files in 2 dirs): linux-hotplug: fixed the path to the hotplug command in pci.rc * the hotplug command was assumed to be in /sbin, but it actually is in /usr/sbin May 27 19:52:34 03Martin Dietze  07org.openembedded.dev * r3e90499e21 10openembedded.git/recipes/gnutls/gnutls.inc: gnutsl: added missing build dependency guile-native May 27 19:52:39 03Martin Dietze  07org.openembedded.dev * rdbf948c5c9 10openembedded.git/recipes/rrdtool/rrdtool_1.0.49.bb: May 27 19:52:42 rrdtool: fixed gcc options clashing with gcc 3 for nylon, refined package May 27 19:52:44 definition for insane.bbclass * the gcc option `-Wdeclaration-after-statement' May 27 19:52:46 broke the gcc 3 build, this is fixed now for nylon * the package definition May 27 19:52:54 ${libdir}/perl broke the build due to QA problems, this is now replaced by the May 27 19:52:56 list of files actually installed May 27 19:52:58 03Martin Dietze  07org.openembedded.dev * rf97874313a 10openembedded.git/recipes/perl/perl-native_5.8.8.bb: perl-native: removed settings clashing with gcc 3 for nylon * Config_heavy.pl and config.sh contained the gcc flag `-Wdeclaration-after-statement' which broke the build with gcc 3, this is disabled for nylon now May 27 19:53:05 03Martin Dietze  07org.openembedded.dev * r173ca78f2e 10openembedded.git/recipes/gcc/gcc-configure-common.inc: gcc: made sure that no unsubstituted @LDFLAGS@ is left in the generated Makefiles May 27 20:05:01 flo_lap: ping May 27 20:05:09 flo_lap: can i get access to the mobile-linux git, please? May 27 20:05:42 mickeyl: I don't have access to it myself.. apart from reading of course. May 27 20:05:49 hmm May 27 20:05:56 who's the maintainer then? May 27 20:06:00 dcordes? May 27 20:06:01 mickeyl: That would be a question for Kevin2 May 27 20:07:58 But this reminds me that I intended to join and help with its marketing :) May 27 20:12:01 cbrake: Ubuntu is a bit big and Andriod,while interesting, is a bit of a turn off with the Java focus ;-) May 27 20:31:18 i'm behind a restrictive http proxy... wget is working through the proxy, but cvs checkouts are not... Is there an alternative? May 27 20:31:39 alternative for the cvs checkouts May 27 20:32:45 rphillips: not really, I think by default it will try to retrieve a snapshot first but if there is none available it will check out directly May 27 20:33:13 rphillips: there should be a way to configure CVS to use the proxy though I would think May 27 20:33:22 not sure though, haven't had to deal with that issue myself May 27 20:33:45 I haven't used cvs in a long time... I'll google some more. thanks May 27 20:36:15 rphillips: that depends on the protocol being used. if it's a pserver checkout, pretty sure ou'd have to use one of those http proxy LD_PRELOAD libs to do it. May 27 20:36:22 thats what i used to have to use when i worked at TI May 27 20:39:01 kergoth: i'll check that out May 27 20:39:10 03Koen Kooi  07org.openembedded.dev * rdc0a87f3d9 10openembedded.git/recipes/xorg-lib/libxext_1.0.5.bb: libxext: add 1.0.6 May 27 20:39:10 03Koen Kooi  07org.openembedded.dev * rb3f8958f0a 10openembedded.git/ (3 files in 3 dirs): libx11: add 1.2 May 27 20:39:16 03Koen Kooi  07org.openembedded.dev * r9e3fda07e7 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 27 20:39:24 03Koen Kooi  07org.openembedded.dev * re47846def8 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux-omap 2.6.29: add more DSS2 patches May 27 21:18:21 03Koen Kooi  07fso/milestone5.5 * r28f6e06674 10openembedded.git/ (conf/checksums.ini recipes/bluez/bluez4_4.39.bb): bluez: add 4.39 May 27 21:18:22 03Koen Kooi  07fso/milestone5.5 * r4acbdeef77 10openembedded.git/recipes/bluez/bluez4_4.39.bb: May 27 21:18:22 bluez4 4.39: actually run initscript May 27 21:18:22 * now *that's* an embarassing bug! May 27 21:18:24 03Michael 'Mickey' Lauer  07fso/milestone5.5 * rb50ede9290 10openembedded.git/recipes/bluez/bluez4/fix-dfutool-usb-declaration-mismatch.patch: bluez4: add compile patch fixing some usb declaration mismatch May 27 21:18:31 03Angus Ainslie  07fso/milestone5.5 * r1b08c557d0 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: paroli: add serenity theme May 27 21:18:31 03Angus Ainslie  07fso/milestone5.5 * ra71bd0b436 10openembedded.git/conf/distro/openmoko.conf: openmoko.conf: and prefered-om-2009-versions and set bluez4 as the prefered provider May 27 22:01:35 03Julien 'Ainulindale' Cassignol  07shr/import * r5c1193ab5c 10openembedded.git/recipes/tasks/task-shr-minimal.bb: task-shr-minimal: Added notifier to the shr apps. May 27 22:02:59 03Koen Kooi  07org.openembedded.dev * rb70a44d9b6 10openembedded.git/classes/lockdown.bbclass: May 27 22:02:59 lockdown: steal some bits from openmoko that will dump prefferred_versions to TMPDIR May 27 22:02:59 * freeze.inc would work as well, but I got this working first May 27 22:11:17 03Julien 'Ainulindale' Cassignol  07shr/import * r79c978aa68 10openembedded.git/conf/distro/include/ (shr-autorev-unstable.inc shr-autorev.inc): shr-autorev-*: Updated SRCREV for unstable to testing migration. May 27 22:29:54 03Julien 'Ainulindale' Cassignol  07shr/import * r73882fc926 10openembedded.git/ (2 files in 2 dirs): alsa-scenarii-shr: Added new recipe. May 27 22:30:05 03Julien 'Ainulindale' Cassignol  07shr/import * rf490d027d0 10openembedded.git/recipes/tasks/task-shr-minimal.bb: task-shr-minimal: Changed from openmoko-alsa-scenarios to alsa-scenarii-shr. May 27 22:44:54 03Julien 'Ainulindale' Cassignol  07shr/import * rcb1855490c 10openembedded.git/recipes/ (9 files in 6 dirs): May 27 22:44:54 Fixed missing OVERRIDES. May 27 22:44:54 Signed-off-by: Julien 'Ainulindale' Cassignol May 27 22:50:33 03Paul Eggleton  07org.openembedded.dev * r477ee8ab97 10openembedded.git/recipes/h2200-bootloader/h2200-bootloader.bb: h2200-bootloader: fix for mtd being built into kernel again May 27 22:50:45 03Paul Eggleton  07org.openembedded.dev * r0e8d0a39df 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 27 23:24:47 03Paul Eggleton  07org.openembedded.dev * rac97bd863e 10openembedded.git/recipes/ (5 files in 4 dirs): May 27 23:24:47 libopie2/qte: fix bad cursor key rotation on some devices May 27 23:24:47 * Should fix bad cursor key rotation with respect to the screen on May 27 23:24:47 some devices and hopefully won't affect devices that were OK. May 27 23:24:47 * All responsibility for rotating the cursor keys now lies with May 27 23:24:49 ODevice (libopie2). Any further fixes need to be applied there. May 27 23:24:53 * Refer to OE bug #3678 for more information. May 27 23:26:53 03Paul Eggleton  07org.openembedded.dev * r1030d3334c 10openembedded.git/MAINTAINERS: MAINTAINERS: add myself to list May 28 00:26:10 tlbmiss, k, thanks May 28 00:26:12 ga May 28 02:02:04 should do_package_stage_all for xorg-image-1.0-r0 really take 3 hours churning my cpu and not doing any disk activity? **** ENDING LOGGING AT Thu May 28 02:59:58 2009