**** BEGIN LOGGING AT Wed May 05 02:59:56 2010 May 05 05:44:42 03Khem Raj  07org.openembedded.dev * r214cda795a 10openembedded.git/recipes/gdb/ (9 files in 2 dirs): May 05 05:44:42 gdb-7.1: Add recipes for version 7.1 May 05 05:44:42 Signed-off-by: Khem Raj May 05 05:46:02 03Khem Raj  07org.openembedded.dev * r940ca14bd7 10openembedded.git/recipes/eglibc/eglibc_svn.bb: May 05 05:46:02 eglibc_svn.bb: Move SRCREV to latest trunk. May 05 05:46:02 Signed-off-by: Khem Raj May 05 06:56:12 Is the pyqt recipe abandoned? I complained about a compile error on the mailing list yesterday. Today I actually opened the recipe, and it seems pretty outdated versionwise. May 05 07:01:37 well that e-mail didn't show much.. May 05 07:05:15 JaMa: the paste had expired, or the compilation output said little? May 05 07:06:57 no info about distro/machine combination, paste was there, but who knows for how long.. (pity when someone finds that you had same issue few months ago, but it will be already gone) May 05 07:07:08 Anyway, the pyqt recipe is based on an old Qt-version. May 05 07:07:39 JaMa: fair points. was in a bit of a hurry when I wrote the mail :) May 05 07:17:22 JaMa: I replied to the topic with a bit more verbosity, and I'm trying to compile with newer versions of PyQt/SIP. May 05 07:26:49 good morning May 05 07:26:52 tasslehoff: I fear, that I still don't have idea (I don't build python-pyqt here), but your chances for helpfull reply are now trippled :) May 05 07:26:56 mckoan: moin May 05 07:27:10 moin JaMa May 05 07:27:59 JaMa: hehe. that's something :) May 05 07:31:15 XorA: the Debian project leader gave me some details about the voting system May 05 07:31:33 mckoan: cool May 05 07:31:48 XorA: their system is based on devotee and www.selectricity.org May 05 07:32:22 mckoan: ah useful, you are awesome May 05 07:32:30 mckoan: somehow I never discovered that site May 05 07:32:39 XorA: glad to be helpful :-D May 05 07:34:20 XorA: the latter looks a great project May 05 07:35:02 selectricity is developed by Mako Hill, debian developer and MIT researcher May 05 07:35:50 its still not actually working, but good to keep an eye on May 05 07:57:28 03Koen Kooi  07org.openembedded.dev * rae3a52f399 10openembedded.git/conf/distro/include/sane-srcrevs.inc: efl: bump SRCREV to get fixes for the eina_stringshare typos May 05 08:27:46 oh..big pull today... May 05 08:34:54 hi guys, i'm trying to update the imagemagick recipe to compile a newer version, but automake is unhappy about AM_SILENT_RULES. any pointers on what i could do ? May 05 09:05:27 03sledz  07org.openembedded.dev * r95a6933e4e 10openembedded.git/recipes/oxnas-boot-tools/ (3 files in 2 dirs): May 05 09:05:27 oxnas-boot-tools: new recipe May 05 09:05:27 Boot tools for OXNAS boards May 05 09:05:27 Signed-off-by: Steffen Sledz May 05 09:05:37 03sledz  07org.openembedded.dev * rb9945f469e 10openembedded.git/recipes/u-boot/u-boot_2009.03.bb: May 05 09:05:37 u-boot_2009.03: additional image processing for hipox machine May 05 09:05:37 Signed-off-by: Steffen Sledz May 05 09:16:01 03Koen Kooi  07org.openembedded.dev * r37f967dd9b 10openembedded.git/recipes/angstrom/ (18 files in 4 dirs): e-wm-config-angstrom: remove exebuf and msgbus_lang May 05 09:36:00 03Koen Kooi  07org.openembedded.dev * r90760a78fd 10openembedded.git/recipes/perl/ (perl-native_5.10.1.bb perl-native_5.8.8.bb): May 05 09:36:00 perl-native: attempt to repair staging, bump PR May 05 09:36:00 this should make things work again after http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=12c5d82663ff4436f4d979b4de1d4475694c7b9f May 05 09:47:13 gdb missing libelf dependency? or is it only for new 7.1 version? CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/libelf without May 05 09:55:51 03Koen Kooi  07org.openembedded.dev * re4b67f6417 10openembedded.git/recipes/aspell/ (aspell_0.60.5.bb aspell_0.60.6.bb): aspell: convert to new style staging May 05 10:14:08 JaMa: oh, I think libelf is optional May 05 10:14:15 JaMa: check for a --disable-libelf May 05 10:14:58 hi, I sent 2 patches concerning module-base.bbclass : http://patchwork.openembedded.org/patch/2012/ and http://patchwork.openembedded.org/patch/2014/ : are these patches OK ? May 05 10:16:03 zecke: checked but still CROSS COMPILE Badness :/ May 05 10:19:19 JaMa: okay, two workarounds May 05 10:19:35 JaMa: a) disable lto (the toplevel configure is shared among some GNU projects) May 05 10:19:44 JaMa: b) point it to something May 05 10:20:00 I don't understand b) May 05 10:20:30 JaMa: it is only using -I/usr/include when --with-elf... is not supplied May 05 10:21:14 --with-elf=/jama/bada/du or --disable-lto should be okay for now. May 05 10:21:18 ah I see what you mean May 05 10:21:38 so should I push --disable-lto to recipe for all? May 05 10:22:03 JaMa: putting it in the gdb.inc should be fine. I don't think gdb is using libelf for something. May 05 10:22:25 ok, thanks May 05 10:23:17 kergoth: you are the author of tslib plugins? Can you help us with a plugin for the palm pre? May 05 11:01:37 hi all, i bitbaked my_own_customized_image.bb which had RDEPENDS += qte, does it also make ti necessary that tslib is also installed in that image?? Or do i have to install tslib as an extra?? May 05 11:16:43 does tslib installs with qte or do i have to install it separately?? May 05 11:39:33 Spyzer: you need to install the QtE ts plugin May 05 11:39:44 Spyzer: this should drag in tslib the library but also the plugins. May 05 11:46:22 thanks a lot, please do me one more favor and also tell me how do i do that?? I mean atleast the package name May 05 11:48:53 if i just do IMAGE_INSTALL += tslib in my_own_customized_image.bb will that be ok too May 05 12:02:42 Spyzer: i have no qte build here, look at your available qte packets. :) May 05 12:07:19 zecke, are you hacking gsm yet? May 05 12:28:11 03Martin Jansa  07org.openembedded.dev * r567dd4c178 10openembedded.git/recipes/starling/starling_0.9.bb: May 05 12:28:11 starling: depend on gst-plugin-mad only for not enterprise distro May 05 12:28:11 Signed-off-by: Martin Jansa May 05 12:28:14 03Martin Jansa  07org.openembedded.dev * r9e5ad9b18a 10openembedded.git/recipes/linux/linux/spitz/defconfig: May 05 12:28:15 linux: spitz defconfig, readd CONFIG_PM May 05 12:28:15 * lost somewhere during defconfig merges/upgrades May 05 12:28:15 * also missing in 2.6.33 defconfig May 05 12:28:15 * suspend/resume works again :) May 05 12:28:15 Signed-off-by: Martin Jansa May 05 12:28:16 03Martin Jansa  07org.openembedded.dev * ra9bd4f7a9f 10openembedded.git/recipes/openmoko-3rdparty/pisi_0.5.2.bb: May 05 12:28:16 pisi: upgrade to 0.5.3 May 05 12:28:17 Signed-off-by: Martin Jansa May 05 12:28:17 03Martin Jansa  07org.openembedded.dev * r20741d404a 10openembedded.git/recipes/openmoko-3rdparty/podboy_svn.bb: May 05 12:28:18 podboy: depend on gst-plugin-mad only for not enterprise distro May 05 12:28:18 Signed-off-by: Martin Jansa May 05 12:28:19 03Martin Jansa  07org.openembedded.dev * r13c6fcb094 10openembedded.git/recipes/gdb/gdb.inc: May 05 12:28:19 gdb: disable-lto as suggested by zecke on #oe May 05 12:28:26 * workaround for CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/libelf in gdb_7.1 May 05 12:28:27 Signed-off-by: Martin Jansa May 05 12:38:04 03Martin Jansa  07org.openembedded.dev * r43198bf4b5 10openembedded.git/recipes/shr/shr-settings_git.bb: May 05 12:38:04 shr-settings: adjust Categories in .desktop file because of changed Efreet filter in ELF_SRCREV 48174 May 05 12:38:04 Signed-off-by: Martin Jansa May 05 12:41:52 Spyzer: IMAGE_INSTALL += "qt4-embedded-plugin-mousedriver-tslib" May 05 12:47:05 03Jesse Gilles  07org.openembedded.dev * rd6cda85cb5 10openembedded.git/ (3 files in 2 dirs): python 2.6: add ssl to python-io May 05 13:57:00 thanks :) May 05 14:14:05 morning all May 05 14:14:27 morning May 05 14:15:31 hey RP, see my email re minimal? May 05 14:18:08 Tartarus: yes, I'm investigating, thanks May 05 14:18:17 Tartarus: I just pushed an updated branch May 05 14:18:32 Tartarus: not with that fixed but just rebased after recent OE.dev changes May 05 14:18:52 Need to get it merged... May 05 14:20:41 k May 05 14:30:43 Is there a config file that tells which MACHINEs are valid for a given DISTRO? May 05 14:33:36 dickelbeck, not really :) May 05 14:35:06 It's not really a binary thing, actually. :) Some distros work "mostly" on some machines, without any real effort on the part of the distro maintainer. May 05 15:00:54 Heinervdm: I'm the current tslib maintainer. I've messed with plugins before, but the vast majority of the existing plugins were written by others before I took over. May 05 15:01:36 hi kergoth_ May 05 15:01:51 hey May 05 15:25:51 hrw|gone: ping May 05 15:40:06 * kergoth_ struggles with pysh/PLY May 05 15:40:14 damn thing chokes on a regular case statement :( May 05 15:41:12 hmmm May 05 16:11:52 kergoth_: the pre touchscreen is a bit strange. We have a function that to calulate the x and y coordinates of the pointer now, but the TS doesn't report data on events only, it also reports data when nothing happens. So i think we could need some hints how to do it May 05 16:14:56 can you not detect the touch/release then? can you use pressure information to determine that, if it's not available directly? May 05 16:25:11 we can detect that, it needs some finetuning, but i think that we can use some threshold May 05 16:25:49 if you don't do it in the driver, there's a tslib plugin, iirc, pthres, that'll floor the pressure of anything below a certain value to 0 "release" May 05 16:25:57 afk May 05 16:26:56 my main question currently is what coordinates should we return May 05 16:27:27 we are doing some interpolation to find the correct position so we can return every value May 05 16:28:03 the absolute amount of the values don't matter, as long as they're sane relative to one another, as the calibration will bring them in line with the screen May 05 16:28:13 Crofton: thanks, it looks like the latest KOM thing from Kaelos is giving me grief against org.openembedded.dev latest. May 05 16:28:14 the key is that the transformation is linear May 05 16:28:36 Crofton: moving away from KOM now gets me further. May 05 16:28:44 if your coordinates aren't linear relative to one another, you'll need a custom calibration method / plugin, or you'll need to apply your own transformation to the raw values to make them linear May 05 16:29:16 NOTE: I actually don't have access to an embedded linux device with a touchscreen right now, so it's been a fair bit of time since I've messed with this stuff May 05 16:29:21 going from memory May 05 16:29:26 (which is weak :) May 05 16:29:32 ok :) May 05 16:29:46 then i think i can go a bit further May 05 16:30:34 can we sent our plugin to you? May 05 16:30:43 * kergoth_ 's had to deal wtih touchscreens that didn't behave linearly, giant pain in the ass.. coordinates that just act oddly in certain areas of the panel.. ugh.. May 05 16:30:49 sure May 05 16:30:58 clarson@kergoth.com May 05 16:31:07 ok :) May 05 16:31:19 alternatively, there's the tslib-general mailing list May 05 16:31:25 basically empty, other than the occasional bugfix patch or question May 05 16:31:52 the pre's touchscreen is a bit strange too, becuase it doesn't return coordinates. it returns 77 fields with an intensity May 05 16:32:57 so it has 7x11 fields and one has to interpolate the actual postion from the fieldnumber and the intensity of the field and the ones around May 05 16:33:24 ah, interesting May 05 16:33:44 * kergoth_ actually knows nothing about modern touchscreen panels that support multitouch and stuff.. haven't had the chance to play with one May 05 16:33:50 tslib is showing its age, i'm afraid :) May 05 16:33:57 :) May 05 16:36:03 I've heard that in the community there are those pushing more toward calibration/filtering in the kernel.. not sure I like that idea, and haven't been paying enough attention to those discussions May 05 16:36:08 * kergoth_ should fix that May 05 16:36:12 * kergoth_ isn't subscribed to the kernel lists anymore May 05 16:41:19 * mwester got unsubscribed from the kernel lists, due to his sloppy ISP May 05 16:41:42 heh May 05 16:41:53 that's sad, how did the isp manage that? May 05 16:42:11 * kergoth_ just couldn't keep up with it anymore.. listens to the lkml podcast thingy instead May 05 16:43:01 "routine" maintenance on their mail server, or so claims their tech support guy. Apparently it was rejecting or bouncing emails long enough that I got unsubscribed from pretty much every list I was on! :D May 05 16:43:25 Doesn't sound like "routine" to me, sounds like somebody screwed up their mail server! May 05 16:43:38 yikes, that's pretty bad May 05 16:43:46 you'd think they'd test that on a staging server first May 05 16:43:48 before going live May 05 16:43:53 They May 05 16:44:00 're not the most professional bunch. May 05 16:44:25 But they give me a 3Mbit pipe *up* to the internet, which I can't get any other way. May 05 16:44:35 nice May 05 16:45:38 yep. Really nice when I used to upload a lot of images and packages from my build server. May 05 16:49:58 hi all, i'm trying to write a recipe which checks out the source code from e git repo, however, i don't succeed... :( May 05 16:50:04 here is the code: http://pastebin.com/YNKrY0gz May 05 16:50:14 here is the output: http://pastebin.com/EUSBn4DD May 05 16:51:02 SRCREV issue. Set SRCREV to the revision of it you want, or .. whats that var again.. SRCREV = ${AUTOREV} or somesuch to get the tip of the branch.. something like that, anyway May 05 16:51:05 * kergoth_ greps May 05 16:51:09 its trying to grab a revision of "1" May 05 16:51:14 as thats theh default SRCREV May 05 16:51:16 silly, i know May 05 16:51:19 * kergoth_ shakes head May 05 16:51:34 do a git grep in the OE repo for SRCREV May 05 16:54:17 * kergoth_ hopes he got the answer before leaving :) May 05 16:55:02 kergoth: thanks! :) May 05 16:55:31 np. thanks for pastebin'ing the input and output by the way. it's refreshing not to have to ask for exact info rather than summary :) May 05 16:56:15 hehe ;) np ;) May 05 16:56:46 by the way, why isn't it trying to fetch from the git repo directly? May 05 16:57:28 i mean, why does it try to get the source from other servers first? May 05 16:58:30 bleikert: it's the mirroring support. allows you to use an internal source mirror, for example, rather than relying on upstream. the distro you're using defaults to checking their source mirror first May 05 16:58:43 see the MIRRORS and PREMIRRORS variables, either with grep, or in bitbake -e output May 05 16:59:06 MIRRORS are fallbacks, if upstream fails. PREMIRRORS, as you'd expect, are attmpted before the actual upstream May 05 16:59:19 thanks :) May 05 16:59:28 np May 05 16:59:29 can i disable it just for this recipe? May 05 17:00:45 what version of bitbake are you using? May 05 17:01:06 i'll assume a recent release. 1.8.x May 05 17:01:11 jup May 05 17:01:32 i mean yes :) May 05 17:01:36 in which case you'd probably SRC_TARBALL_STASH = "" and CVS_TARBALL_STASH = "" in the recipe (it falls back to the cvs value for compatibility) May 05 17:02:03 bitbake 1.10 branch / master can use the PREMIRRORS/MIRRORS mechanism used by non-scm fetches to fetch scm tarballs too. the older ones use the stash variables May 05 17:02:46 okay :) May 05 17:03:16 so, you could set PREMIRRORS = "" to avoid the use of the angstrom mirror for non-scm fetch or for scm fetch with bitbake master, as an alternative. May 05 17:03:24 the recipe can always override any configuration variable May 05 17:03:56 thx :) May 05 17:08:16 does oe support building 32 bit x86 toolchains on x86_64 host? May 05 17:08:47 targeting 32 bit x86, or binaries that are 32 bit x86 targeting something else? :) May 05 17:09:15 targeting something else, say ARM9 May 05 17:09:16 (gotta love cross..) May 05 17:09:25 ah, you want to b uild a toolchain you can run on 32 bit hosts May 05 17:09:42 you could probably override the BUILD_ARCH, which would change the --build autoconf argument May 05 17:09:54 might also need a -m32 in BUILD_CFLAGS, or run under linux32.. May 05 17:10:06 * kergoth_ should play with that more May 05 17:10:48 currently I have a schroot environment setup and I can do it, but this means complete karmic 32 bit environment eating my my disk on what is otherwise a x86_64 host May 05 17:11:12 ah May 05 17:11:29 * kergoth_ really wants an easy way to get OE to emit an LSB-compliant SDK May 05 17:12:44 kergoth: where would the overrides to BUILD_CFLAGS and BUILD_ARCH best take place? May 05 17:13:25 local.conf May 05 17:13:49 or site.conf. conceptually, this is about your machine or your build, not the distro, machine, or global setup May 05 17:13:56 so that's the most appropriate place to put it May 05 17:14:33 it helps if you think of the metadata as layered, least specific to most specific, with the latter overriding the former, both via config files and OVERRIDES. local *should* always be most specific, but it can't be, since the user defines MACHINE and DISTRO there, we have to load those after it :) May 05 17:14:45 * kergoth_ must be in an explanatory mood today May 05 17:17:53 kergoth: thanks. probably wont try it until I run out of disk space. :) May 05 17:18:47 heh :) May 05 17:19:01 how good is the eglibc support at this point? should I consider it in lieu of glibc for a small headless distro? May 05 17:19:27 good question.. I've heard good things, but not played with it much personally. hopefully someone will jump in with a more helpful answer May 05 17:21:29 eglibc is pretty much a straightforward replacement for glibc. unlike uclibc it does not cut in features, but only supported archs etc. May 05 17:23:14 mickey: I need ARM9 and x86 support. Is it smaller by much? Any good reasons to switch? May 05 17:23:54 hardly any smaller, the folks who work on it care a bit more about arm than mainline May 05 17:24:01 ask khem for details May 05 17:24:17 all i can say is that I'm quite happy with it May 05 17:24:20 bbl May 05 18:10:24 Quick question: Is there any reason that update-alts seems to run a LOT later in the boot process then they did (say 3 months ago) leading to scripts running on the 1st boot that have missing tools. This is esp. bad if your using non-Busybox tools. May 05 18:19:13 git log? :) May 05 18:21:07 kergoth_: I checked but dammed if I could find anything that looked like it was the cause ;-). May 05 18:21:24 hmm May 05 18:22:37 well, in general, postinst scripts are attempted to run at image creation time, and if that fails (or they notice they're being run at build time and exit non-zero that way), they get run on first boot by opkg's startup script. the package gets flagged as unconfigured, then opkg is run to configure them. see recipes/opkg/files/configure May 05 18:22:50 so perhaps a git log in recipes/opkg May 05 18:24:23 kergoth_: ahhh, I forgot to look there, that would make sense. I doubt they can run at image creation time as Busybox symlinks will already be there (for things like sleep etc.). Thanks for the clue. May 05 18:24:45 np May 05 18:25:09 well, the whole point of update-alternatives is to manage those links, so that them already existing *isn't* a problem May 05 18:25:12 :) May 05 18:25:43 And update-alts-native should deal with that at creation time correctly? May 05 18:26:21 that's the entire purpose of it. If it's instructed to create a link to something, and this new something has a higher priority than the existing one, it replaces it with a linking pointing at the new thing, otherwise its a no-op May 05 18:26:41 er, s/linking/link/ :) May 05 18:28:09 RP: thoughts on renaming packaged-staging after making it default? conceptually, it does more than what its name implies. in addition, i think its clearer to say it implements package-managed staging, rather than packaged-staging, though the latter is true too, it doesn't imply what's *done* with those packages May 05 18:30:02 re May 05 18:53:18 greetings! anyone here used a AT91SAM9G20-EK ? May 05 18:53:58 why? May 05 18:54:54 I'm bringing it up for the first time, and when I connect via usb (so I can run sam-ba) nothing appears in dmesg May 05 18:55:37 I have the at91sam9261-ek and that one shows up fine when I connect via usb May 05 18:56:09 What do you mean by "nothing appears in dmesg"? May 05 18:56:35 literally nothing happens, it's as if I didn't connect anything May 05 18:57:05 So you're just seeing nothing on the console? May 05 18:57:34 * broonie has only ever used the board with the serial port. May 05 18:58:18 ah great, maybe I'm missing something then, my understanding is that you have to use their sam-ba tool over usb to flash the board May 05 18:58:34 how do you get your u-boot/uImage/rootfs on your board? May 05 18:59:05 linux4sam.org is down which doesn't help... :( May 05 18:59:33 Oh, right. I flashed it on using their tool yes. May 05 18:59:51 There is a bug with the board which requires a workaround that escapes me immediately... May 05 19:00:02 a-ha! May 05 19:00:19 much appreciated, I'll google around for it, thanks! May 05 19:00:47 http://support.atmel.no/bin/customer?action=viewKbEntry&id=699 might be it. May 05 19:00:48 * oneshel wonders why they don't just use a serial port, rather than USB->serial May 05 19:01:57 hmmm, that FAQ suggests that the usb->serial connection has been established, I can't even get that far May 05 19:02:53 Also check your jumpers and so on. I don't recall any usb-serial stuff but I was just following the instructions they gave. May 05 19:03:14 yes there could definitely be a jumper that needs changing May 05 19:03:48 hmm, the python-cheetah depends need work May 05 19:04:10 needs a RDEPEND on python-netserver May 05 19:04:31 and for completeness I suspect a DEPENDS on python itself? May 05 19:04:36 does that sound right? May 05 19:07:40 broonie: do either of the solutions here sound like what you did? http://support.atmel.no/bin/customer?action=viewKbEntry&id=717 May 05 19:08:06 ah nuts, that's not it, I have rev. c May 05 19:09:53 mickey|sports, ping May 05 19:13:28 anyone know if there is a good atmel/at91 channel? May 05 19:20:58 grr.. fixing pysh isn't as simple as I'd hoped May 05 19:27:29 I'm compiling mono in oe and it mostly works but there is an issue with mono-mcs-intermediate. do_install() is in mono-mcs-intermediate.inc but it does not seem to work as when I look in the run.do_install.xxxx the do_install() there is just blank (:) and not what was in the .inc file. May 05 19:27:53 If I manually run the code in do_install() then everything works fine. May 05 19:27:54 did it define that do_install before inheriting a class? May 05 19:28:00 inherit occurs immediately, at that point in the recipe May 05 19:28:05 so the class can override things May 05 19:28:14 * kergoth_ thinks we need to fix that May 05 19:28:53 kergoth_: the only inherit is inherit native and the do_install() is set after the inherit. May 05 19:29:28 well, dunno what to tell you. it wasn't destroyed by the ether, something was parsed that overwrote it, or there was an override version May 05 19:30:22 kergoth_: weird as the mono recipes worked fine in an older version of OE but not the latest. Is there some issue with calling oe_runmake from do_install? May 05 19:30:37 ? May 05 19:30:48 if the do_install is :, something overwrote it, and it never got to run oe_runmake May 05 19:30:51 so no, thats irrelevent May 05 19:31:24 kergoth_: I thought that, I'm just running out of ideas. May 05 19:33:00 broonie: success! I had to open J33 and J34, I found the relevant linux4sam.org wiki page in the google cache May 05 19:34:01 kergoth_: it does also inherit autotools but again before the do_install. I'm also assuming that the require statements accur in the order you put them as if that is not true then the inherits could be after the do_install. May 05 19:34:06 svolpe: its a native recipe. natives generally don't use install, they stage with a prefix directly into staging. May 05 19:34:44 hello May 05 19:34:49 svolpe: see native.bbclass, the anonymous python function May 05 19:34:58 oneshel: good news May 05 19:37:06 kergoth_: so mono is being neutered :-) May 05 19:37:30 yep. it wasn't behaving itself :) May 05 19:37:41 either use do_stage or convert to new style staging, i'd say May 05 19:39:15 kergoth_: well mono uses a tar generated from the old image directory from the native package, I guess I can just re-write mono to use the native staging area to get its files instead of from the tar. May 05 19:40:21 well, new style staging uses do_install and populates staging from that, so if its safe to so so, ... May 05 19:41:28 kergoth_: just to make sure I understand: your agreeing that my suggested approach above is the correct way to do it? May 05 19:42:19 kergoth_: is there a good recipe I can look at that is doing the same type of thing? May 05 19:42:23 * kergoth_ isn't familiar enough with the mono build process to say so with any degree of confidence, but sure :) May 05 19:49:26 is there then some easy way to extract files for a specific package from the staging area? I only need to get the files for mono-mcs-intermediate so I can include them in with the mono package. May 05 19:52:51 it sounds like the mono build is doing Bad Things May 05 19:54:37 kergoth_: here is what its doing and why: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/mono/README May 05 19:56:17 kergoth_: so its hard to overlay the files if they are mixed in with all the other staging files. May 05 20:02:44 kergoth_: is there a cleaner way to build files on the native system and overlay them onto a target system package? May 05 20:19:12 hi, I'm thinking about buying a core i7-720QM(quad core 1.6GHz) for the summer,the goal would be to be able to build an image very fast(because autorev will be set on shr and framwrokd so fetchall won't work....),how fast does it build a console-image? a kernel? or something usefull May 05 20:19:18 svolpe: my initial instinct upon hearing that is "don't do that.", but.. :) i guess mono is a special case May 05 20:23:38 GNUtoo: make sure the system has DDR3 May 05 20:23:42 ok May 05 20:23:50 it has May 05 20:23:51 GNUtoo: that makes a lot of difference May 05 20:23:59 DDR3 1066Mhz May 05 20:24:05 it's a laptop btw May 05 20:24:24 so I think the difference will be even bigger May 05 20:24:26 GNUtoo: on an oldish T61 with Core2 duo I can build a minimal/console-image in less than 3 hrs May 05 20:24:31 ugh May 05 20:24:48 laptop I dont know how it will be but it certainly should be better than mine May 05 20:24:57 actually I use a pentium M @less_than_2_ghz_because_of_heat but its screen is dead May 05 20:25:07 so it works for now May 05 20:25:13 but will not work the summer May 05 20:26:12 also I fear race condition issues May 05 20:26:20 I always used 1 core/cpu May 05 20:26:40 khem, did you have a chance to take those uClibc configury hunks and make sense out of them? May 05 20:27:30 thanks a lot for the infos May 05 20:28:00 blindvt: not yet. Although I should be able to get to it soon May 05 20:28:05 I am lagging behind May 05 20:30:00 khem, that'd be awesome (I'm so swamped with work that it ain't funny. zilch time to do sparetime-stuff ATM) May 05 20:30:01 GNUtoo: I use a quad core here. No race conditions as far as I can tell. May 05 20:30:11 ok May 05 20:30:13 nice May 05 20:31:35 And with BB_NUMBER_THREADS = "12" :-) May 05 20:32:17 and PARALLEL_MAKE = "-j 4" May 05 20:36:54 ok May 05 20:46:38 03Martin Jansa  07org.openembedded.dev * r62b12a8c47 10openembedded.git/recipes/navit/navit_svn.bb: navit: bump SRCREV for improved bookmarks support May 05 20:57:52 03Koen Kooi  07org.openembedded.dev * rcf55ad281a 10openembedded.git/recipes/angstrom/angstrom-version.bb: angstrom: add TARGET_SYS to /etc/angstrom-version May 05 21:50:23 wb XorA May 05 21:50:32 hey ant__ May 05 21:56:00 hey ant__ how is it going ? May 05 21:56:16 hey May 05 21:56:46 I'd like to build again and check *libc sizes (without -ggdb3) May 05 21:57:19 btw, if uclibc, must be uclibc-nptl, isn't? May 05 22:05:11 ant__: nptl got merged into master May 05 22:05:27 right now I have uclibc_git recipes for nptl May 05 22:05:35 atleat works on ARM May 05 22:05:44 great May 05 22:05:58 we have to sort out threading story once .9.32 releases with nptl and lt together May 05 22:10:35 03Andrea Adami  07org.openembedded.dev * r0b956513d4 10openembedded.git/recipes/kexecboot/linux-kexecboot-2.6.33+2.6.34-rc4/ (6 files in 6 dirs): May 05 22:10:35 linux-kexecboot: further editings for Zaurus defconfigs. May 05 22:10:35 * add FAT/VFAT support May 05 22:10:35 * remove unused sysfs and tmpfs May 05 22:10:35 * add KEYBOARD_GPIO for clamshells May 05 22:10:35 * this kernels won't work with udev...too many missing options. May 05 22:10:35 * collie, poodle and tosa probably still broken with vanilla sources May 05 23:34:59 03Richard Purdie  07org.openembedded.dev * r6ccaf4b86c 10openembedded.git/classes/ (base.bbclass staging.bbclass): May 05 23:34:59 base.bbclass: Stage etc directory for native packages and add a use_do_install_for_stage special staging hint (from poky) May 05 23:34:59 Signed-off-by: Richard Purdie May 05 23:35:01 03Richard Purdie  07org.openembedded.dev * r3fb59642b2 10openembedded.git/recipes/gcc/gcc-package-cross.inc: May 05 23:35:01 gcc-pacpake-cross.inc: Clean up do_install function massively (from Poky) May 05 23:35:01 Signed-off-by: Richard Purdie May 05 23:35:02 03Richard Purdie  07org.openembedded.dev * r4194eae293 10openembedded.git/classes/base.bbclass: May 05 23:35:02 base.bbclass: Remove pointless data expand call (from Poky) May 05 23:35:02 Signed-off-by: Richard Purdie May 05 23:35:03 03Richard Purdie  07org.openembedded.dev * r1693ecdcd0 10openembedded.git/ (classes/cross.bbclass recipes/gcc/gcc-cross.inc): May 05 23:35:03 cross.bbclass: Move target_ variable definitions from gcc recipes to main class. Cross recipes need these in general (from Poky) May 05 23:35:04 Signed-off-by: Richard Purdie May 05 23:35:05 03Richard Purdie  07org.openembedded.dev * reb5a0f5a54 10openembedded.git/recipes/glibc/glibc-stage.inc: May 05 23:35:05 glibc: Remove now unneeded legacy staging function (from Poky) May 05 23:35:07 Signed-off-by: Richard Purdie May 05 23:35:08 03Richard Purdie  07org.openembedded.dev * r851eb471cc 10openembedded.git/recipes/gcc/ (3 files): May 05 23:35:08 gcc-cross: Convert to remove legacy staging functions May 05 23:35:08 Signed-off-by: Richard Purdie May 05 23:35:08 03Richard Purdie  07org.openembedded.dev * ra3d29c0211 10openembedded.git/recipes/binutils/binutils.inc: May 05 23:35:29 03Richard Purdie  07org.openembedded.dev * r49f0153a05 10openembedded.git/recipes/gcc/ (14 files): May 05 23:35:39 gcc-cross-sdk: Use NATIVEDEPS and drop unneeded DEPENDS May 05 23:35:40 Signed-off-by: Richard Purdie May 05 23:35:40 03Richard Purdie  07org.openembedded.dev * rd7eff9aaf5 10openembedded.git/recipes/gcc/ (gcc-cross.inc gcc-cross4.inc): May 05 23:35:40 gcc-cross: Use NATIVEDEPS May 05 23:35:40 Signed-off-by: Richard Purdie May 05 23:35:41 03Richard Purdie  07org.openembedded.dev * r24ef72d610 10openembedded.git/recipes/gcc/gcc-configure-cross.inc: May 05 23:35:41 gcc-configure-cross.inc: The install function is used, stage is no longer required May 05 23:35:42 Signed-off-by: Richard Purdie May 05 23:35:42 03Joshua Lock  07org.openembedded.dev * r692f64df9a 10openembedded.git/classes/packaged-staging.bbclass: May 05 23:35:43 packaged-staging: Fix mkdir to actually create destination May 05 23:35:43 Patch from Poky fixes fallout from recent packaged-staging fix for cross May 05 23:35:44 packages. May 05 23:35:45 Signed-off-by: Joshua Lock May 05 23:35:45 03Joshua Lock  07org.openembedded.dev * r3440328ac1 10openembedded.git/ (classes/packaged-staging.bbclass conf/bitbake.conf): (log message trimmed) May 05 23:35:46 packaged-staging: enhancements from Poky for fetching and relocatability May 05 23:35:46 Firstly adds tooling from Poky to scan packages and fix up paths in libtool May 05 23:35:47 files, we then build on this to further post-process native packages (native, May 05 23:35:47 cross, sdk) and fix up any references to the STAGING_DIR in non-binary files. May 05 23:36:12 03Joshua Lock  07org.openembedded.dev * r1b9f9a1625 10openembedded.git/classes/autotools.bbclass: May 05 23:36:12 autotools.bbclass: merge recent changes from Poky May 05 23:36:12 Includes an important change to the prepackage_lamangler method which changes May 05 23:36:12 which directories we fix la files in to operate with the new directory layout. May 05 23:36:13 Signed-off-by: Joshua Lock May 05 23:36:13 03Joshua Lock  07org.openembedded.dev * r4806fcf56c 10openembedded.git/classes/packaged-staging.bbclass: May 05 23:36:14 packaged-staging.bbclass: Remove hardcoded paths in binconfig files for target packages May 05 23:36:14 Amend the default PSTAGE_SCAN_CMD, as used when scanning target packages, to May 05 23:36:15 include binconfig scripts in the results and remove their hardcoded paths. May 05 23:36:15 Signed-off-by: Joshua Lock May 05 23:36:16 03Richard Purdie  07org.openembedded.dev * r3634cec953 10openembedded.git/recipes/aspell/aspell_0.60.6.bb: May 05 23:36:25 aspell: This package requires gettext so inherit the class May 05 23:36:26 Signed-off-by: Richard Purdie May 05 23:36:26 03Richard Purdie  07org.openembedded.dev * re01f928266 10openembedded.git/classes/gconf.bbclass: May 05 23:36:26 gconf.bbclass: Sync with Poky May 05 23:36:26 * Only add the postinstall script header if an existing postinstall isn't set May 05 23:36:26 * Remove the unneeded python import May 05 23:36:27 * Fix the indentation in the postinstall function May 05 23:36:27 Signed-off-by: Richard Purdie May 05 23:36:28 03Richard Purdie  07org.openembedded.dev * recbeeacf12 10openembedded.git/recipes/gcc/ (44 files): May 05 23:36:28 gcc: Simplfy some require statements May 05 23:36:29 (28 lines omitted) May 05 23:36:29 03Richard Purdie  07org.openembedded.dev * rd80c2eb371 10openembedded.git/recipes/module-init-tools/ (module-init-tools-cross_3.2.2.bb module-init-tools.inc): May 05 23:36:45 module-init-tools: Convert from legacy staging function (from Poky) May 05 23:36:45 Signed-off-by: Richard Purdie May 05 23:36:45 03Richard Purdie  07org.openembedded.dev * r728b0b740e 10openembedded.git/recipes/flex/flex.inc: May 05 23:36:45 flex: This package requires gettext so inherit the class May 05 23:36:45 Signed-off-by: Richard Purdie May 05 23:36:53 omg! May 05 23:38:11 thats a branch merge I guess May 05 23:43:48 Indeed it was :) May 05 23:44:06 RP: I did not see eglibc May 05 23:44:09 patch May 05 23:44:37 RP: better start using eglibc as your primary libc in poky May 05 23:44:51 khem: with what reasoning? May 05 23:44:52 RP: now that 2.12 will be out I will test and move to 2.12 soon May 05 23:45:01 RP: oh there are many May 05 23:45:11 it can compile with -Os :) May 05 23:45:13 khem: I will get asked which is why I'm asking :) May 05 23:45:40 secondly it has support for non desktop arches like e500 May 05 23:45:42 khem: I don't think I updated eglibc in this patchset - any help there would be appreciated May 05 23:46:03 RP: what you did for glibc should be done for eglibc too May 05 23:46:22 RP: there are patches to make it configurable like uclibc May 05 23:46:30 khem: legacy staging removal then May 05 23:46:34 I havent configured eglibc to do that yet May 05 23:47:26 eglibc tries to be cross compilable and cross testable so there are bunch of fixes that went in May 05 23:47:49 khem: which licence is eglibc under? May 05 23:47:54 same as glibc May 05 23:48:13 and its uptodate with upstream glibc on daily bases May 05 23:48:17 khem: so GPLv3? May 05 23:48:23 no May 05 23:48:34 glibc is LGPL 2.1 AFAIK May 05 23:48:45 unless something happened in last few weeks May 05 23:49:08 er, right, LGPL. hmm May 05 23:50:06 so there are advantages of using it May 05 23:50:40 khem: yes, I can see that. I need to discuss that with others re using it in Poky May 05 23:50:41 oh once cross-localedef is configured then you dont need qemu to generate locales May 05 23:51:01 so two items I have re eglibc May 05 23:51:11 1. Get the locales building in cross env May 05 23:51:19 2. Get the config stuff May 05 23:51:23 working in OE May 05 23:51:40 That sounds good, particularly the locales May 05 23:51:51 khem: Why isn't glibc taking these things? May 05 23:52:24 drepper doesnt accept glibc to be meant for embedded devices May 05 23:52:42 numerous times patches that were for embedded use were rejected May 05 23:53:09 khem: right. This is sad :( May 05 23:53:15 but not surprising May 05 23:53:47 so eglibc tracks glibc to fullest plus takes care of needs of embedded and non-desktop CPUs May 05 23:53:48 The patches for glibc look trivial to apply to eglibc... May 05 23:54:01 but its late here, maybe tomorrow... May 05 23:54:14 RP: ok May 05 23:54:26 RP: so now your branch is merged fully ? May 05 23:54:32 khem: yes May 05 23:54:34 can we start testing ? May 05 23:54:39 oh boy May 05 23:54:40 * Tartarus pulls May 05 23:54:43 khem: yes May 05 23:54:52 or is there something left we should wait for ? May 05 23:54:54 Tartarus: your DISTRO=minimal thing was trivial at least May 05 23:55:01 RP: saw, thanks May 05 23:55:01 khem: no, I have nothing queued now May 05 23:55:06 cool May 05 23:55:21 khem: There are other things brewing in Poky but nothing ready yet May 05 23:55:50 Like the gcc-runtime thing - I've a lot of complaints about that :/ May 05 23:56:22 (source bitbake.rc ; for MACH in mpc8315e-rdb qemux86 db1200 calamari qemumips qemuarm; do MACHINE=$MACH DISTRO=minimal bitbake minimal-image;done) > minimal-image.log 2>&1 ; ( source bitbake.rc ; for MACH in qemux86 qemumips qemuarm; do MACHINE=$MACH DISTRO=minimal bitbake x11-image ;done) > x11-image.log 2>&1 May 05 23:56:23 kicked :) May 05 23:56:47 Tartarus: should be fun :) May 05 23:57:01 Uneventfull I hope :) May 05 23:57:03 Worked pre merge May 05 23:57:12 Tartarus: I can but hope :) May 05 23:57:30 yay for 'F' in less May 06 00:01:21 Tartarus: you must be having a large HD May 06 00:04:43 Yes May 06 00:04:50 2.something TB May 06 00:05:53 Tartarus, is serious about OE :) May 06 00:06:46 yes ;) May 06 00:06:56 Almost a year ago now, heh, took 4x1.5TB drives May 06 00:07:17 raid1+0 with a small bit cut out for / for booting May 06 00:07:32 afk a while May 06 00:07:42 l6r May 06 00:36:39 what GUI audio players are people using on their underpowered OE devices? May 06 00:37:01 (i still use xmms on my desktop) May 06 00:37:29 is there anything touchscreen friendly? May 06 01:03:31 bash May 06 01:03:55 best thing for underpowered devices, in general. :) May 06 01:05:31 as in, use a cli player? May 06 01:05:41 not really an option for end users of my device May 06 01:06:08 ps: bash is gargantuan May 06 01:17:03 anyone around for a hardware-y question? May 06 01:17:16 trying to see if I can get gumstix to drive 2 LCDs May 06 01:17:35 I know its somewhat gumstix specific maybe but is this possible through the kernel drivers for linux? May 06 01:25:16 aditya_111, isn't there a #gumstix ? May 06 01:47:58 grg, #gumstix can be slower than here :) May 06 01:48:03 hard question May 06 02:47:00 grg: I've asked on there May 06 02:47:06 just wanted to see if you guys have some ideas too May 06 02:47:15 cause half of the problem is drivers **** ENDING LOGGING AT Thu May 06 02:59:56 2010