**** BEGIN LOGGING AT Thu Feb 10 02:59:57 2011 Feb 10 06:50:52 khem, ping ka6sox is trying to ping you through me Feb 10 07:39:47 khem, still away? Feb 10 08:32:49 03Martin Jansa  07master * rba31f48093 10openembedded.git/recipes/xorg-xserver/ (5 files in 2 dirs): Feb 10 08:32:49 xserver-xorg: 1.9.3.902 was released as 1.9.4, rename Feb 10 08:32:49 Signed-off-by: Martin Jansa Feb 10 08:47:49 good morning Feb 10 09:02:26 gm Feb 10 09:05:28 woglinde: hi Feb 10 09:05:41 'morning Feb 10 09:06:46 anyone around having a angstrom 2008 build setup and could test to build usb-modeswitch? Feb 10 09:07:00 woglinde: you know what? race issue with curl-native appears only building from Gentoo. Zero issues from Ubuntu lucid ... Feb 10 09:07:08 It fails during do_install for me and git bsiect points me to an commit from kergoth Feb 10 09:07:32 I already experienced some strange quirks, because Gentoo's perl has no threads. Feb 10 09:07:55 So I suspect something goes wrong during autoconf Feb 10 09:08:08 e.g. peeking at buildhost and not sysroot Feb 10 09:08:28 ant lol Feb 10 09:08:40 more strangeness: race only occours with >= 4 bb threads Feb 10 09:08:46 all fine with 2 :/ Feb 10 09:09:09 hm thats really strange Feb 10 09:09:11 woglinde: same PC, same OE partition... Feb 10 09:09:15 and hard to debug Feb 10 09:10:40 I'll try to diff the config files Feb 10 09:11:30 fwiw, I've already seen curl-native linking to ldap when building an image but not if being built from scratch. Feb 10 09:23:48 hi mickey|bbl Feb 10 09:23:53 hi mickey|office Feb 10 09:23:57 kergoth: ping Feb 10 09:23:59 morning stefan_schmidt Feb 10 09:24:32 hi mickeyl Feb 10 09:24:35 hi stefan Feb 10 09:24:40 hi woglinde Feb 10 09:29:19 * stefan_schmidt just ordered his second TV in life Feb 10 09:31:57 lol Feb 10 09:32:32 tft? Feb 10 09:34:27 woglinde: Samsung 46" LED TV Feb 10 09:34:47 With integrated tuner and usb for a harddisk Feb 10 09:35:04 to get rid of all this boxes around the TV Feb 10 09:35:10 46? Feb 10 09:35:11 wtf Feb 10 09:35:54 :D Feb 10 09:36:12 Needed something bug for Wii gaming Feb 10 09:36:19 its the official excuse :) Feb 10 09:42:34 morning Feb 10 10:11:25 * rob_w curse xinput_calibrator Feb 10 10:11:47 CIA-2: Thank you for yesterday's patch on the curl Feb 10 10:15:13 rob_w: I'm following your Odyssey...we'll have to move from kdrive to xorg soon Feb 10 10:16:43 rob_w still fighting? Feb 10 10:16:58 am now at the point to leave out tslib and go kernel-evdev - xorg-evdev with xinput-calibrator Feb 10 10:17:09 looks all good Feb 10 10:17:19 but the dynamic part of the recalib is not working Feb 10 10:17:35 if i set the values in xorg.conf they are are perfect Feb 10 10:17:47 but as soon as i call xinput with the values .. this happens Feb 10 10:17:54 EE) GLX: could not load software renderer Feb 10 10:17:54 (EE) Failed to load module "tslib" (module does not exist, 0) Feb 10 10:17:54 (EE) No input driver matching `tslib' Feb 10 10:17:54 (EE) config/hal: NewInputDeviceRequest failed (15) Feb 10 10:18:06 which is ok imho as i removed tslib.so Feb 10 10:18:14 but the values are not set Feb 10 10:19:17 am still at xorg server 1.7.4 .. might this be a issue ? Feb 10 10:20:46 rob_w: if you have everything in xorg.conf then disable adding devices from hal/udev Feb 10 10:20:56 how do i ? Feb 10 10:21:42 rob_w: like this http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1a841b207adb2b1a473ecf1217bc464f34755161 Feb 10 10:22:12 thx Feb 10 10:25:06 screw it .. i go onto 1.9.2 Feb 10 10:25:08 * Jay7 have used xinput_calibrator yesterday's night to calibrate wacom's digitiser of ThinkPad X61t Feb 10 10:30:28 hmm who limited me to 1.7.4 xorg .. Feb 10 10:32:04 ah jama Feb 10 10:32:11 ah woglinde_ :) Feb 10 11:20:38 arg now omapfb is not working Feb 10 11:31:52 rob_w lol hardtimes Feb 10 11:31:58 jama ping Feb 10 11:32:08 I remember now what I wanted to ask Feb 10 11:32:59 woglinde: pong Feb 10 11:45:24 jama hm what's the case with egl and mesa and cairo stuff Feb 10 11:45:27 hi obi Feb 10 11:45:37 hi woglinde Feb 10 11:45:45 jama should we introduce a feature which takes that I want only gles Feb 10 11:45:53 and not whole gl support Feb 10 11:46:30 the whole xorg gles gl and so on stuff is really hard to understand sometimes Feb 10 11:50:46 woglinde: to be honest, it's confusing also to me Feb 10 11:51:22 ok am back into buisness .. xorg 1.9.2 but yet its not taking the dynomic calibration Feb 10 11:51:22 jama yeah and you have the case where you want gles but not xorg Feb 10 11:51:46 rob_w xorg or xserver? Feb 10 11:52:05 xserver-xorg = 1.9.2 Feb 10 11:52:17 ah Feb 10 11:52:24 jama just checked in 1.9.4 Feb 10 11:55:11 and 1.9.2 was removed long ago Feb 10 11:55:25 and I don't know what you mean by "its not taking the dynomic calibration" Feb 10 11:55:58 i mean i cant set xinput set-int-prop "touch" "Evdev Axis Calibration" 32 77 3952 165 3976 Feb 10 11:56:24 why? Feb 10 11:56:35 i run xinput_calibrator .. and its also supposed to set the values to the current Xorg session Feb 10 11:57:03 why ? why i want to do it ? or wyh its not working ? Feb 10 11:57:18 why it's not working Feb 10 11:57:28 hehe well thats the good question Feb 10 11:58:01 or what exactly is not working Feb 10 11:58:02 check xinput_calibrator_once.sh Feb 10 11:58:11 that's what my images are using successfully Feb 10 11:58:25 did you remove that AutoAdd as I said before? Feb 10 11:58:37 yep and yep Feb 10 11:58:58 because ie I had problem when 1 input was defined in xorg.conf with right calibration in /etc/pointercal.xinput Feb 10 11:59:07 xinput_calibrator as such works .. the values it generates are perfect but it doesnt work settings this life in a running Xorg session Feb 10 11:59:27 but another input was added by udev (for same hw device) but this time with evdev driver (instead of tslib from xorg) Feb 10 11:59:45 so the second was preferred and not calibrated at all Feb 10 12:00:03 hmm lemme rebuild the rest of xorg .. as i just moved onto 1.9.2 . maybe the libs are still against the 1.7.4 from before Feb 10 12:00:30 hm again in oe is now 1.9.4 with bugfixes Feb 10 12:00:32 see how xinput_calibrator is called from Xsession.d Feb 10 12:00:52 calling it is not an issue Feb 10 12:01:16 it seems xinput as such is the issue to get the stuff into a live session Feb 10 12:01:35 that's how it's used here and here it works Feb 10 12:01:58 kk thanks Feb 10 12:02:35 woglinde: any hint on that icedtea-native? Feb 10 12:04:07 jama what? Feb 10 12:04:14 what was the problem again? Feb 10 12:04:15 sorry Feb 10 12:05:17 woglinde: trying to build 32b version on 64b host Feb 10 12:06:46 woglinde: __x86_64__ gets probably undefinde in the process and then my build fail because of missing gnu/stubs-32.h (which is included instead of gnu/stubs-64.h when there is no __x86_64__ Feb 10 12:07:43 oh sorry Feb 10 12:07:49 woglinde: http://paste.pocoo.org/show/335671/ Feb 10 12:07:53 hehe check this out .. calling xinput to see the props of the device .. then change ,, then xinput listing probs calls X Error http://pastebin.com/a5WgHmVR Feb 10 12:07:55 why building 32bit version? Feb 10 12:09:18 woglinde: don't know why it's lost during do_compile, but first parts look like building 64b right Feb 10 12:10:11 woglinde: didn't really look into it as you said you had to solve similar issue in cross compile build Feb 10 12:10:23 hm Feb 10 12:10:46 jama do you have a complete log? Feb 10 12:11:43 rob_w: http://paste.pocoo.org/show/335675/ Feb 10 12:12:17 yeo thats what want Feb 10 12:12:31 * rob_w needs a smoke Feb 10 12:13:51 woglinde: http://paste.pocoo.org/show/335680/ Feb 10 12:14:17 woglinde: it's not really complete as I had to restart build due to jamvm segfault Feb 10 12:14:36 woglinde: but please note -m32 in last gcc call Feb 10 12:16:50 woglinde: without it.. lass command works ok Feb 10 12:18:04 wow calling simply xinput list-props "touch" 3 times brings up the X erro at the 3rd call Feb 10 12:18:54 yes saw it now Feb 10 12:18:59 damn sizer binary Feb 10 12:22:09 jama seems we introduced it ones Feb 10 12:22:11 icedtea6-native-1.7.5/icedtea-jdk-build-sizer-32-on-amd64.patch Feb 10 12:23:11 maybee we dont need it anymore Feb 10 12:26:59 woglinde: from that comment in that patch it looks like something for native-sdk? Feb 10 12:27:33 woglinde: otherwise I don't understand why anyone on x86_64 would need to build openjdk for 32bit platform Feb 10 12:27:58 except if openjdk is always built for 32bit :) Feb 10 12:32:03 jama talked with robert Feb 10 12:32:44 we build the 32bit sizer for the crosscompiling Feb 10 12:33:06 but we can change it in the cross compile too to use qemu Feb 10 12:36:48 woglinde: I've skiped the sizer 32b build and now trying to continue with openjdk-6 build Feb 10 12:37:00 jama it will not end Feb 10 12:37:01 let's see if it still works Feb 10 12:37:10 you need the sizer when awt is build Feb 10 12:37:40 and why do I need 32b version while building 64b openjdk? Feb 10 12:37:59 or do I need it for arm openjdk even? Feb 10 12:38:12 arm Feb 10 12:38:26 sure for 64bit amd you wouldnt need them Feb 10 12:51:44 is tehre a way to rebuild all libX packages ? Feb 10 12:53:27 no Feb 10 13:03:39 Tartarus: ping? Feb 10 13:18:49 pb_, did you ever get back in your house? Feb 10 13:24:42 woglinde: openjdk build for armv4t finished ok now without sizer32 in icedtea-native :) Feb 10 14:59:25 03Andreas Oberritter  07master * rb88dccd7c6 10bitbake.git/.gitignore: Feb 10 14:59:26 .gitignore: add *.pyo Feb 10 14:59:26 * python generates pyo files if PYTHONOPTIMIZE is set Feb 10 14:59:26 Signed-off-by: Andreas Oberritter Feb 10 14:59:26 Signed-off-by: Chris Larson Feb 10 14:59:36 03Javier Martin  07master * rf30b3af975 10bitbake.git/lib/bb/fetch/__init__.py: Feb 10 14:59:37 Fix comparison with SRCREVINACTION constant Feb 10 14:59:37 Use '==' instead of 'is', otherwise it will always return Feb 10 14:59:37 true since 'rev' and "SRCREVINACTION" are not the same object. Feb 10 14:59:37 Signed-off-by: Javier Martin Feb 10 14:59:37 Signed-off-by: Chris Larson Feb 10 14:59:38 03Javier Martin  07master * rd761cf9828 10bitbake.git/lib/bb/ (fetch/__init__.py utils.py): Feb 10 14:59:38 Export KRB5CCNAME variable Feb 10 14:59:39 This allows fetching git repositories using Kerberos authentication. Feb 10 14:59:39 Signed-off-by: Javier Martin Feb 10 14:59:40 Signed-off-by: Chris Larson Feb 10 15:03:04 * Tartarus finally tries postgresql 8.4.4 + mips64 to see if that stops using ld and starts using CCLD Feb 10 15:07:04 are there instructions somewhere on using an external toolchain? the manual in git still says TODO Feb 10 15:07:20 * kergoth_ sighs in sqlite's direction Feb 10 15:07:38 unfortunately with a Marvell target you have to use their provided toolchain -- can't allow oe to build anything. so I'm a bit lost Feb 10 15:08:11 demigod2k, have you hit google? Feb 10 15:08:24 The manual may be missing it but denix and I have both talked about how to do it on the ML Feb 10 15:08:43 that said, it's only tested well for either OE-built toolchains or CodeSourcery ARM toolchains Feb 10 15:08:50 ya I have. I'm a total beginner with this, but I keep hitting on explanations that don't really line-up with the code as it stands today (like 2007-2008 era) Feb 10 15:08:50 kergoth_: have a minute? Feb 10 15:09:05 somewhat, whats up Feb 10 15:09:12 demigod2k, sec Feb 10 15:09:30 tartarus, do you remember the subject line? maybe that'll help me hit it better. I saw a bunch about ASSUME_PROVIDED the problem is it keeps trying to build glibc and other things that turn out to be a big problem Feb 10 15:09:36 kergoth: I have problems with do_install here http://pastebin.com/afJBjvYA and git bisect pointed me at your commit Feb 10 15:09:41 yeah, assume provided is wrong :) Feb 10 15:09:42 kergoth: af5f4debf19be227c63d5cc89e4acd2961469724 Feb 10 15:09:52 kergoth: the install wrapper instead coreutils native Feb 10 15:09:55 after floundering a bit yesterday I need to rm the whole mess and start over again too :) I tried too much with assume_provided Feb 10 15:10:03 kergoth: and indeed reverting it fixes the issue for me Feb 10 15:10:06 stefan_schmidt: try changing it to use -m instead of --mode Feb 10 15:10:30 tartarus, I appreciate it by the way. I'm giving this a shot. we usually use buildroot but I'm starting a new project so... we'll see how this works out Feb 10 15:10:33 kergoth: its oe_runmake install DESTDIR=${D} Feb 10 15:10:40 stefan_schmidt: yes.. Feb 10 15:10:52 kergoth: recipes/usb-modeswitch/usb-modeswitch_1.1.4.bb Feb 10 15:10:56 demigod2k, http://pastebin.com/WxTrY4tW Feb 10 15:10:59 again, not helpful Feb 10 15:11:06 i'm talking about what the makefile is doing, not what the recipe is doing Feb 10 15:11:17 That's how I do it, and oh, i also used that one for x86, heh, so it's got 2 examples Feb 10 15:11:18 kergoth: ah Feb 10 15:11:18 just give me a minute and i'll do it Feb 10 15:11:29 kergoth: no need I can do it as well Feb 10 15:11:42 kergoth: Just thought all the time that it was in our classes Feb 10 15:11:47 stefan_schmidt: it was a portability concern, our wrapper only implements the args that seem most portable Feb 10 15:11:55 oe_runmake just runs make with EXTRA_OEMAKE args Feb 10 15:11:57 nothing magic :) Feb 10 15:12:20 kergoth: thanks thats enough info Feb 10 15:12:25 tartarus: are you still using the mingw recipes that you checked in a while back? Feb 10 15:12:29 kergoth: I can fix it Feb 10 15:12:41 okay, thanks Feb 10 15:12:44 sorry about the hassle Feb 10 15:12:50 kergoth: morning Feb 10 15:12:54 hey pb_ Feb 10 15:12:54 pb_, I am not and I need to go poke the person that updated them a while back and got distracted Feb 10 15:12:54 kergoth: well, thanks for giving me the right direction :) Feb 10 15:12:58 np Feb 10 15:13:05 pb_, attempting to use? Feb 10 15:13:07 kergoth: no deal, normal fallout Feb 10 15:13:33 tartarus: well, attempting to understand what their intended use-case is at the moment. :-) Feb 10 15:13:40 pb_, ok Feb 10 15:13:51 tartarus: I am trying to set up oe to target mingw32 (i.e. build mingw32 binaries) but the existing recipes seem to be all canadian configs. Feb 10 15:13:52 Tartarus: so basically uncomment those? I was heading down that road. So toolchain_type = "External" is going to hit on including toolchain-external.inc Feb 10 15:14:13 pb_, there's bits in there too for making mingw32 binaries as well Feb 10 15:14:19 ie there's a mingw32-make or so recipe Feb 10 15:14:22 Or, uh, should be :) Feb 10 15:14:39 demigod2k, yes. And 'external', it's important to get the case right :) Feb 10 15:14:51 Tartarus: one part I don't quite understand is that *.inc does a PREFERRED_PROVIDE_virtual for each piece defining as "external-toolchain-${TOOLCHAIN_BRAND}" Feb 10 15:15:07 how does that end up mapping to my compiler? Feb 10 15:15:15 demigod2k, there's a lot of abstractions going on that set things up right, in the end Feb 10 15:15:42 Tartarus: ah, hm, right. I didn't see that but maybe I didn't look hard enough. Feb 10 15:16:02 mingw-make-canadian-sdk_3.81.bb Feb 10 15:16:45 Builds mingw-make (which is different from make itself, it's the mingw's projects patched one) that runs as a mingw32 binary Feb 10 15:17:16 or more simply.... my compiler's binary is called arm-mv5vfp-linux-gnueabi-gcc. is there some other definition in there that manages to tell it the correct binary name? Feb 10 15:17:47 So, you'll need to write an external-toolchain recipe for it Feb 10 15:17:53 see recipes/meta/external-toolchain*bb Feb 10 15:18:15 mmmm there might be the trick Feb 10 15:18:24 Tartarus: ah, right, in the make/ dir. I was looking in mingw/, doh. Feb 10 15:19:17 if this all works it might be cool but wow this is difficult. are a lot of companies using this? Feb 10 15:19:20 Tartarus: that still seems to be a canadian setup though which leads me to suspect it is not quite what I wanted. Feb 10 15:20:07 pb_, well, what are you trying exactly? Feb 10 15:20:23 That's for build on linux, runs on mingw32 ("targets" mingw32) Feb 10 15:21:32 Tartarus: yeah, that's basically what I want (i.e. TARGET_SYS=i686-oe-mingw32). I don't quite understand why all those recipes are setup to use canadian-sdk though, that seems a bit weird. Feb 10 15:22:45 Um Feb 10 15:22:51 I suppose, when you have a nail.... Feb 10 15:23:13 It was a side effect of the first need being build linux, runs mingw32 targets mips Feb 10 15:23:39 (when you have a hammer? heh, time for cup #2 of coffee) Feb 10 15:24:45 Righto, fair enough. So it works ok in the degenerate case where you aren't actually doing a canadian cross? I guess I'll give it a go and see what happens. Feb 10 15:25:24 It's all slightly busted I bet, sec.. Feb 10 15:29:43 kergoth: yeah, after looking at the makefile and not trying to find it in our classes its quite obvious that --mode= is the problem Feb 10 15:30:02 kergoth: shame on me not thinking about this earlier :) Feb 10 15:30:12 hehe, np Feb 10 15:35:07 Is there some option for bitbake to only compile packages required for a certain recipe? Seems silly to built 7300 items for a 8mb console-image :( Feb 10 15:35:58 what bitbake command are you executing? normally it only builds the dependency set you've asked for.. Feb 10 15:36:08 7300 "tasks" is different from 7300 "items".. Feb 10 15:36:33 bitbake console-image, board is a micro2440 Feb 10 15:36:36 along with that question, is there a way to see the build-plan for a certain set? I was following the tutorial to build nano and can't tell what the entire chain is that it wants to build Feb 10 15:36:38 a small image can easily be 7300 tasks when you factor in host tools, toolchains, libc, basic application support and related Feb 10 15:37:01 there is an option to produce a graph, but I don't know it off hand.. the bitbake help might give you what you need Feb 10 15:37:34 NovceGuru my 16 MB "minimal" image is around 4500 tasks.. (but I'm not running the OE set of recipes -- so that will affect the count) Feb 10 15:37:54 I think the option was -g which puts out some template-*.dot Feb 10 15:38:00 that sounds right Feb 10 15:38:22 Mainly I wanted to check that external-toolchain is working, since compiling nano should not take that much if it's pulling everything from the external tools Feb 10 15:38:37 I was still getting the thousands of tasks so I suppose the external still wasnt working :) Feb 10 15:39:15 ya, task count CAN be misleading.. the graph should tell you hat it's doing though.. Feb 10 15:39:20 fray: gotcha, I just saw things like bison and what not which didnt seem to have anything to do with my image Feb 10 15:39:45 but I could very well be wrong :) Feb 10 15:39:45 ya.. most likely they're host tools.. or things needed to build the target image, but won't end up on the target image itself Feb 10 15:39:52 (bison is almost certainly a host-tool) Feb 10 15:40:19 I only ask becuase bison failed to build, and was annoyed, haha Feb 10 15:42:15 since I have to set a DISTRO variable, is "minimal" a safe one to start? I don't quite understand how that setting works but I really don't want all the stuff I see in most of htem Feb 10 15:42:35 not sure, sorry Feb 10 15:43:10 I'll give it a shot. Seems like the goal from the distro is to name all sorts of packages (x11, etc). at least the name minimal sounds like a safe bet Feb 10 15:44:02 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * rfc005a9dc5 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): Feb 10 15:44:02 xserver-xorg-conf: fix htcdream calibration and Monitor entries Feb 10 15:44:02 Without that fix that fix the screen is not calibrated well. Feb 10 15:44:02 The Monitor "Monitor" -> Monitor "Monitor0" was a typo, Feb 10 15:44:02 Thanks pespin in #openmoko-cdevel on Freenode on irc for notifying the error: Feb 10 15:44:02 Feb 09 23:27:58 I think this line in xorg.conf is wrong -> Monitor "Monitor" Feb 10 15:44:03 Signed-off-by: Denis 'GNUtoo' Carikli Feb 10 15:47:22 03Stefan Schmidt  07master * r1379a59cfd 10openembedded.git/recipes/usb-modeswitch/ (2 files in 2 dirs): Feb 10 15:47:22 usb-modeswitch: Patch makefile to use portable install options. Feb 10 15:47:22 Without this it fails with our install wrapper whcih does only support portable Feb 10 15:47:22 options. Feb 10 15:47:33 03Stefan Schmidt  07master * r6a5cfd3156 10openembedded.git/recipes/usb-modeswitch/ (2 files in 2 dirs): Feb 10 15:47:33 usb-modeswitch-data: Patch makefile to use portable install options. Feb 10 15:47:33 Without this it fails with our install wrapper whcih does only support portable Feb 10 15:47:33 options. Feb 10 15:57:33 Tartarus: how did you start on your external-toolchain-*.bb recipe, did you copy the -generic? Feb 10 15:59:04 I'm using hte csl one Feb 10 16:05:14 Tartarus: already looking a heck of a lot better. I'm down to "task X of 465" instead of "task X of 7000ish" Feb 10 16:06:44 its still goofy why it thinks it needs sqlite-native just in order to build nano. but.... I won't judge :) Feb 10 16:08:26 Well, it's part of a "get things right" mentalty Feb 10 16:08:34 Rather than being the quickest, we aim to be the most correct Feb 10 16:08:44 So we don't rely on host stuff when we don't have to Feb 10 16:09:48 totally agreed there, I hate host dependencies. I'm just skeptical that it's needed when I have an external toolchain and I'm compiling a program that doesn't need it. maybe for the packaging or something Feb 10 16:10:33 I was fighting marvell's host dependencies forever just to get the cross compiler working. more than half of them were stupid documentation related problems -- not having the right version of xxx2pdf or something Feb 10 16:11:01 so like 2 hours into the build it craps out because it cannot build a manpage for binutils which I didnt care about in the first place Feb 10 16:12:33 * Tartarus curses postgresql, a lot Feb 10 16:13:45 As I'm relatively new to this package, are you a main developer or a user? Feb 10 16:22:37 developer Feb 10 16:29:13 cool nice to meet you. we've done a handful of projects with buildroot and uclibc based toolchain in the past -- taking a look at this since it seems to be a better fit with glibc Feb 10 16:32:50 demigod2k: OE fits all! :-D Feb 10 16:33:15 * kergoth_ rolls eyes Feb 10 16:33:20 mckoan: it has an incredibly, incredibly steep learning curve Feb 10 16:33:50 continuing work is in progress with OE and similar projects to lower the curve.. Feb 10 16:33:50 demigod2k: definitely the steepest I've ever seen! Feb 10 16:34:26 I think the best-fit is if you have a read-write root filesystem. If it's read-only and if you have a tiny NOR flash I'm not sure that it's a good fit Feb 10 16:34:48 tiny NOR these days is way different hten tiny NOR 10 years ago.. ;) Feb 10 16:35:03 I wouldn't necessarily go with OE if I was doing board bringup or something Feb 10 16:35:21 but between eglibc, and other various optimizations it is do-able.. but ya, bring up and system creation are perhaps different tasks.. Feb 10 16:35:24 or active application development directly anyway, external-toolchain from it though, perhaps Feb 10 16:35:38 I find build systems, like OE, to be really good at creating something I can support/reproduce 5-10 years from now.. Feb 10 16:35:44 jo Feb 10 16:35:46 fray: sorta. we have a few products with 8mb flash which is partitioned into a 5mb main rootfs and 3mb recovery rootfs. I say that because OE seems oriented around packages and packages are unnecessary overhead for that small of a flash Feb 10 16:35:47 but if I'm prototyping.. it may be unnecessary overhead Feb 10 16:36:08 demigod2k: what do you count as tiny NOR? if you have less than a few megabytes then I would have thought any kind of linux would probably be a poor fit. Feb 10 16:36:14 5 MB rootfs tells me you want an optimized libc and -1- application.. Feb 10 16:36:37 an 8 mb rootfs these days will get you libc, busybox and a few apps.. Feb 10 16:36:43 ah, 5MB? luxury, you could fit ten rootfses in there. :-) Feb 10 16:37:15 more then 8 mb rootfs and you have more then enough space for pretty much anything.. :) Feb 10 16:37:21 you don't have to use all the packaging stuff on the target, you can just ignore all of that. Feb 10 16:37:32 hm 5b is enough for stripped down qt Feb 10 16:37:46 pb_: definitely. and it doesn't have to be that way -- just when i see things like x11, qt, etc my eyes glaze over. we don't use anything like that Feb 10 16:38:19 demigod2k: yeah, that's fine. you can ignore that stuff too. oe can build it, but you aren't obliged to. Feb 10 16:38:30 our workflow is the rootfs gets built as a squashfs, deployed to users, nothing writable on there Feb 10 16:39:07 that is all very easy to do.. just means you'll want your own custom image task.. nothing exciting there.. Feb 10 16:39:26 default images are really samples that you can build from.. but you don't have to Feb 10 16:39:28 ya once i get past the external toolchain stuff that should be more turning-the-crank Feb 10 16:39:35 yup Feb 10 16:40:15 hm kergoth is bouncing Feb 10 16:40:22 my computer hates me Feb 10 16:40:24 :| Feb 10 16:43:46 mckoan: from my experience this week, the learning curve is so high because everything's controlled by variables that are basically only documented on the mailing list Feb 10 16:44:24 you have to know what variable name to set (and the value) in order to achieve something, and there's nowhere to look that up Feb 10 16:45:00 demigod2k: that is one of the things that is hopefully going to be improving over the next year... Feb 10 16:45:01 demigod2k? Feb 10 16:45:01 ? Feb 10 16:45:16 if you dont find in the wiki Feb 10 16:45:17 add it Feb 10 16:45:24 I have the same issue, too many switches -- not enough to tell me the order I should flip them in.. (or even where they might be hiding) Feb 10 16:45:24 that's really not sufficient Feb 10 16:45:31 ideally you'd be able to discover it while using the tool Feb 10 16:45:34 woglinde: I will try, but I haven't been able to make it work yet either Feb 10 16:47:06 fray: totally, and it is what it is... just contrasted with a KConfig where all the choices are presented to you. in this case I need to know "if I add some variable called TOOLCHAIN_EXTERNAL, some different file will get included way-down and change the behavior" Feb 10 16:47:13 agreed, the current documentation does suck a bit and this is an unsatisfactory state of affairs. Feb 10 16:47:23 uboot has the same problem where you can add some #define and radically change the behavior of the system Feb 10 16:47:37 eFfeM_work: hello; do you mind to take a look at the cups patches? it://projetos.ossystems.com.br/git/users/otavio/org.openembedded.dev.git Feb 10 16:47:41 I was reminded of this today when I needed to set up a build environment from scratch on a new machine. :-} Feb 10 16:48:42 * kergoth really wants to try prototyping a kconfig based configuration ui based upon the variable typing flags at some point -- unfortunately there's no namespacing, it'd be one big pile Feb 10 16:49:00 need to fix filename/lineno tracking for variables in bitbake Feb 10 16:49:07 hrm Feb 10 16:49:21 yeah, that's an interesting idea. Feb 10 16:49:40 I see two issues, finding all of the config switches.. and then documenting and categorizing them.. Feb 10 16:49:45 then the kconfig bit becomes easy.. :) Feb 10 16:50:39 the pattern for finding possible switches is easy enough.. but I suspect the rest is a manual operation Feb 10 16:53:03 we have documentation flags, we should really use them Feb 10 16:53:26 we still need a new flag to say "this configuration variable is for users to use", or some sort of degree of difficulty or something :) Feb 10 16:53:52 we have documented vars which should almost never be touched by the typical user, so don't want to show them all Feb 10 16:54:50 demigod2k: yes you're right, the main OE lack is a configuration tool Feb 10 16:55:12 I think additionally a walkthrough for a few common use-cases would help too. Coming from buildroot I expect a tool that can pick a compiler (internal or external), pick a C library (uclibc or glibc or external), build some selected set of packages, then spit-out a rootfs (squashfs, jffs2, ubi, etc) Feb 10 16:55:46 it's not like I can start with a template, copy and modify, and make that happen Feb 10 16:55:50 * kergoth wonders about yocto's roadmap item for image builder tool :) Feb 10 16:56:09 the thing that took me the longest to grasp when moving to bitbake.. I wasn't supposed to put in a list of things I wanted built.. instead I needed to put in the "end result", and that picked up everything else based on dependencies.. Feb 10 16:56:15 kergoth: I proposed to follow such path on OEDEV-2009 but I met few interest Feb 10 16:56:29 kergoth it's on the roadmap, but I don't believe there is dates associated yet.. Feb 10 16:56:32 * kergoth nods Feb 10 16:57:00 there are two sides to it.. initial configuration, and image construction.. the later is different -- we need a way to generate an image outside of the build environment.. (almost like a traditional linux system) Feb 10 16:57:15 but the resulting binary installation need to be the same as what would have been constructed by the build-system as a whole.. Feb 10 16:57:33 (initial configuration thought is a bit more important still) Feb 10 16:58:32 my efforts were on creating a overlay management system koam.kaeilos.com Feb 10 16:59:08 I tried to do something with Eclipse too, like Ken Feb 10 16:59:27 but the tool really needed would be a kconfig based configuration ui Feb 10 16:59:51 because most of us work on remote build machines Feb 10 17:00:27 yes -- whenever tooling comes up in the Yocto discussions, I alway remind people that a large set of developers work on remote configurations that do NOT have an X console Feb 10 17:00:45 BTW I'd bet that Yocto will do something like that soon or late Feb 10 17:01:12 here here. I have no X windows. Even the tool doesnt matter to me. I could configure it with a textfile if I just knew the switches that affected things Feb 10 17:01:12 I will expect that Yocto will have a configuration model at some point.. the configuration model will work on command line and in the IDEs Feb 10 17:01:33 demigod2k ya... thats the first thing.. get things identified and documented.. next step is tooling Feb 10 17:01:35 my outsider view is that it's really good as long as you're looking to build something for a zarus, or a pre-existing setup. It's very difficult to walk up and bring-up a board Feb 10 17:02:23 the very first thing I have to do is copy and modify a local.conf, copy and modify a machine conf, copy and modify an external-toolchain-* conf, and probably more. none of that has a walkthrough Feb 10 17:02:53 demigod2k: IMHO you won't need to modify so much Feb 10 17:03:10 yes Feb 10 17:03:21 because external-toolchain is extended use Feb 10 17:04:44 BTW main interest in OE has always been to add packages, until with Yocto cooperation someone discovered that reliability is important, at last Feb 10 17:05:20 Yocto is focused primarily on the core system, build components and for lack of a better phrase "initial user experience" Feb 10 17:05:29 (yocto has a long way to go still though) Feb 10 17:05:48 I hope that the next awareness step could be the configuration tool Feb 10 17:06:05 need to find / document all of the configuration settings first.. ;) Feb 10 17:06:14 fray: yes, but you have to consider who is behind yocto Feb 10 17:06:36 yes.. and hopefully more then just Intel and Wind River (publically)... Feb 10 17:06:54 * kergoth ponders Feb 10 17:06:57 * fray waits for the Linux Foundation to announce other interested parties once all of hte legal stuff is done Feb 10 17:07:04 fray: the only official and updated document is here http://wiki.openembedded.net/index.php/Documentation Feb 10 17:08:20 have a nice rest of the day guys! and happy hacking ;-) Feb 10 17:08:31 ciao mckoan Feb 10 17:09:15 woglinde: tchüss Feb 10 17:10:56 why did I get practically ignored on the makedevs issue on the ML? Feb 10 17:11:12 nobody else runs into it or what? Feb 10 17:11:40 heh taking of rfs size in OE ucslugc is 3Mb besides kernel and has a lot of apps Feb 10 17:11:49 gm all Feb 10 17:11:54 filip? ant resposnded Feb 10 17:12:30 woglinde: well I'd like to come up with a patch for it, ant's response doesn't get me close to it in no way Feb 10 17:12:34 filip: nothing gets ignored Feb 10 17:12:39 filip: what version of makedevs are you using? Feb 10 17:12:41 its just people might have not read the ml yet Feb 10 17:12:49 pb_: from busybox Feb 10 17:12:57 khem: ah, different timezone issue probably :P Feb 10 17:13:17 pb_: recipe from org.openembedded.dev Feb 10 17:13:19 filip: I guess that would be why. presumably most other folks are using the standalone one. Feb 10 17:13:25 pb_: howdy, long time is your house building work complete Feb 10 17:13:42 pb_: is there a reason for that? Feb 10 17:13:42 filip: so, you just need to make sure that your scripts are in sync with the binary you have chosen. Feb 10 17:14:00 pb_: is there an alternative /etc/init.d/devices I could choose? Feb 10 17:14:06 filip: yes what pb_ says is likely the case Feb 10 17:14:08 filip: probably just historical in most cases. Feb 10 17:14:27 and budybox makedevs have has problems of its own oto Feb 10 17:14:33 intressting Feb 10 17:14:43 so you suggestion is switching to discrete makedev? Feb 10 17:14:44 nobody sended the pulseaudio patches upstream Feb 10 17:14:45 I suspect busybox makedevs was defective at some point in the past, or possibly didn't exist at all, and (assuming it is no longer defective) there has never been a compelling reason to change Feb 10 17:15:06 how about making them compatible? Feb 10 17:15:17 with each other Feb 10 17:15:18 filip: well, that's what your /etc/init.d/devices is apparently expecting. it's up to you whether you change the script or select the other makedevs. Feb 10 17:15:54 pb_: it's not mine, it comes from initscripts-1.0 :P Feb 10 17:16:02 making them compatible would be fine too, if there is a way to do that without making them simultaneously incompatible with old versions of themselves. Feb 10 17:16:14 hm Feb 10 17:16:32 and it would be simpler to patch the simpler one as the sources are directly in the OE tree Feb 10 17:16:36 no need to push upstream Feb 10 17:16:50 hm and the libintl problem with uclibc is still there Feb 10 17:18:18 recipes/slugos-init/files/turnup: # (if makedevs is a symlink, it's the busybox version, different syntax) Feb 10 17:18:24 huh, this is wicked Feb 10 17:21:21 woglinde: what libintl issue Feb 10 17:21:36 khem I will fix it Feb 10 17:21:46 or maybee I had for prevouis version Feb 10 17:22:06 khem especially for you in german Feb 10 17:22:08 make[3]: *** Keine Regel vorhanden, um das Target »-lintl«, Feb 10 17:22:18 benötigt von »libbluetooth-ipc.la«, zu erstellen. Schluss. Feb 10 17:22:54 hm I will send the patch upstream Feb 10 17:23:04 * kergoth_ sighs Feb 10 17:23:17 kergoth buy a new one? Feb 10 17:27:15 hm seems pulse dont care on bugtracker Feb 10 17:27:27 full of bugs from 2009 Feb 10 17:27:59 woglinde: heh add CFLALS_libc-uclibc += "-lintl" Feb 10 17:29:24 no Feb 10 17:30:17 some updater didnt checked if fixbluezbuild.patch is needed Feb 10 17:30:27 and I know why upstream dont hit it Feb 10 17:30:46 because libbluetooth_ipc_la_LIBADD = $(AM_LIBADD)libpulsecore-@PA_MAJORMINORMICRO@.la libpulsecommon-@PA_MAJORMINORMICRO@.la libpulse.la Feb 10 17:30:56 $(AM_LIBADD) is empty in glibc case Feb 10 17:31:07 hmm I see Feb 10 17:31:37 its in since .15 version Feb 10 17:31:54 but as I said bugtracker seems worthless Feb 10 17:32:49 and still all patches from .21 version in oe applies to .22 too Feb 10 17:32:55 only one was fixed Feb 10 17:33:20 the switch(foo) case moo:; Feb 10 17:43:50 ok the very beginning of recipes/meta/external-toolchain-generic.bb is looking for some package-status in ${prefix}. Can anybody explain that? Did I need to set some variable or setup something to point this to my external toolchain? Feb 10 17:54:35 03Henning Heinold  07org.openembedded.dev * rf779c90411 10openembedded.git/recipes/pulseaudio/pulseaudio_0.9.22.bb: Feb 10 17:54:35 pulseaudio: add version 0.9.22 with DP=-1 Feb 10 17:54:35 * only one patch from 0.9.21 was applied, so no Feb 10 17:54:35 need to copy them all around Feb 10 17:54:46 03Henning Heinold  07org.openembedded.dev * rb3ac55f2aa 10openembedded.git/recipes/pulseaudio/ (pulseaudio-0.9.21/fixbluezbuild.patch pulseaudio_0.9.21.bb): pulseaudio: fix build for uclibc again and bump PR Feb 10 18:30:41 Tartarus: where are you using postgresql on embedded side? Feb 10 18:31:07 * Jay7 is long time postgresql user Feb 10 18:31:43 jay me wonders he dont speaked of 9.0 Feb 10 18:31:49 woglinde: same thing Feb 10 18:32:12 I have 9.0.3 here Feb 10 18:32:18 but this is home setup Feb 10 18:32:33 I've still using 8.2 in production.. Feb 10 18:32:44 jay7 a pg client isnt that uncommon for emebbed stuff Feb 10 18:33:47 ah, client Feb 10 18:34:22 or the qt postgres modul Feb 10 18:34:56 anyway it is good to have 9.0.x with DP=-1 now Feb 10 18:36:03 xora is the wiki editing fixed for you? Feb 10 18:43:45 khem, you around? Feb 10 18:46:46 Jay7, I'm not, but qt4*demo-image pulls it in Feb 10 18:46:55 and LD rather than CCLD was busting qemumips64 Feb 10 18:47:07 Tartarus: ah Feb 10 18:55:39 tartarus I asked someone to help me with getting the mirror repos going. i'm on the road and its not getting done Feb 10 18:58:49 ok Feb 10 18:59:01 ka6sox nook-color? Feb 10 18:59:18 dinner now Feb 10 18:59:20 till later Feb 10 19:01:52 woglinde yup Feb 10 19:03:27 Tartarus: http://pastebin.alm.mentorg.com/mf81c895 Feb 10 19:03:33 erm, wrong window, ignore that Feb 10 19:04:25 * Crofton|work is amused Feb 10 19:06:05 * kergoth mutters Feb 10 19:28:41 re Feb 10 19:56:11 03Alex Ferguson  07master * r00029fdb98 10openembedded.git/recipes/jlime/fileselector_1.3.1.bb: Feb 10 19:56:12 fileselector: Update version from 1.3.1 to 1.3.2 Feb 10 19:56:12 The newer version contains some bugfixes. Feb 10 19:56:12 Signed-off-by: Alex Ferguson Feb 10 19:56:12 Signed-off-by: Kristoffer Ericson Feb 10 19:56:21 03Alex Ferguson  07master * rc76f41d315 10openembedded.git/recipes/jlime/jlime-extras-ben-nanonote_1.0.1.bb: Feb 10 19:56:21 jlime-extras-ben-nanonote: Update version from 1.0.1 to 1.0.2 Feb 10 19:56:21 The newer version contains some changes in relation to jlime-extras. Feb 10 19:56:21 Signed-off-by: Alex Ferguson Feb 10 19:56:22 Signed-off-by: Kristoffer Ericson Feb 10 19:56:26 03Alex Ferguson  07master * r466933f106 10openembedded.git/recipes/jlime/jlime-extras_1.0.6.bb: Feb 10 19:56:26 jlime-extras: Update version from 1.0.6 to 1.0.7 Feb 10 19:56:26 The newer version contains some changes in the startup scripts and Feb 10 19:56:26 configuration for mplayer. Feb 10 19:56:26 Signed-off-by: Alex Ferguson Feb 10 19:56:26 Signed-off-by: Kristoffer Ericson Feb 10 19:56:29 03Alex Ferguson  07master * raf8541c1ba 10openembedded.git/recipes/linux/ (3 files in 2 dirs): (log message trimmed) Feb 10 19:56:29 linux-jlime-ben-nanonote: Add support for USB networking Feb 10 19:56:30 Added jz4740-udc.patch from qi-hardware which adds support for Feb 10 19:56:30 usb networking. Feb 10 19:56:30 Added modified kernel config file which enables the above patch. Feb 10 19:56:30 Modified linux-jlime-ben-nanonote recipe for the above files. Feb 10 19:56:31 Signed-off-by: Alex Ferguson Feb 10 20:29:19 hi, could someone give me some advise on how to do this properly? http://pespin.espeweb.net/patches/0002-xorg-xserver-common.inc-change-DISTRO_XORG_CONFIG_MA.patch Feb 10 20:30:05 I want to set DISTRO_XORG_CONFIG_MANAGER_shr to empty but ony for a scpecifc machine Feb 10 20:30:21 pespin grep recipes Feb 10 20:30:29 there are lot of examples Feb 10 20:30:41 for instance in the linux dir Feb 10 20:31:33 woglinde, I know I can set it for a specific machine using DISTRO_XORG_CONFIG_MANAGER_machine-name Feb 10 20:31:45 but I don't know how to set it only for a specific distro Feb 10 20:32:20 woglinde, what can I grep for to see examples? Feb 10 20:36:48 hm ah Feb 10 20:40:33 uh Feb 10 20:40:34 Parsing recipes...ERROR: Error parsing /home/users/builder/openembedded/recipes/tslib/tslib_git.bb: database is locked Feb 10 20:40:38 what the hell? Feb 10 20:44:53 there is an intermitent problem with the parser/database locking.. Feb 10 20:45:11 (assuming this is a fresh / new build) just remove the tmp directory and retry.. Feb 10 20:45:40 I belive tmp/cache is where the bad lock gets held.. Feb 10 20:48:45 hi, anyone can help this message: Traceback (most recent call last): File "/home/me/oe/bitbake/bin/bitbake", line 234, in ret = main() File "/home/me/oe/bitbake/bin/bitbake", line 226, in main return ui_main(ServerCommunicator(ui_channel), event_queue) File "/home/me/oe/bitbake/lib/bb/ui/knotty.py", line 152, in main parseprogress = new_progress("Parsing recipes", event.total).start() File "/home/me/oe/bitbake/ Feb 10 20:49:09 AssertionError Feb 10 20:50:34 after bitbake console-image Feb 10 20:51:28 I've not seen tha specific callback before.. but based on the messages, it looks like it might be due to a bad recipe somewhere.. Feb 10 20:51:32 (but thats just a guess) Feb 10 20:52:22 I am new to oe. I have no clue what is wrong Feb 10 20:53:06 whats your bitbake version? Feb 10 20:53:22 I did not modify any recipe Feb 10 20:53:54 woglinde, how can I see the bitbake version? Feb 10 20:54:09 what did you install? Feb 10 20:54:23 bitbake and oe Feb 10 20:54:39 yeah but how installed you bitbake? Feb 10 20:54:44 from air Feb 10 20:54:46 or water? Feb 10 20:55:02 git clone Feb 10 20:55:11 ah Feb 10 20:55:11 woglinde_: I prefer mud, gives a more intense flavor Feb 10 20:55:19 okay sou have the master version Feb 10 20:55:43 but seems you didnt follw the steps to gettting started Feb 10 20:56:52 http://www.openembedded.org/index.php/Getting_started Feb 10 20:56:54 might be, this is the first time, so there might be somewhere wrong Feb 10 20:58:00 thank you woglinde, I'll try to do it again. Feb 10 21:01:23 * Crofton|work is hacking at verilog Feb 10 21:01:32 maybe we should rewrite OE in verilog? Feb 10 21:02:42 lol Feb 10 21:37:18 Any chance someon could help me with this? http://lists.linuxtogo.org/pipermail/openembedded-users/2011-February/001226.html Feb 10 21:41:27 atl197111, use external-toolchain-generic Feb 10 21:41:45 see my related email today about someone else needing to use an external toolchain Feb 10 21:47:37 Tartarus: having trouble finding email where is that posted? Feb 10 21:48:58 Tartarus: n/mfound it Feb 10 22:17:52 Anyone else think the TSC should contain Frans+Koen, or neither? Feb 10 22:18:06 :P Feb 10 22:18:41 ? Feb 10 22:19:33 those guys seem to not see eye to eye. I think in order to have balance, either they should both have a contribution to the direction of OE, or neither should. Feb 10 22:20:41 Most of the conflict on the lists is coming from them. Perhaps its not resolvable. Feb 10 22:21:10 anyway... interim TSC is fine. Feb 10 22:35:33 grg, I think the current set of TSC will will work together well Feb 10 22:35:45 and they are all very active in OE and OE realted projects Feb 10 22:36:02 I dont doubt that. Feb 10 22:41:29 grg: yeah, I think you are probably right Feb 10 22:42:53 +1 for Frans+Koen Feb 10 23:01:55 well you all get to vote on that soon Feb 10 23:07:01 regarding the tsc elections, is the order in which you listed the members the order in which their positions will come up for election? Feb 10 23:08:41 pb_: no, it was truly random order (ie the order thunderbird put their names when I searched for word TSC) Feb 10 23:09:36 the order was alphabetical Feb 10 23:09:40 I think Feb 10 23:09:51 well, I tried to make it alpabetical Feb 10 23:10:08 XorA, I reordered the names from your draft :) Feb 10 23:10:10 oh, alphabetical by first name Feb 10 23:10:11 so it is Feb 10 23:10:38 again a random selection technique :-) Feb 10 23:10:45 heh Feb 10 23:10:55 it is up to them how the order works Feb 10 23:11:12 heh I just figured that out as well.. I thought it had been randomized.. ;) Feb 10 23:12:03 * XorA kicks Crofton|work anyway for messing with perfection Feb 10 23:12:07 heh Feb 10 23:12:20 this avoids conspiracy theories about the order Feb 10 23:13:54 bah whats OE without a good bit of gossip Feb 10 23:14:22 I think that can be said about almost any project Feb 10 23:14:41 I should have sorted by irc nick Feb 10 23:14:49 we should place some info to wikileaks Feb 10 23:15:42 (for those that don't know, I'm the Mark Hatle on the TSC list) Feb 10 23:19:03 ok, off to watch Spooks and see if Harry saves England again Feb 10 23:19:26 yo Mark Feb 10 23:19:30 get to work :-D Feb 10 23:19:43 actually I'm just about done with my day.. :) Feb 10 23:23:41 fray, what TZ are you in? Feb 10 23:24:07 central US -- -6 (-5 w/ DST) Feb 10 23:24:11 ah Feb 10 23:24:19 est here Feb 10 23:24:41 not many nerds in cst it seems Feb 10 23:24:53 although I think cbrake and mwester are Feb 10 23:25:08 my hours seem to shift between EST and PST.. :P Feb 10 23:25:22 * XorA cant tell the difference between his Taiwan cash and japanese cash Feb 10 23:25:35 fray: your in OE now, no sleep allowed Feb 10 23:25:58 don't worry, Yocto hasn't gotten me much sleep either Feb 10 23:27:12 XorA, I wonder if that android app where you take a photo and feed it to the google would help with your cash issue Feb 10 23:30:00 hehe.. Feb 10 23:30:27 OE and sleep are mutually exclusive Feb 10 23:37:08 Crofton|work: wikipedia knew Feb 10 23:37:19 Crofton|work: you mean goggles BTW Feb 10 23:40:37 03Yu Ke  07master * rae008059b3 10bitbake.git/lib/bb/fetch2/hg.py: Feb 10 23:40:37 bb.fetch2.hg: add hg urldata_init Feb 10 23:40:37 move the hg specific urldata init from localpath to urldata_init Feb 10 23:40:37 so that it can be called early Feb 10 23:40:37 (From Poky rev: f684ff18a2b9565823a41750af369dee392f6142) Feb 10 23:40:37 Signed-off-by: Yu Ke Feb 10 23:40:38 Signed-off-by: Richard Purdie Feb 10 23:40:47 03Yu Ke  07master * r99c81a1ae3 10bitbake.git/lib/bb/ (6 files in 2 dirs): (log message trimmed) Feb 10 23:40:47 Fetcher: break the "SRCREVINACTION" deadlock Feb 10 23:40:47 Current fetcher has annoying "SRCREVINACTION" deadlock, Feb 10 23:40:47 which occurs when SRCREV=${AUTOREV}=@bb.fetch.get_srcrev(): Feb 10 23:40:47 get_srcrev()->setup_localpath()->srcrev_internal_helper() Feb 10 23:40:48 ->evaluate SRCREV->get_srcrev() Feb 10 23:40:48 current fetcher resolve the deadlock by introducing a Feb 10 23:40:49 03Yu Ke  07master * ra8f2315078 10bitbake.git/lib/bb/fetch2/ (13 files): Feb 10 23:40:49 bb.fetch2: rename "go" with "download" to better reflect its functionality Feb 10 23:40:50 no functional change Feb 10 23:40:50 (From Poky rev: e05918937c515dff845fcb4c9e94f8ecbea8c957) Feb 10 23:40:51 Signed-off-by: Yu Ke Feb 10 23:40:51 Signed-off-by: Richard Purdie Feb 10 23:40:52 03Yu Ke  07master * rc557a67a79 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Feb 10 23:40:53 Fetcher: only set __BB_DONT_CACHE when SRCREV = "${AUTOREV}" Feb 10 23:40:54 we should cache SRCREV whenever possible, the only exception is Feb 10 23:40:54 when SREREV is auto rev. so change the logic to only set __BB_DONT_CACHE Feb 10 23:40:55 at SRCREV = "${AUTOREV}" case Feb 10 23:41:06 Signed-off-by: Richard Purdie Feb 10 23:41:07 03Richard Purdie  07master * r8e1f6bfe1e 10bitbake.git/lib/bb/msg.py: Feb 10 23:41:08 bitbake/msg: Ensure lower level debug messages have DEBUG prefix and reuse log level values from formatter Feb 10 23:41:08 (From Poky rev: 7586adb360d8075d3e97184dfcafb1b13ce5f838) Feb 10 23:41:09 Signed-off-by: Richard Purdie Feb 10 23:41:09 03Yu Ke  07master * rd6fac93d81 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Feb 10 23:41:10 bb.fetch2: revise the Fetch.unpack API Feb 10 23:41:10 change the unpack to use the urldata and rootdir parameter Feb 10 23:41:11 - urldata is the FetchData instance Feb 10 23:41:11 - rootdir is the dir to put the extracted source. the original unpack Feb 10 23:41:12 use current dir (os.getcwd) as destination dir, which is not flexible Feb 10 23:41:12 and error-prone (error will occur if caller not chdir to dest dir) Feb 10 23:41:13 03Yu Ke  07master * r190896c095 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:41:13 bb.fetch2.git.py: add git urldata_init Feb 10 23:41:14 move the git specific urldata init from localpath to urldata_init Feb 10 23:41:15 so that it can be called early Feb 10 23:41:16 (From Poky rev: 54e34f6e255d1717beada23638a5783c9dda42ea) Feb 10 23:41:16 Signed-off-by: Yu Ke Feb 10 23:41:16 Signed-off-by: Richard Purdie Feb 10 23:41:17 03Saul Wold  07master * r7a73e39690 10bitbake.git/lib/bb/utils.py: Feb 10 23:41:29 (From Poky rev: f12e71484593039cd58b6e7fadd038b28b05d849) Feb 10 23:41:30 Signed-off-by: Yu Ke Feb 10 23:41:31 03Yu Ke  07master * rcd3705347a 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:41:31 bb.fetch2: remove the obsolate Fetch.try_mirrors referrence Feb 10 23:41:31 Fetch.try_mirrors is no longer exists, so the code is obsolate Feb 10 23:41:32 (From Poky rev: 733de7596c2ed78a846541b3290f01c21ff96606) Feb 10 23:41:33 Signed-off-by: Yu Ke Feb 10 23:41:33 (13 lines omitted) Feb 10 23:41:33 03Richard Purdie  07master * r2f7e2b2d79 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:41:34 bitbake/fetch2: Ensure the local revision counter takes a default value of 0, not None Feb 10 23:41:34 (From Poky rev: 05954ef4d7d882f34e2bb1f3bc44ad6f80c11d4c) Feb 10 23:41:35 Signed-off-by: Richard Purdie Feb 10 23:41:42 03Yu Ke  07master * rdee27c176a 10bitbake.git/lib/bb/fetch2/ (__init__.py git.py): (log message trimmed) Feb 10 23:41:43 git.py: split download to download() and build_mirror_data() Feb 10 23:41:43 the download is to fetch the source from URL, the build_mirror_data is Feb 10 23:41:43 to create the mirror tar ball. the original go() method mix them together, Feb 10 23:41:43 it is more clean to split them. Feb 10 23:41:43 (From Poky rev: ef918a72de97fd2189e1c8487e371d13e18088fd) Feb 10 23:41:44 Signed-off-by: Yu Ke Feb 10 23:41:45 03Yu Ke  07master * ra605deb12a 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Feb 10 23:41:45 bb.fetch2: add "BB_NO_NETWORK" option Feb 10 23:41:45 Sometime user want a purely local fetching, i.e. using local mirror without Feb 10 23:41:46 any remote netowrk access. BB_NO_NETWORK option is introduced for this purpose Feb 10 23:41:46 check_network_access() is the guard for BB_NO_NETWOKR option. it should be Feb 10 23:41:50 put in any place that fetcher use network access Feb 10 23:41:50 (From Poky rev: 098e8ded339f3bf864f3bad9871028176f70b12b) Feb 10 23:41:50 03Richard Purdie  07master * r2cce5bd9dd 10bitbake.git/lib/bb/__init__.py: Feb 10 23:41:50 __init__.py: Fix debug log level handling to correct debug output Feb 10 23:41:51 (From Poky rev: d7eebbe9dbf0d790d4af93466f5c27127cae0999) Feb 10 23:42:02 Any other approach such as the existing manipulations of localpath Feb 10 23:42:03 internally to the fetcher are prone to errors, races and other issues. Feb 10 23:42:03 03Richard Purdie  07master * r9188a6a7db 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:04 bitbake/fetch2: Remove old local file acceleration code Feb 10 23:42:04 Since local mirror fetches are always symlinked from the download directory Feb 10 23:42:05 directly, there is no need for this premirrors hack which doesn't cover Feb 10 23:42:05 mirrors and also abuses the localpath variable with inconsistent results. Feb 10 23:42:06 (From Poky rev: 282a828f3dc373d8f1397827ebbe1be1c54f2d2a) Feb 10 23:42:06 Signed-off-by: Richard Purdie Feb 10 23:42:07 03Richard Purdie  07master * r2217e9af98 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:07 bitbake/fetch2: When encoding a file:// url, drop user and host information Feb 10 23:42:08 When processing a cvs SRC_URI to a file:// mirror, the user and host information Feb 10 23:42:09 will break the mirror processing. This patch addresses it by only constructing Feb 10 23:42:09 valid urls. Feb 10 23:42:09 (From Poky rev: 7f99605562119a13a2510a3c990e3cf577ad764e) Feb 10 23:42:10 Signed-off-by: Richard Purdie Feb 10 23:42:11 03Richard Purdie  07master * re8878a7d97 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:42:11 bitbake/fetch2/git: Ensure target directory exists when copying files Feb 10 23:42:12 (From Poky rev: adfa6c40dadebb18bfd457859300d8c093b007f7) Feb 10 23:42:12 Signed-off-by: Richard Purdie Feb 10 23:42:24 (From Poky rev: 7e4fbfc1c1887a1a0507b60244aa53b8b1994edd) Feb 10 23:42:24 Signed-off-by: Richard Purdie Feb 10 23:42:24 03Richard Purdie  07master * r61983b9a8b 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:26 bitbake/fetch2: Drop unused parameter for localpath() and update comments Feb 10 23:42:26 (From Poky rev: 8daab5b95157dda6854fe6bf1929f911fe3cf25e) Feb 10 23:42:26 Signed-off-by: Richard Purdie Feb 10 23:42:27 03Richard Purdie  07master * rbd4a7ec55c 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:28 bitbake/fetch2: Simplify localpath variable handling FetchData init Feb 10 23:42:29 (From Poky rev: 49a022d25d35115e7286e2ca2530566da2d71aa8) Feb 10 23:42:29 Signed-off-by: Richard Purdie Feb 10 23:42:30 03Richard Purdie  07master * rf422c499b1 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:30 bitbake/fetch2: Add missing parameter to localcount_internal_helper Feb 10 23:42:31 (From Poky rev: 08cd6c1cb9639e958e0c60a02e317a22cf43f880) Feb 10 23:42:31 Signed-off-by: Richard Purdie Feb 10 23:42:37 03Richard Purdie  07master * rb987a08a03 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:37 bitbake/lib/bb/fetch2: Assign a default name in the names array as empty strings as names cause problems for python Feb 10 23:42:37 (From Poky rev: a55d86b4051f6d063f9a67db026f7da6f9b50cc6) Feb 10 23:42:37 Signed-off-by: Richard Purdie Feb 10 23:42:41 03Richard Purdie  07master * r04e260d5f2 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Feb 10 23:42:42 bitbake/fetch2: Drop old md5 handling code Feb 10 23:42:42 Drop some old md5 functions since we have improved functionality now which includes Feb 10 23:42:42 sha256 checksum support. This stops each download being md5 checksumed twice. Feb 10 23:42:42 Also change ".md5" stamp extentions to ".done" to better describe its use as a Feb 10 23:42:42 download complete marker file and no longer write the md5 sum to the files. Feb 10 23:42:43 (From Poky rev: 74b71864fed79ce60e721945c8e239b3ebf49200) Feb 10 23:42:43 03Richard Purdie  07master * rfa426b73b0 10bitbake.git/lib/bb/fetch2/ (13 files): Feb 10 23:42:44 bitbake/fetch2: Rename Fetch class to FetchMethod Feb 10 23:42:44 (From Poky rev: ab0dd1397491478ee6149283e5ba8775dd8cdc3b) Feb 10 23:42:45 Signed-off-by: Richard Purdie Feb 10 23:42:45 03Richard Purdie  07master * r7ffcda8bfa 10bitbake.git/lib/bb/fetch2/ (__init__.py osc.py): Feb 10 23:42:46 bitbake/fetch2: Make srcrev_internal_helper a normal function, doesn't belong in the FetchMethod class Feb 10 23:42:57 bitbake/fetch2: Use True instead of integer values Feb 10 23:42:57 (From Poky rev: 7202a77134029cb37540c785ce0161a4dd574853) Feb 10 23:42:58 Signed-off-by: Richard Purdie Feb 10 23:42:58 03Richard Purdie  07master * ra6ea08e7ab 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:42:59 bitbake/fetch2: Drop name/override ordering backwards compatibility code Feb 10 23:42:59 (From Poky rev: 8f2abf4a9f000d42e98c4936e393bd5033a1af48) Feb 10 23:43:01 Signed-off-by: Richard Purdie Feb 10 23:43:01 03Richard Purdie  07master * rac8982c2e0 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:43:01 bitbake/fetch2/git: Fix localpath to point at the clone repo since we no longer always generate a mirror tarball and it isn't a good guide to fetcher success Feb 10 23:43:02 (From Poky rev: 917d3e9697acefe308e7139e86df37a072ee3500) Feb 10 23:43:02 Signed-off-by: Richard Purdie Feb 10 23:43:03 03Richard Purdie  07master * r5ef9b378f5 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:43:03 bitbake/fetch2/git.py: Ensure that forcefetch operates in the correct directory for calling _contains_ref() Feb 10 23:43:04 (From Poky rev: 330886826770ff6ec1449dc375cb4c3604b2736b) Feb 10 23:43:04 Signed-off-by: Richard Purdie Feb 10 23:43:05 03Richard Purdie  07master * r2fd63c32aa 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:43:08 bitbake/fetch2/git: use clonedir as ud.localfile too since the mirror tarball may not exist Feb 10 23:43:08 (From Poky rev: 681bcf4e6b606dde2029d143805023a927285917) Feb 10 23:43:08 Signed-off-by: Richard Purdie Feb 10 23:43:08 03Richard Purdie  07master * r1174b2955e 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:43:09 bitbake/fetch2: Drop legacy CVSDATE support Feb 10 23:43:21 Signed-off-by: Richard Purdie Feb 10 23:43:25 03Richard Purdie  07master * ra9e70ef8eb 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:43:25 bitbake/fetch2: Update mirror processing to ensure we look for mirror tarballs Feb 10 23:43:25 (From Poky rev: 94faffdaf6c13ce59987aab28383d66a9a0bf100) Feb 10 23:43:25 Signed-off-by: Richard Purdie Feb 10 23:43:26 03Richard Purdie  07master * r40644b5f33 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:43:26 bitbake/fetch2:Fetch Make using the fn based cache optional Feb 10 23:43:27 (From Poky rev: 500c66337c7cb5e3044a02ef761097713e47f523) Feb 10 23:43:27 Signed-off-by: Richard Purdie Feb 10 23:43:28 03Richard Purdie  07master * r84e0ae4e97 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:43:28 bitbake/fetch2: Fix pickling issues with fetcher exceptions Feb 10 23:43:29 See the problems in http://bugs.python.org/issue1692335, need to set self.args Feb 10 23:43:45 correctly. Feb 10 23:43:45 (From Poky rev: d4b4b48addfa781d7b94965e0477974c3fb6dbb3) Feb 10 23:43:45 Signed-off-by: Richard Purdie Feb 10 23:43:45 03Richard Purdie  07master * rd0ffe023c4 10bitbake.git/lib/bb/fetch2/ (11 files): Feb 10 23:43:45 bitbake/fetch2: Rewrite and improve exception handling, reusing core functions for common operations where possible Feb 10 23:43:46 (From Poky rev: d08397ba4d1331993300eacbb2f78fcfef19c1cf) Feb 10 23:43:47 Signed-off-by: Richard Purdie Feb 10 23:43:47 03Saul Wold  07master * rd1a37060cd 10bitbake.git/lib/bb/fetch2/ (bzr.py cvs.py perforce.py ssh.py svk.py wget.py): Feb 10 23:43:48 fetch2: add runfetchcmd to import for fetchers Feb 10 23:43:48 (From Poky rev: 232b6f3c92928c333ad1201aa8eb3706e7251cdf) Feb 10 23:43:49 (31 lines omitted) Feb 10 23:43:49 03Mark Hatle  07master * r3372d84fa9 10bitbake.git/lib/bb/fetch2/__init__.py: (log message trimmed) Feb 10 23:43:56 fetch2: Add SRPM knowledge Feb 10 23:43:56 Enable the fetcher to be able to unpack and SRPM. By default the system will Feb 10 23:43:56 unpack the contents of the SRPM into the WORKDIR. Feb 10 23:43:56 A new syntax "unpack=file" was developed for the SRC_URI, to allow for a Feb 10 23:43:57 recipe to extract a specific file within an SRPM. An unpack operation will Feb 10 23:44:05 then be executed on the extracted file. Feb 10 23:44:05 03Richard Purdie  07master * r25204a6a81 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:44:05 bitbake/fetch2: Move symlink handling into try_mirror where is belongs instead of the main download function Feb 10 23:44:05 (From Poky rev: ee1a9c0476cc4b2ce9dfb0faa29a1371a8517c40) Feb 10 23:44:06 Signed-off-by: Richard Purdie Feb 10 23:44:06 03Richard Purdie  07master * r2bc5a25100 10bitbake.git/lib/bb/fetch2/__init__.py: Feb 10 23:44:07 bitbake/fetch2: Fix negated if check for BB_FETCH_PREMIRRORONLY Feb 10 23:44:07 (From Poky rev: 29ed2c6e9a0c3cc57c5bbaf3c53e1cff8586c51c) Feb 10 23:44:08 Signed-off-by: Richard Purdie Feb 10 23:44:08 03Richard Purdie  07master * re7534cb70a 10bitbake.git/lib/bb/fetch2/git.py: Feb 10 23:44:10 bitbake/fetch2/git: Write mirror tarballs if enabled and they don't exist, also set a default value for mirror tarball generation Feb 10 23:44:10 (From Poky rev: 59a08262aba2d2b9b8b299a2818fb4cfe13b9909) Feb 10 23:44:10 Signed-off-by: Richard Purdie Feb 10 23:45:10 * zenlinux_laptop notes that Richard has been up to no good lately.... ;) Feb 10 23:56:57 03Saul Wold  07master * rdb2abcd641 10bitbake.git/lib/bb/fetch2/ (__init__.py cvs.py git.py local.py svn.py): Feb 10 23:56:58 fetch2: Correct the clean() mechanism for the fetcher2 code Feb 10 23:56:58 This create a clean() method in each of the fetcher modules Feb 10 23:56:58 and correctly cleans the .done stamp file and lock files Feb 10 23:56:58 (From Poky rev: 14dea89521c0c648e8e543388096a6dcd6d4f2e0) Feb 10 23:56:58 Signed-off-by: Saul Wold Feb 10 23:56:58 Signed-off-by: Richard Purdie Feb 11 00:02:59 well.. time to fire testbuilder up on new release testing branch.. Feb 11 00:29:02 ok back home so I don't have my work email to continue the discussion :) so did you mean OE is pulling the libs from STAGING_DIR rather than from my external toolchain path? Feb 11 00:29:58 it seemed to me like nano just lacked a -lncurses. it looked like a more simple substitution error to me since there was a goofy -l/home/something/. I didnt track it down at the time Feb 11 00:49:03 kergoth, is there a bitbake-1.11 coming anytime soon? wondering when .bbappend will make it in a release Feb 11 00:49:16 tharvey: not on the bitbake mailing list? Feb 11 00:49:27 oops nope... let me go read up on that :) Feb 11 00:49:28 sry Feb 11 00:51:04 where is the current bitbake mailing list? Feb 11 00:51:16 http://news.gmane.org/gmane.comp.sysutils.bitbake.devel/ is what I'm reading Feb 11 00:51:37 kergoth, nice... looking forward to 1.12 soonish Feb 11 00:55:09 fray: at least I got the busybox compiled before giving up for the day Feb 11 01:00:01 demigod2k :) Feb 11 01:00:57 so one thing I don't get... the *.bb files, are they code (ie. loaded right into the same namespace like bitbake) or are they parsed as datafiles to drive the process? Feb 11 01:02:02 both Feb 11 01:02:09 because we like to be in pain, all the time:) Feb 11 01:02:12 they are fully parsed -- but they contain code used to run specific items Feb 11 01:02:54 the inherit rules load default build instructions.. the items in the do_.... () { ... } statements override, append, modifyt he default rules.. Feb 11 01:04:13 I was leaning toward the code side since I saw so many files that have these fairly-random seeming things that looked like variable names to me. for example in the external-toolchain-csl.bb there's stuff like INSANE_SKIP_nscd = True Feb 11 01:04:43 it was like... ok. looks like a variable definition. how does that get pulled in somewhere except if the entire thing was a giant #include *.bb Feb 11 01:05:35 yes, the variables are added to hte local data when the recipes are parsed.. Feb 11 01:05:53 the inbuilt functions and/or user provided ones can then use those data functions to do things.. Feb 11 01:06:16 ok that makes me think like the *.bb all get linked in and it's one giant script/program running Feb 11 01:06:16 something like INSANE_SKIP_nscd -- when the nscd package is being processed automatically translates into INSANE_SKIP Feb 11 01:06:41 so when something looks to see if INSANE_SKIP == True, then it will trigger it.. but only for the nscd package Feb 11 01:07:00 no it's actually parsed.. but it's all parsed at the beginning of the program Feb 11 01:07:17 that creates the overall data sets.. which are then manipulated and transformed as the build actions occur.. Feb 11 01:07:30 hm. interesting. I guess I'm constrasting against something like ant or msbuild that might be driven by an XML file with a strict schema. this is basically code so anything goes in here. right? Feb 11 01:07:31 this allows for global defaults with recipe or context specific overrides Feb 11 01:07:53 there is a format / policy.. but it's not "formal" like XML Feb 11 01:08:26 or maybe like an ini file. it's not like name-value pairs, there's a standard way to do it but its still ultimately code Feb 11 01:08:33 this goes back to the we really need to document all of the switches and such.. the core set of variables is well documented in the recipe examples I've seen.. (as well as the recipes themselves by usage).. it's things like "INSANE_SKIP" that you just need to know what they do Feb 11 01:09:12 bitbake has it's own scripting (lack of a better term) language... thats parsed and allows a mix of raw variables, python and shell scripts Feb 11 01:09:34 variables are really just meta data in a non-strict format Feb 11 01:09:47 hm. I see it kind of like how buildroot does it. with makefiles they just assume "there must exist a rule called xxx" in each makefile Feb 11 01:10:15 it does some extra crap around there, you can put extra crap in there yourself, but the API is that it calls some rule called XX_clean, or XX_install, or whatever at each stage Feb 11 01:10:17 there is a set of standard actions and rules, with defaults -- some of which are empty Feb 11 01:10:40 then the inherit autotools (or similar) starts to fill in those defaults with actions that know how to build software conforming to GNU autotools.. etc Feb 11 01:11:14 another thing I couldn't quite figure out, like in external-toolchain-* there are a bunch of depends, and other places there are a ton of virtual/*. Are those documented somewhere? Feb 11 01:11:22 ya.. the actions are "do_fetch", "do_unpack", "do_patch", "do_configure", "do_compile", "do_install", "do_package"... and a few others Feb 11 01:11:50 unfortunately external-toolchain- may be the most complicated possible example but those names seemed to be fairly random. like I need to have a libc package. or a glibc package. or... well... whatever it's looking for in that particular place :) Feb 11 01:12:08 depends come from the recipes themelves.. by default the recipe is a provide that matches depends.. for the virtuals, individual recipes (or other files) need to say "I provide this virtual item" Feb 11 01:13:07 it might've been nasty here since OE tries to provide that stuff itself somehow (even though, well, it cannot possibly make a compiler for my chip). so it was my job to know those and provide my preferred gcc, g++, glibc, gcc-internal, etc. Feb 11 01:13:14 as part of the parsing.. there are also a number of default variables that all recipes contain.. like PN is the name of the recipe.. PV is the version.. Feb 11 01:13:16 * fray has to go.. later! Feb 11 01:13:17 luckily the -csl was a good starting place but its not like I knew what those names should be Feb 11 01:13:40 ya those ones are at least documented in the usermanual its the base packages mainly. later! **** ENDING LOGGING AT Fri Feb 11 02:59:57 2011