**** BEGIN LOGGING AT Tue Jan 19 02:59:57 2010 Jan 19 07:41:17 good morning Jan 19 08:27:06 morning Jan 19 08:42:18 Finally I managed to make it build apache2_2.2.3 instead of 2.2.14 but get some compile errors :( http://pastebin.com/m73b24f9b Jan 19 08:44:53 morning woglinde Jan 19 08:45:22 the most interesting line in that pastebin is "make[3]: dftables: Command not found" Jan 19 08:45:32 03Steffen Sledz  07org.openembedded.dev * r192d40a9c1 10openembedded.git/recipes/linux/linux-2.6.24/hipox/defconfig: Jan 19 08:45:32 linux-2.6.24: defconfig for hipox machine changed Jan 19 08:45:32 - UART3 enabled Jan 19 08:45:32 - I2C bitbash pins changed (SDA=GPIO26, SCL=GPIO25) Jan 19 08:45:32 Signed-off-by: Steffen Sledz Jan 19 08:48:07 jovox: and ./recipes/apache2/apache2-2.2.3/dftables-makefile-patch was applied? Jan 19 08:50:36 hrw, looks like it is according to the console output: NOTE: Applying patch 'dftables-makefile-patch' (apache2-2.2.3/dftables-makefile-patch) Jan 19 08:52:29 hi ant Jan 19 08:52:35 hi hrw Jan 19 08:53:17 jovox: so check what provides dftables... apache2-native? Jan 19 08:55:56 hrw, looks like it, yes. Could it be that it's building the wrong version or the apache2-native... checking Jan 19 08:59:20 thats it. It's building apache2-native 2.2.14 Jan 19 10:12:08 good morning Jan 19 10:13:13 hi florian Jan 19 10:19:10 jovox: i spent quite some time on apache, trying to get php and mysql to work with it, but in the end I moved to lighttpd. Jan 19 10:19:23 * eFfeM is a happier person since that day :-) Jan 19 10:22:31 hehe Jan 19 10:23:38 effem ;) Jan 19 10:24:05 effem you can hail me to put lighty into shape Jan 19 10:24:08 *g* Jan 19 10:30:14 * eFfeM hails woglinde Jan 19 10:30:17 :-* Jan 19 10:30:23 *g* Jan 19 10:30:32 actually i don't have a nice hail smiley in pidgin Jan 19 10:40:53 eFfeM, lighttpd with php? Jan 19 10:41:20 I had it working in the stable branch but not in the "latest" dev branch Jan 19 10:42:54 But now I'm building 2.2.3 of apache which is the same as in the stable branch so hopefully that will work Jan 19 10:43:14 btw, anyone played around with the new libspotify? Jan 19 10:43:35 downloaded it yesterday but havn't had the change to test it yet Jan 19 10:55:17 jovox: for me it worked on the dev branch, but it is probably a month ago since I last build it myself Jan 19 10:55:21 it is on the angstrom feed Jan 19 10:59:31 jovox, i am in.nl, spotify is not available here Jan 19 11:00:59 eFfeM, I think it is available in nl if someone in .se pays for it which wouldnt be too bad :-) Jan 19 11:01:33 eFfeM, the lib is x86 only anyway Jan 19 11:01:42 jovox: i know Jan 19 11:02:02 in a previous life I did similar things with other content providers Jan 19 11:02:36 the why-not-available page says i live in .nl based upon ip address and due to licensing it cannot be made available Jan 19 11:03:05 guess even if someone from se pays it would not help Jan 19 11:03:53 it's not supposed to be available in .de either but I was there last week, downloaded it and logged in with my account. Worked perfectly well Jan 19 11:04:17 wrt '86 code. guess it communicates over https or so to get the data, would require some re-engineering to find the key and analyse the protocol Jan 19 11:04:57 jovox: if you have a .se based account probably they will allow you to access everywhere since your agreement is under .se law Jan 19 11:05:40 which means it work in .nl (kind of) Jan 19 11:08:29 true Jan 19 11:10:28 who's paying you guys for working on OE? Are you doing it full time? Jan 19 11:31:08 re Jan 19 11:55:31 Hi Jan 19 11:55:42 perl-native fails with this error: http://pastebin.com/d35e3e95a Jan 19 11:55:59 Any hints on what might be wrong ? Jan 19 12:07:47 sgh: do you have make installed? Jan 19 12:08:42 eFfeM: yes, but I think that it is cause by missing coreutils..... Jan 19 12:10:02 sgh: your error is at line 161 of makedepend: Jan 19 12:10:03 $MAKE shlist || ($echo "Searching for .SH files..."; \ Jan 19 12:10:03 $echo *.SH | $tr ' ' $trnl | $egrep -v '\*' >.shlist) Jan 19 12:10:17 yes Jan 19 12:10:48 this makes shlist, if $MAKE is empty it will instead try to execute the command shlist which does not exist (and whcih then will give the error you have) Jan 19 12:11:46 eFfeM: ok ...... maybe that is the case then. Jan 19 12:12:10 for me (a few days ago) it build like a charm, so guess it is either a host issue or a missing dependency (i typically do bitbake virtual/kernel or bitbake console-image as a starter in a fresh tmp dir) Jan 19 12:12:44 sgh: add an echo or so to makedepend then rerun the compile step (this was in compile iirc) Jan 19 12:12:49 eFfeM: yes .... dependencies on basic recipes are not as good as they could be I guess. Jan 19 12:13:22 sgh: feel free to submit patches to improve :-) Jan 19 12:15:10 eFfeM: sure .... what is the *correct* commandline for submitting patches via. git-email ? Jan 19 12:15:14 a from scratch build cruncher would be good Jan 19 12:15:46 sgh: its hard to say correct one because it depends on your workflow Jan 19 12:16:36 XorA: I'm just wondering how your guys get a whole bunch of description embedded into the email. When I do it I only get the commit message :( Jan 19 12:17:26 put the description in the commit message Jan 19 12:20:06 XorA: it would be a nice QA exercise to iterate over all recipes trying to build them from scratch; so something like rm -rf tmp; bitbake package1; rm -rf tmp; bitbake package2 and do that for all packages Jan 19 12:20:12 but on my system that would take ages Jan 19 12:20:24 eFfeM, whats the relation between the apache and apache2 recipes? Jan 19 12:20:42 jovox: guess apache is for apache1, the recipe will tell you Jan 19 12:21:24 eFfeM: we neeed bigger systems :-D Jan 19 12:21:44 XorA: but maybe if you start off with a VM with the basic stuff preinstalled (e.g. all cross stuff and some native stuff) and starting with a fresh VM copy would improve things Jan 19 12:22:18 * eFfeM is still looking for someone to sponsor a 19" with quad core i7's etc Jan 19 12:22:30 eFfeM: could be done with the external toolchain support Jan 19 12:22:32 blade ofc, so I can have 20 or so Jan 19 12:22:45 XorA: never really looked at external toolchain Jan 19 12:22:57 * XorA fears an OE blade rack Jan 19 12:23:05 eFfeM: 19" as 1U/2U rack? Jan 19 12:23:25 eFfeM: it will not take ages - use packaged staging for that Jan 19 12:23:43 hrw yes as 1U Jan 19 12:24:03 hrw, not really knowledgeable about packaged staging, is there a description somewhere ? Jan 19 12:24:12 how to get that going Jan 19 12:24:18 eFfeM: moment Jan 19 12:24:51 eFfeM: http://marcin.juszkiewicz.com.pl/2008/07/01/packaged-staging-and-what-it-gives/ for example? Jan 19 12:26:26 hrw, i am using angstrom distro, and according to koen it is enabled, maybe it does not do what i want/expect it to do Jan 19 12:26:42 remember I had this problem with mythtv and then someone (you probably) also mentioned packaged staging Jan 19 12:27:13 and I see multiple package versions in both deploy and work (so if PR is bumped the old version is not gone) Jan 19 12:27:22 eFfeM: rm -rf tmp/staging tmp/stamps then do a rebuild Jan 19 12:27:23 or do I still need to do the things you mention with angstrom Jan 19 12:28:25 XorA does that take things from packaged staging ? Jan 19 12:28:35 it is possible with all the massive staging changes packaged-staging needs to catch up in some areas, but its basic property of super fast builds should still work Jan 19 12:28:50 eFfeM: deploy/pstage is always checked before building Jan 19 12:29:28 bugadmin@dauber:/opt/sandbox/hrw/trunk/build$ for recipe in ../meta-bug/packages/*/*bb;do echo $recipe; bitbake `basename $recipe .bb` && rm -rf tmp/*;mv tmp tmp-$recipe;done Jan 19 12:30:04 eFfeM: that + tmp/deploy/glibc/pstage outside of tmp (settable by DIR_DEPLOY_PSTAGE) do builds from scratch Jan 19 12:30:13 in quite short time Jan 19 12:30:33 yeah guess the DEPLOY_DIR_PSTAGE is not outside of my tmp Jan 19 12:30:45 will try tonight or tomorrow night Jan 19 12:30:59 (and bother you if I run into problems :-) Jan 19 12:31:28 mkey Jan 19 13:02:42 hi mickey|ICE627 Jan 19 13:02:54 where do you want to go today? Jan 19 13:03:57 hehe Jan 19 13:03:58 morning Jan 19 13:03:59 Munich Jan 19 13:04:11 attending a monthly openmoko user meeting Jan 19 13:04:20 ah, very good Jan 19 13:07:22 mickey|ICE627: morgen Jan 19 13:08:07 hrw: guten Morgne Jan 19 13:08:13 err, Morgen Jan 19 13:09:42 mickey|ICE627: so there are still openmoko users? Jan 19 13:10:01 for sure Jan 19 13:10:10 la resistance Jan 19 13:10:13 :) Jan 19 13:10:13 ;D Jan 19 13:10:57 and for those it's getting better almost every day Jan 19 13:10:57 hm Jan 19 13:11:06 just recently we bumped kernel speed Jan 19 13:11:10 I recently shared my debugboard for local openmoko user. he tries to help SHR on freerunner (his own) and neo1973 (mine) so he should make good use of it Jan 19 13:11:17 and this year will move the remaining fso services to C Jan 19 13:11:24 so that's for a nice speedup Jan 19 13:11:40 hrw: sounds good. i have some debug boards spare, if you need one Jan 19 13:11:42 mickey|ICE627: any commercial use of fso? Jan 19 13:11:58 mickey|ICE627: do you have v3 one? with NOR unlock option? Jan 19 13:12:12 we're currently in negotiation phase, it looks like we can probably get our first contract soon Jan 19 13:12:21 (v3), no i only have v2 ones Jan 19 13:12:47 mickey|ICE627: so far I do not need extra one, but will ask local devs Jan 19 13:13:13 mickey|ICE627: just wonder, If there's only freerunner supported or I could remove dust from my neo also :) Jan 19 13:13:42 ynezz: although i didn't test, all the work that goes into kernel and userland is supposed to benefit the 1973 as well Jan 19 13:13:50 ah, cool Jan 19 13:16:31 does anybody know whether g_slice_alloc() can return NULL? Jan 19 13:16:38 I guess probably not but it doesn't seem to be documented anywhere. Jan 19 13:18:38 I have to agree with mickey|ICE627 here. I've dusted the Freerunner off just yesterday and there's been some tremendous improvements Jan 19 13:18:48 still a bit sluggish Jan 19 13:19:00 but otherwise it's starting to look polished Jan 19 13:19:25 I think a lot of that is owed to JaMa's good work (and others I don't know) Jan 19 13:20:37 heh, if I had ever had a working FreeRunner might have been worth checking out :-) Jan 19 13:21:23 Mine still works AFAIK Jan 19 13:21:45 broonie: yeah you finally got a production one didnt you Jan 19 13:21:57 * XorA only ever got early model prototypes Jan 19 13:22:00 never had working one Jan 19 13:22:05 Yes, just before they shut down. Jan 19 13:22:22 but never wanted ;D Jan 19 13:22:30 mine doesnt even have stickers on it :-) Jan 19 13:30:09 koen around? Jan 19 13:30:27 kristoffer: koen doesn't hang out in this channel Jan 19 13:30:51 pb_, know where I can find him? Jan 19 13:30:54 kristoffer: he is on #beagle Jan 19 13:30:59 ah thx Jan 19 13:57:27 sgh, with your perl issue, what was the exact command you did (and did you build other things before) Jan 19 14:00:35 eFfeM: I did not would a whole lot. That was problably the problem. make-native was not build. Jan 19 14:01:04 i don't have make-native either Jan 19 14:01:10 and you told me you had make Jan 19 14:01:17 guess it was perhaps not in your path Jan 19 14:01:23 (when building) Jan 19 14:01:29 eFfeM: well ... not make-native I guess. Jan 19 14:01:32 from getting started: GNU extensions to tools are often required. Symlink GNU patch, make, and cp (from fileutils), chmod, sed, find, tar, awk into your OE development path. Jan 19 14:01:58 make-native does not exist on my system Jan 19 14:03:41 eFfeM: does OE use a "local" make if a such exists ? Jan 19 14:04:38 guess so Jan 19 14:05:07 i've build perl and I do not have a make in my oe tree so it must have used the native one Jan 19 14:05:15 native as in local Jan 19 14:06:23 ynezz: thx for your email Jan 19 14:07:03 make is a requirement for OE Jan 19 14:07:09 There is no distinguishing made by build scripts between a command on the local host vs a command that was staged by a -native recipe. Jan 19 14:07:12 as gcc requires make and make needs gcc to build Jan 19 14:09:17 I guess if it became apparent that some DISTRO was shipping a broken make then we would have to have a make-native, but it hasnt happened yet Jan 19 14:11:39 XorA: .... strange. I will try to build perl-native from scratch without make-nativ in its DEPENDS. Jan 19 14:14:25 sgh: you are not playing with bitbake -b ?? Jan 19 14:14:35 xora we have recipes for make-native Jan 19 14:14:51 XorA: no no ..... just bitbake perl-native Jan 19 14:15:09 eFfeM: I checked poky with doesnt, dont have a local OE Jan 19 14:16:04 * XorA will need to do some IT work tonight to setup for new contracts Jan 19 14:18:37 XorA: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/make Jan 19 14:19:02 not sure if you do a bitbake perl-native on a clean tree if it really depends on gcc etc (although ofc it uses gcc) Jan 19 14:19:13 * eFfeM is not an expert in that area Jan 19 14:19:16 afk ... Jan 19 14:19:29 looks like a good candidate for BBCLASSEXTENDS :-) Jan 19 14:23:31 ynezz: thanks for the offer to share a recipe for xinput_calibrator, first time I have seen that app, looks REALLY nice and should just push most people to EVDEV for touchscreens :). Jan 19 14:27:27 mckoan: is using EVDEV for touchscreen a viable option for you? Looking at the http://www.freedesktop.org/wiki/Software/xinput_calibrator stuff. Getting X using UDEV rules for autoconfig and that app would make a VERY nice combo for touchscreen users. Jan 19 14:28:18 DJWillis: apply the openmoko ts filtering chain and touchscreen becomes a evdev device Jan 19 14:28:29 DJWillis: as then calibration is handled in the kernel Jan 19 14:31:39 XorA: BTW, where do you see, that a calibration is done in the kernel? :) Jan 19 14:31:49 XorA: it's done in evdev xorg driver Jan 19 14:32:35 ynezz: with the filter stack originally posted calibration was written to a /sys file Jan 19 14:34:52 XorA: it's handled in the kernel then in the driver with all sorts of overlays ;), also, not very good at dealing with local vairance or touchscreen age ;). All ready using EVDEV for the Pandora's touchscreen and a crappy hackup app to get the calibration data fed in, xinput_calibrator just does it 'much nicer (tm)' ;-) Jan 19 14:36:15 ynezz: the X evdev driver reads the default calibration from the kernel IIRC and you can overlay it at runtime or static with the Calibration/SwapAxes Option flags (at least I THINK it works that way). Jan 19 14:36:59 A while ago I made some modifications to the apache2 recipe to make it use my custom httpd.conf. I don't want that a.t.m to I removed all changes I made and now building with the recipe from git. When I build apache2 (bitbake apache2) and extract the ipk everything looks good. Ie, my customized httpd.conf isn't in /etc/apache2/httpd.conf. But when building the image, bitbake console-image, it uses my httpd.conf. I have been scanning through th Jan 19 14:36:59 e entire directory structure for httpd.conf files (tmp, my overlay, and openembedded). None of the found files contains my changes. This is a bit mysterious i must say. I have cleaned the apache2 packages many times :/ Jan 19 14:38:02 jovox: you have a package with a higher version then your reset apache2 (i.e. still has your changes) so that is getting dragged into the image, check for extra ipks ;-) Jan 19 14:38:40 XorA, DJWillis: it's just a driver specific stuff I think, nothing generic Jan 19 14:39:01 XorA, DJWillis: I can't see anything about calibration in evdev code Jan 19 14:39:29 ynezz: this was not evdev code, it was ts filter stack Jan 19 14:39:30 DJWillis, when you say "check for extra ipks", what exactly do you mean then? Jan 19 14:39:41 The kernel does not export any calibration information via the input interface. Jan 19 14:39:57 XorA: ah, ts another storry :) Jan 19 14:41:03 the filter stack was a nice idea, but never really gained traction Jan 19 14:41:32 It looked like it might go in last time it was posted. Jan 19 14:41:36 DJWillis: on bug I have 2 touchscreens now but evdev is unable to track them Jan 19 14:41:45 ynezz: that may be true, either way, 2.3.*> of evdev support runtime and static calibration of the TS so it's rather moot as that can be used with xinput_calibrator and it looks like all should be good (well, hmm, ok, maybe not but you get the idea). Jan 19 14:42:33 hrw: ahh, never tried 2 screens, how does xinput-tslib deal with them, I would have assumed as long as both had core pointers and prams set it 'should' have worked. Jan 19 14:43:12 morning Jan 19 14:43:15 DJWillis: one is set as corepointer, each tslib instance has said which screen it uses Jan 19 14:43:43 jovox: you will have a stray apache2 package in your tmp somewhere that is getting dragged in as it has a higher version than your current recipe (at a guess). Jan 19 14:44:04 kergoth: you turn up just as the debate turns to touchscreens ;-) Jan 19 14:44:13 * kergoth runs away Jan 19 14:44:22 DJWillis, ok, I'll scan the tmp then Jan 19 14:44:45 hrw: ahhh. What happens if one is EVDEV and one is TSLIB out of interest? Jan 19 14:44:45 DJWillis: the problem is, that xorg evdev driver can't handle hiddev touchscreens... Jan 19 14:45:15 DJWillis: so it's a mess anyway Jan 19 14:45:44 ynezz: ahhh, now that makes some more sense. Did not know that (never looked very hard, it supported everything I chucked at it). Jan 19 14:48:16 DJWillis: did not tried such combo Jan 19 14:51:58 DJWillis, ynezz: however would be nice to try xinput_calibrator with OE Jan 19 14:52:41 damn.. tinderbox.openembedded.org is .. pretty Jan 19 14:52:44 * kergoth hadn't looked at it in ages Jan 19 14:52:45 probably the 'perfect' solution (if exist) could be something completely new Jan 19 14:53:04 mckoan: ynezz: if you have said recipe i'll take it out for a spin in place of my crappy hackup code on the Pandora as an X calibration app. Jan 19 14:54:13 * DJWillis considers taking his box out of Tinderbox as a lot of fails are recipes he is working on :-o. Jan 19 14:54:15 I have recipe for older version, with gtkmm Jan 19 14:54:30 tias has made some work on it and rewrote it to pure Xorg code Jan 19 14:54:48 ynezz: care to send it over? Should make a decent starting point. Jan 19 14:55:07 I'll be home in ~3hrs or so Jan 19 14:55:11 ynezz: yes I saw tias version Jan 19 14:55:48 ynezz: ok, I'll switch to another task then Jan 19 14:56:01 If we make the new bitbake require python 2.5 is that going to be a problem? Jan 19 14:56:16 ynezz: grand :), about the same as me. It would be nice to get something semi-generic in place to help with the current soup. Jan 19 14:56:42 RP: I thought it did? Jan 19 14:56:56 RP: it will with any Lenny based system Jan 19 14:57:39 RP: are you thinking for 1.10? Jan 19 14:57:45 kergoth: yes Jan 19 14:57:51 2.5 seems reasonable for 1.10, stick to 2.4 or 1.8, and 2.6+ for master Jan 19 14:57:52 imo Jan 19 14:57:57 s/or/for/ Jan 19 14:58:02 * kergoth hasn't had enough caffeine yet Jan 19 14:58:14 kergoth: master can go 2.5 with 2.6 required for the xmlrpc mode Jan 19 14:58:19 * mckoan -> bbl Jan 19 14:58:38 This would be nasty... I use Lenny for all the build servers. Jan 19 14:58:42 sounds good to me. i don't think many current distros are still on 2.4, but we may want to double check that Jan 19 14:58:43 ah Jan 19 14:59:05 * kergoth thinks it would be nice to keep virtual machines of all the major distro releases on hand somewhere .. he should really do that on one of his machines Jan 19 14:59:28 you don't need virtual machine, just some chroot bz2 Jan 19 14:59:30 kergoth: the current Ubuntu LTS is also 2.4 for Python and adding 2.6 is painful. Jan 19 14:59:33 kergoth: there is a site with virtualbox images for all distros commonly in use Jan 19 14:59:50 XorA: cool, i'll check for that. thanks Jan 19 14:59:57 ok, I started a beagleboard-demo-image build :) Jan 19 15:00:01 florian: can you do me a favour then and see if bitbake master actually works on python 2.4 ? (removing the version check for 2.6) Jan 19 15:00:05 kergoth: Im just trying to refind it for you Jan 19 15:00:49 it's crazy to compile OE in virtualbox, isn't it? Jan 19 15:00:58 could be 2.5x or more slower Jan 19 15:01:10 DJWillis: I thought LTS had 2.5 by now for Ubuntu? :/ Jan 19 15:01:21 RP: Forget what we said... my Lenny has 2.5. Jan 19 15:01:36 kergoth: virtualbox.wordpress.com/ Jan 19 15:01:46 ynezz: trying to build it Jan 19 15:01:50 XorA: ah, sweet, thanks Jan 19 15:01:56 * kergoth bookmarks Jan 19 15:02:09 hrw: what are you trying to build? Jan 19 15:02:53 xinput-calibrator Jan 19 15:03:10 RP: You may be right, I was sure it was 2.4.* but it may well infact be 2.5. Jan 19 15:03:28 RP: just checked, HardyLTS is 2.5.2, sorry for the noise. Jan 19 15:03:30 hrw: ok, are you autotoolizing it? Jan 19 15:03:55 RP: It might be possible that it defaults to 2.4 but 2.5 is available for Lenny. But I will try if I find a machine that has 2.4 here. Jan 19 15:03:59 only really CentOS/RHEL guys get hit with python 2.5 requirement Jan 19 15:04:16 no Jan 19 15:04:28 XorA: looks like http://www.thoughtpolice.co.uk/vmware/ has a decent selection too on the vmware end of things Jan 19 15:04:32 florian: If its commonly available I'm less worried about just going to 2.5... Jan 19 15:04:39 XorA: Those people enjoy pain anyway ;-) Jan 19 15:04:48 RP: we do thats true :_D Jan 19 15:05:27 hehe Jan 19 15:05:46 althugh I have python 2.5 RPM for those systems Jan 19 15:06:13 as trac python 2.5 is pretty much compulsary Jan 19 15:11:02 * Laibsch has python 2.5 on his hardy machine Jan 19 15:13:05 ynezz: xinput_calibrator: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped Jan 19 15:14:21 hrw: ok, I have it also, DJWillis and mckoan are interested in recipe Jan 19 15:14:45 I can push mine and then you add your fixes? Jan 19 15:15:05 no problem, but I've autotoolized version... Jan 19 15:15:27 and for 0.40 so I would need to update it to 0.50 Jan 19 15:15:40 ah Jan 19 15:15:44 more magic Jan 19 15:16:34 yes, but I plan to send it back to Tias, so he can merge Jan 19 15:16:45 and everybody can make a profit from this Jan 19 15:17:38 ynezz: sounds very good Jan 19 15:18:28 ynezz: for x11 version http://hrw.pastebin.ca/1757518 was enough Jan 19 15:22:06 eFfeM: "rm -rf tmp ; bitbake perl-native" work fine .... so I guess there must have been something wrong with tmp. Jan 19 15:22:48 sgh, great Jan 19 15:23:10 eFfeM: yes ... :) Jan 19 15:23:24 sgh in case of strange build errors rm -rf tmp is often a good option (especially if you are fiddling with the tree for quite a while) Jan 19 15:24:05 hrw: why not push and ynezz can overlay later with more patches Jan 19 15:24:29 I will Jan 19 15:24:52 rebuilding latest ver of recipe now Jan 19 15:25:22 hrw: yes, it's easy, autotools is just few lines more, but it's almost same Jan 19 15:27:19 ynezz: you cover gtkmm too? Jan 19 15:28:02 in the older version it was only gtkmm Jan 19 15:29:00 ok Jan 19 15:37:05 03Marcin Juszkiewicz  07org.openembedded.dev * rb28038e813 10openembedded.git/recipes/xinput-calibrator/ (2 files in 2 dirs): Jan 19 15:37:05 xinput-calibrator: added 0.5.0 Jan 19 15:37:05 This is tool to calibrate touchscreens which works as XInput devices Jan 19 15:37:06 (evdev, evtouch, ... but not tslib one). Jan 19 15:37:08 So far only X11 version, GTKmm one will be provided later by Petr Štetiar. Jan 19 15:37:47 ynezz: fine with it? Jan 19 15:43:09 eFfeM, Did you have todo anything special to get apache + php work? I just get "Segmentation fault (11)" in /var/apache/log/error_log Jan 19 15:44:20 jovox, i never got apache with php working, that's why i switched to lighty, (and I did spend quite some time on it) Jan 19 15:44:37 your best chance is probably invoking php over cig Jan 19 15:44:38 cgi Jan 19 15:48:30 hmm sad to hear.. as I had it running in the stable branch Jan 19 15:49:30 and switched over to the dev branch to get a newer kernel :/ Jan 19 15:53:12 Warning: multiple calibratable devices found, calibrating last one (ts5) Jan 19 15:53:13 X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 144 (XInputExtension) Jan 19 15:53:16 :( Jan 19 15:55:17 eFfeM, what's needed to get lighty running php? Jan 19 15:58:35 hrw: ts5 is correct device? Jan 19 15:58:44 ynezz: yes Jan 19 15:59:05 ynezz: it is /dev/input/lcd_bmi_ts5 which is named 'ts5' in xorg.conf Jan 19 16:04:56 hrw: hm, I made some patches http://www.mail-archive.com/xorg@lists.freedesktop.org/msg09732.html because it selected my mouse for calibration, but your device is correct so it seems like other problem Jan 19 16:05:20 hrw: maybe you can create issue on his github page, seems he's using it Jan 19 16:05:22 eFfeM, you just installed lighttpd and php and configured lighttpd? Jan 19 16:05:24 I have older evdev probably Jan 19 16:06:42 maybe, but it would be sane to write something about incompatible version instead of this cryptic error and if he don't know about this, he can't fix it... Jan 19 16:07:07 afk Jan 19 16:07:36 sure Jan 19 16:12:45 ynezz: added both Jan 19 16:14:12 i wonder.. Jan 19 16:14:13 hmm Jan 19 16:14:48 another random idea for my list: postpone actual package generation until image population time, and only generate the ones we want for the image? Jan 19 16:14:59 (a crapload of rpmbuilds takes a looooong time) Jan 19 16:15:05 yeah, that's not a bad idea Jan 19 16:15:20 that'd help a bit with glibc and all the locale packages too Jan 19 16:15:48 yeah Jan 19 16:15:54 obviously not so great if you want to make a feed, but it'd definitely work for people who have O_P_M turned off. Jan 19 16:16:15 probably wouldn't be terribly difficult to implement, either, leverage pkgdata or store the bits in the persistant datastore Jan 19 16:16:24 * florian notices that pb_ types faster than florian Jan 19 16:16:29 * kergoth chuckles Jan 19 16:16:36 heh Jan 19 16:17:54 but will it work for "bitbake console-image;bitbake x11-image"? Jan 19 16:17:55 hm, it would actually be a step in the previously discussed direction wrt separation of responsibilities Jan 19 16:18:18 i don't see any reason why not. the image could leverage the persistant data to construct what it needs when it needs it Jan 19 16:19:57 would have to emit more info to pull it off, though. needs more thought. Jan 19 16:20:00 * kergoth adds to the list Jan 19 16:26:00 * mckoan -> re Jan 19 16:27:00 RP: my Lenny has Python 2.5.2 ;-) Jan 19 16:33:38 mckoan: xinput-calibrator is in OE - try it Jan 19 16:34:08 * kergoth tries breaking up his list into: general ideas / architecture, use cases, usability issues, cleanup tasks, enhancements (need further discussion), bugz, and long term goals & direction Jan 19 16:41:27 hmmm Jan 19 16:41:39 * kergoth thinks about ways to leverage ${B} vs ${S} in a semi-automated way Jan 19 16:47:48 hi Jan 19 16:48:31 i am having trouble building my toolchain with oe (i thought i know how to do that :-) Jan 19 16:48:43 anyone willing to listen? Jan 19 16:49:10 thats just asking for people to put fingers in ears and go lalalala Jan 19 16:49:17 allright Jan 19 16:49:21 so let's go ;-) Jan 19 16:49:24 but we always listen normally Jan 19 16:49:44 I am building a 2 month old oe.dev Jan 19 16:49:52 for imx31 Jan 19 16:50:26 now when it comes to building glibc or eglibc I get: Jan 19 16:50:34 configure: error: working compiler support for visibility attribute is required Jan 19 16:50:44 in log.do_configure Jan 19 16:51:04 you are using which distro/machine combo? Jan 19 16:51:05 that's for gcc 4.4.1 Jan 19 16:51:17 and also gcc 3.4.3 Jan 19 16:51:23 ang glibc 2.6.1 Jan 19 16:51:28 but not for 4.3.3? Jan 19 16:51:32 and eglibc 2.10 Jan 19 16:51:37 i didn't try Jan 19 16:51:40 should I? Jan 19 16:51:41 or 4.1.2 or 4.2.4? Jan 19 16:51:54 I setup my own distro and machine files Jan 19 16:52:05 I used 4.1.2, 4.2.4, 4.3.3 for our i.mx31 device Jan 19 16:52:35 with angstrom and poky Jan 19 16:52:38 I'll give 4.3.3 a try Jan 19 16:52:55 but shouldn't all the oe compilers have visibility support? Jan 19 16:53:09 I kind of expec switching gcc to not lead anywhere Jan 19 16:53:40 4.4. is the default for sane-toolchain Jan 19 16:53:48 and 4.3.4 the default for arm Jan 19 16:53:59 ah, that error is kicked out for more than just visibility support failing, you have to analise config.log Jan 19 16:54:19 thanks. that's a pointer Jan 19 16:54:26 that will give the real reason for failure Jan 19 16:55:01 * XorA had to google it to jog memory Jan 19 16:56:38 * XorA thinks for toolchains we should have a method better than MACHINE="blah" Jan 19 16:58:35 hrw: glad to see that the work that drive me to xinput-calibrator has been useful, I'm going to test it in OE Jan 19 17:01:58 yep mckoan Jan 19 17:03:07 hrw, ynezz: thx for creating and pushing xinput-calibrator recipe ;-) Jan 19 17:08:33 XorA: thanks for your help Jan 19 17:08:43 it was a missmatch in compiler switches Jan 19 17:09:20 gcc didn't like to get both -mcpu and -march swiches on the command line Jan 19 17:09:45 i'll see if leaving -march out works Jan 19 17:10:34 it worked Jan 19 17:11:27 Hi all! I want to use the openembedded logo in a presentation. Is there any responsible person availible? Jan 19 17:12:14 hi Frighty Jan 19 17:21:30 xinput_calibrator starts good, but fails Jan 19 17:21:42 Calibrating EVDEV driver for "atmel-ts" Jan 19 17:21:42 terminate called after throwing an instance of 'std::runtime_error' what(): Unable to open 9x15 font Jan 19 17:21:44 Aborted Jan 19 17:22:04 I'll play a bit with it Jan 19 17:25:06 have a nice rest of the day Jan 19 17:43:45 gm all Jan 19 18:12:19 hrw, mckoan|away, DJWillis: http://github.com/ynezz/xinput_calibrator/commit/754d23d7b043b2d3a5b70f9a15c3054296b7892a Jan 19 18:13:01 awesome Jan 19 18:13:20 just checking oe recipe, will send patch later Jan 19 18:13:27 rebuilding cache :( Jan 19 18:14:03 ynezz: you have r/w access? Jan 19 18:26:45 * hrw off Jan 19 18:39:36 hrw|gone: patch sent to mailing list Jan 19 18:39:56 hrw|gone: if you mean r/w access to oe, no Jan 19 18:43:01 hrw|gone: do you have an idea how to enable gtkmm version of it? make another package? Jan 19 18:58:47 ynezz: just make a metapackage and -x11 and -gtkmm? Jan 19 18:59:44 When doing bitbake makedevs-native, why does it not find makedevs when doing bitbake .....-image (target image) It is there in the staging area but just not found.... Jan 19 19:30:40 RP: think i asked before, but i can't remember if you responded or not .. do we have any documentation on the xml/rpc interfaces, yet, for 3rd party UIs to use? Jan 19 20:06:46 03Khem Raj  07org.openembedded.dev * r487479374e 10openembedded.git/recipes/ (4 files in 4 dirs): (log message trimmed) Jan 19 20:06:46 libqpe, opie-taskbar: Fix linking errors found with 2.20 ld Jan 19 20:06:46 * Fix PR #5376 Jan 19 20:06:46 * Dont remove ~LnkProperties when QTOPIA_INTERNAL_FSLP is not defined Jan 19 20:06:46 this could cause g++ to emit default destructor which will be inlined Jan 19 20:06:48 and as we asked inlines to have hidden visibility it could make the Jan 19 20:06:50 destructor hidden in the final library this happens now because ld Jan 19 20:13:14 2.6.31 falls belly up when booting qemuarm Jan 19 20:13:36 anyone succeeded with some non rp kernel ? Jan 19 20:14:17 probably I should look into patches if any makes sense for forward port Jan 19 20:14:19 03Chris Larson  07org.openembedded.dev * r0788436f2d 10openembedded.git/classes/package_dbg.bbclass: Jan 19 20:14:19 package_dbg.bbclass: add current incarnation from MVL6 Jan 19 20:14:19 This optional bbclass implements per-subpackage debug packages. Among other Jan 19 20:14:19 things, this makes it much easier to automate creation of debug images (where Jan 19 20:14:19 you have the debug files for all installed packages). Jan 19 20:14:23 Signed-off-by: Chris Larson Jan 19 20:27:37 Hi all! I want to use the openembedded logo in a presentation. Who has the rights to authorize this issue? Jan 19 20:27:58 khem: let me know about your qemuarm successes Jan 19 20:28:07 Frighty: may be e.V Jan 19 20:28:09 I think qemuarm is underutilized in OE Jan 19 20:28:15 Laibsch: yes it is Jan 19 20:28:30 I'm very interested in improving the experience Jan 19 20:28:38 Laibsch: I found qemu quite a tool to debug system libraries Jan 19 20:28:44 although I think I was able to boot a console image Jan 19 20:28:54 Laibsch: I will use same to debug kernel now and see why it falls flat :) Jan 19 20:35:35 03Chris Larson  07org.openembedded.dev * r73bf228927 10openembedded.git/conf/amend-recipes.inc: Jan 19 20:35:35 amend-recipes.inc: Add. Allows tweaks to be amended to a recipe via a .inc in its FILESPATH Jan 19 20:35:35 Signed-off-by: Chris Larson Jan 19 20:39:37 Frighty, it is OK to use it in presentations Jan 19 21:06:06 03Stanislav Brabec  07org.openembedded.dev * r053e7c8340 10openembedded.git/recipes/irda-utils/ (irdadump/glib2.patch irdadump_0.9.16.bb): irdadump: Migrated to glib-2.0. Jan 19 21:07:28 03Stanislav Brabec  07org.openembedded.dev * rccfe5e49bb 10openembedded.git/recipes/glib-1.2/glib-1.2_1.2.10.bb: glib-1.2: Fixed file list of glib-1.2-dev. Jan 19 21:16:22 03Stanislav Brabec  07org.openembedded.dev * r89f3a006a1 10openembedded.git/recipes/glib-1.2/glib-1.2_1.2.10.bb: glib-2.0: Typo fix in previous commit. Jan 19 21:32:03 Crofton_|work: Thnx! Jan 19 21:33:17 Has anyone configured lighttpd and php? Jan 19 21:33:37 effem did Jan 19 21:34:28 Laibsch: have you seen how nicely integrated the qemu bits are in firmware linux? automatically spawns a distccd on the host end and configures the distro to use it, for doing builds in the qemu instance. one script to spawn it against the build output and drop in and work Jan 19 21:35:02 no, never seen it Jan 19 21:35:03 woglinde, yeah, but he's probably in his bed by now :-(. My question is which way I should set it up, cgi or fast cgi.. Jan 19 21:35:06 Laibsch: would be good to do something like that in our stuff. would be even more slick to set up a local http server on the build machine hosting the ipk feed, and configure opkg to use it out of the box in the qemu instance Jan 19 21:35:20 jovox fastcgi Jan 19 21:35:21 Laibsch: ./contrib/run-qemu.sh default-image ... opkg install foo .. would kick ass Jan 19 21:35:25 heh Jan 19 21:35:31 Sure Jan 19 21:35:43 I'm still struggling with getting basic images to work, though Jan 19 21:35:56 basic, but GUI images Jan 19 21:36:07 hehe. baby steps Jan 19 21:36:22 forward, yes Jan 19 21:36:33 woglinde, ok, that means I need to add the fastcgi module to lighttpd, add the fastcgi package, and php? Jan 19 21:36:46 and whenever you return to OE it seems the project has taken some giant leaps back on just basic stuff Jan 19 21:37:07 * kergoth needs to fix his Linux machine at home, then will see about doing some regular builds of OE proper Jan 19 21:37:10 hm didn't we activate ot? Jan 19 21:37:11 everything gets more advanced, but it took me about 14 days until xorg-image would compile again Jan 19 21:37:15 aregs it Jan 19 21:37:16 yikes Jan 19 21:37:42 nobody looks at the bug tracker (new policy or not) Jan 19 21:37:48 well, I shouldn't say nobody Jan 19 21:37:53 the usual suspects do Jan 19 21:38:09 but that is irrespective of the new policy Jan 19 21:38:36 which new policy? Jan 19 21:40:28 OE has become stricter on what bugs to accept (although the distinction is fuzzy) Jan 19 21:40:35 ah Jan 19 21:40:42 the official wording is "bugs in OE metadata only" Jan 19 21:40:50 but nobody really knows what that means Jan 19 21:41:33 people still don't use the bug tracker, and I think that is because it means more work, not less Jan 19 21:41:54 but there is no way around that if as a project you want to be open to contributions Jan 19 21:42:19 I can't see any substantial inefficiency with bugzilla Jan 19 21:42:31 speaking of efficiency, ping RP Jan 19 21:42:46 kergoth: How good is your perl? Jan 19 21:43:13 not what it used to be. i used to be pretty good with it, but nowadays the extend of my perl coding is the occasional text mangling Jan 19 21:43:21 * kergoth uses python/shell/etc day to day now Jan 19 21:46:26 kergoth: what do you think about the quality of the coding (the idea is obviously excellent) of http://www.theoldmonk.net/blog/archives/2008/03/08/git-bugzilla_integration/ ? Jan 19 21:47:36 looks pretty straightforward, i don't see any obvious issues with it Jan 19 21:49:33 woglinde, I don't which package provides php's fastscgi Jan 19 21:49:58 jovox aeh you better should have read the lighty docu Jan 19 21:50:05 fastcgi is a lighty modul Jan 19 21:50:23 fastcgi you can use python ruby php other stuff Jan 19 21:50:29 1. Git should disallow any commit where the commit message does not have a bug number. ? Jan 19 21:50:41 Crofton: no, of course not Jan 19 21:50:44 not that bit Jan 19 21:50:51 fully optional Jan 19 21:50:54 hi crofton Jan 19 21:51:10 hi woglinde Jan 19 21:51:14 but close a bug ticket if you already said so in the commit? Jan 19 21:51:20 yes, but the docs also says that php needs to be installed. And the php package doesn't seem to provide what Lighttpd needs Jan 19 21:51:38 ???? Jan 19 21:51:46 you only the php executbale Jan 19 21:51:51 which should working Jan 19 21:52:16 which is not built with "bitbake php" Jan 19 21:52:26 working php-exec, nearly working fastcgi Jan 19 21:52:33 so its php problem Jan 19 21:52:41 no lighty Jan 19 21:52:47 ok, right Jan 19 21:52:53 and sorry I will/can not help with php Jan 19 21:53:02 I dont like this language Jan 19 21:53:36 neither do I Jan 19 21:59:48 hi,I've a 2.6.32+2.6.33 kernel in my feeds Jan 19 21:59:55 I want to remove it Jan 19 22:00:04 but the 2.6.33 went from rc2 to rc4 Jan 19 22:00:14 and PR was also bumped Jan 19 22:00:21 how do I clean 2.6.33? Jan 19 22:21:58 GNUtoo: use "rm" Jan 19 22:22:09 lol Jan 19 22:22:10 ok Jan 19 22:22:18 thanks Jan 19 22:22:33 I'll rm and clean and re-bitbake the kernel Jan 19 22:22:37 there's no magic to deleting packages from the feeds, you literally just have to remove the .ipk files Jan 19 22:22:55 and then regenerate the index Jan 19 22:23:07 hi pb Jan 19 22:23:40 hi woglinde Jan 19 22:26:44 hi pb__ woglinde Jan 19 22:27:14 ok thanks a lot Jan 19 22:59:46 hi ant__ Jan 19 23:08:26 hmm Jan 19 23:08:58 hmm? Jan 19 23:09:15 I pasted a link in the other window and it did not get here Jan 19 23:09:23 client on another machine Jan 19 23:10:13 see http://tinderbox.openembedded.net/public/logs/task/4517109.txt Jan 19 23:14:17 fun Jan 19 23:18:48 Crofton_|work: this is the reason for that gnome-games breakage? Jan 19 23:19:35 crofton I need the do_configure Jan 19 23:20:52 okay I have t Jan 19 23:21:01 args Jan 19 23:21:04 but not the log Jan 19 23:23:00 I suspect we can do something like seding the usr/include/SDL to point into staging Jan 19 23:23:21 crofton again Jan 19 23:23:28 show me the do_configure log please Jan 19 23:23:45 config.log? Jan 19 23:23:51 both Jan 19 23:23:56 do_configure Jan 19 23:23:56 let me see Jan 19 23:24:00 and configure.log Jan 19 23:24:25 first we need to see which sdl.m4 macro is drag in Jan 19 23:24:36 do you know a pastebin that lets you upload files? Jan 19 23:24:42 the one gnome-games shipps is uterless crap Jan 19 23:24:47 pastebin.ca Jan 19 23:25:10 ah right upload the sdl.m4 file too Jan 19 23:28:15 http://pastebin.ca/1758205 Jan 19 23:29:02 woglinde, config.log is too large to upload :( Jan 19 23:29:59 don't see an sdl.m4 file Jan 19 23:30:06 Crofton_ hm upload configure please Jan 19 23:30:54 too big Jan 19 23:30:59 checking for sdl-config... /usr/bin/sdl-config Jan 19 23:31:02 is the problem Jan 19 23:31:07 and we need to find out Jan 19 23:31:23 crofton do you dont have some webspace for upload? Jan 19 23:31:28 yeah Jan 19 23:33:01 http://balister.dyndns.org:8008/~balister/oe/config.log Jan 19 23:33:06 and configure Jan 19 23:33:10 and configure.in Jan 19 23:36:38 crofton Jan 19 23:36:39 as_save_PATH="$PATH" Jan 19 23:36:39 if test "x$prefix" != xNONE; then Jan 19 23:36:39 PATH="$prefix/bin:$prefix/usr/bin:$PATH" Jan 19 23:36:39 fi Jan 19 23:36:46 is the bullshit Jan 19 23:37:13 this is in configure.in? Jan 19 23:37:18 jepp Jan 19 23:37:24 but I cannt see where it is included Jan 19 23:37:32 from the configure.in Jan 19 23:37:38 heh Jan 19 23:37:47 autotools sucks :) Jan 19 23:37:54 no Jan 19 23:38:06 fools who dont use it right suckz Jan 19 23:38:14 okay Jan 19 23:38:57 I think quickfix is set --with-sdl-exec-prefix Jan 19 23:39:15 I will test it Jan 19 23:39:50 :) Jan 19 23:39:52 very true Jan 19 23:40:18 ok time for dinner Jan 19 23:40:30 thanks for the help, resolving this will be great Jan 20 00:25:42 hm I am really puzzeld Jan 20 00:25:46 in the libsdl svn Jan 20 00:26:01 is a new .m4 macro which first uses pkg-config Jan 20 00:27:14 hm okay Jan 20 00:27:26 came out after the .14 release Jan 20 01:12:27 cronfton pull and try Jan 20 01:12:29 03Henning Heinold  07org.openembedded.dev * r54fd635924 10openembedded.git/recipes/gnome/gnome-games_2.24.0.bb: Jan 20 01:12:29 gnome-games: set libsdl-mixer as dependency and delete sdl.m4 macro only when exist Jan 20 01:12:29 * bump PR Jan 20 01:12:30 03Henning Heinold  07org.openembedded.dev * ra41265d883 10openembedded.git/recipes/libsdl/ (libsdl-x11-1.2.14/sdl.m4 libsdl-x11_1.2.14.bb): Jan 20 01:12:30 libsdl-x11: use newer sdl.m4 macro from svn Jan 20 01:12:34 * the sdl.m4 macro now uses pkgconfig which unbreaks gnome-games Jan 20 01:12:36 build Jan 20 01:12:38 * bump PR Jan 20 01:47:44 woglinde, thanks, that seems to have solved the problem Jan 20 01:48:32 fine Jan 20 01:48:48 I earlier thought that .14 sdl has the newer m4 macro already Jan 20 01:53:19 ah Jan 20 01:53:31 good fix Jan 20 01:53:46 much better than the usual seding around :) Jan 20 01:54:27 yeah I was to lazy to patch the macro file Jan 20 01:54:47 okay good nite Jan 20 01:55:37 gn **** ENDING LOGGING AT Wed Jan 20 02:59:57 2010