**** BEGIN LOGGING AT Tue Jan 04 02:59:58 2011 Jan 04 03:29:00 It looks like the recipe is not being stamped, dunno why. Jan 04 03:29:08 My layer looks like: http://pastebin.com/n10VRA8G Jan 04 03:29:38 (this is the important part for it, since just linux is not controlled properly) Jan 04 03:30:04 it looks like my PR change has caused it but I need a way to track the PR bump so how to do that? Jan 04 04:24:33 GNUtoo|laptop: mind to take a look in ml about .bbappend issue? Jan 04 04:24:38 GNUtoo|laptop: I just mailed it Jan 04 04:24:59 ? Jan 04 04:25:21 I can look but why me? Jan 04 04:26:17 GNUtoo|laptop: because you use layers AFAIK and you're friendly :-D Jan 04 04:26:18 hehehe Jan 04 04:26:26 ah? Jan 04 04:26:26 LOL Jan 04 04:26:31 I don't use layers Jan 04 04:26:34 grr Jan 04 04:26:39 sorry Jan 04 04:26:43 I can look Jan 04 04:26:43 you were my last hope Jan 04 04:26:44 ok Jan 04 04:26:45 :P Jan 04 04:26:47 np Jan 04 04:26:50 but I know nothing about layers Jan 04 04:26:56 apart if it's a simple issue Jan 04 04:27:06 I'll let kernel hacking board bringup aside and look Jan 04 04:28:41 I looked Jan 04 04:28:46 and I don't understand Jan 04 04:28:52 because I never used layers Jan 04 04:29:31 but I've an idea Jan 04 04:29:35 bitbake -e the PR Jan 04 04:29:41 and findout what's the PR Jan 04 04:29:54 otavio, ^^^ Jan 04 06:44:25 hi ericben Jan 04 06:44:28 ericben, http://pastebin.com/xur6BC8F Jan 04 08:05:28 morning Jan 04 08:17:26 good morning Jan 04 08:42:23 gm Jan 04 09:33:19 tasslehoff: ping Jan 04 09:33:31 hi mckoan Jan 04 09:33:35 mckoan: instant pong Jan 04 09:33:39 lol Jan 04 09:34:07 tasslehoff: on Sep 21 you faced to a problem with "error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory" Jan 04 09:34:15 woglinde: hi Jan 04 09:34:26 tasslehoff: here the same now Jan 04 09:34:33 tasslehoff: did you solve it? Jan 04 09:36:00 mckoan: it was solved for me, by a commit in ... gcc-cross, or whats-its-name. it was changed to link libmpfr and libgmp statically instead of dynamically, if I remember correct Jan 04 09:36:36 tasslehoff: did you push that commit? Jan 04 09:36:37 mckoan: three or four weeks ago the same thing happened again, but another upstream pull fixed it again Jan 04 09:37:04 mckoan: someone here fixed it upstream, and I just pulled and tested. Jan 04 09:37:58 I built a SDK on 18/12 on a debian64 and using the SDK on ubuntu64 10.x gives that error Jan 04 09:38:34 mckoan: I see that I compiled an SDK with said error Dec 10. Then I did a pull and built an ok one on Dec 14. Jan 04 09:39:02 tasslehoff: hmmmm... Jan 04 09:39:04 that's x86 though Jan 04 09:39:13 no idea if it matters Jan 04 09:39:30 tasslehoff: may be an x86_64 issue Jan 04 09:44:24 tasslehoff: ok I built on 18/12 with pull done on Tue Dec 7, I have a chance :-D Jan 04 09:44:50 tasslehoff: I am retrying, thank you Jan 04 09:45:51 mckoan: np. good luck :) Jan 04 09:50:04 good morning, best wishes for this new year. Jan 04 09:50:19 ericben: thank you, to you too Jan 04 09:53:38 hi ericben Jan 04 10:51:00 03Simon Busch  07org.openembedded.dev * rd85bd16514 10openembedded.git/recipes/freesmartphone/msmcommd_git.bb: Jan 04 10:51:00 msmcommd: add missing dbus service file to package Jan 04 10:51:00 Signed-off-by: Simon Busch Jan 04 10:51:02 03Simon Busch  07org.openembedded.dev * r12b9367140 10openembedded.git/recipes/palmpre/ (read-tokens/read_tokens read-tokens_git.bb): Jan 04 10:51:02 read_tokens: add initscript to read tokens on boot Jan 04 10:51:02 Signed-off-by: Simon Busch Jan 04 10:51:03 03Simon Busch  07org.openembedded.dev * r5e75168f83 10openembedded.git/recipes/serial-utils/serial-forward_git.bb: Jan 04 10:51:04 serial-forward: bump SRVREV Jan 04 10:51:04 Signed-off-by: Simon Busch Jan 04 10:51:05 03Simon Busch  07org.openembedded.dev * r7e02d6b8d7 10openembedded.git/recipes/linux/linux-palmpre_git.bb: Jan 04 10:51:05 linux-palmpre: bump SRCREV Jan 04 10:51:05 Signed-off-by: Simon Busch Jan 04 10:51:07 03Simon Busch  07org.openembedded.dev * r7d12344457 10openembedded.git/recipes/freesmartphone/ (msmcommd/msmcommd msmcommd_git.bb): Jan 04 10:51:07 msmcommd: add initscript to start on system boot Jan 04 10:51:07 Signed-off-by: Simon Busch Jan 04 10:51:11 03Simon Busch  07org.openembedded.dev * r9db95ee2ab 10openembedded.git/recipes/serial-utils/pty-forward-native.bb: Jan 04 10:51:11 pty-forward-native: bump SRCREV Jan 04 10:51:11 Signed-off-by: Simon Busch Jan 04 10:51:12 03Simon Busch  07org.openembedded.dev * r20e3f45a62 10openembedded.git/recipes/palmpre/read-tokens_git.bb: Jan 04 10:51:12 read_tokens: bump SRCREV Jan 04 10:51:12 Signed-off-by: Simon Busch Jan 04 10:51:14 03Frederik 'playya' Sdun  07org.openembedded.dev * r524cd829cd 10openembedded.git/recipes/xorg-xserver/ (xserver-xorg-conf/palmpre/xorg.conf xserver-xorg-conf_0.1.bb): Jan 04 10:51:14 xserver-xorg-conf: Update palmpre's xorg.conf Jan 04 10:51:14 Signed-off-by: Frederik 'playya' Sdun Jan 04 10:51:26 FSO's fsodeviced daemon. Jan 04 10:51:26 Signed-off-by: Simon Busch Jan 04 11:25:30 #msg chanserv unban ##tsc Jan 04 11:25:40 oops Jan 04 12:22:01 Hello; did someone see my message about the kernel recipe? Jan 04 12:27:20 (on ml) Jan 04 12:29:23 otavio, hi Jan 04 12:29:38 GNUtoo|laptop: hello Jan 04 12:30:43 ah the same message than yesterday Jan 04 12:30:54 otavio, did you bitbake -e to get the PR like I suggested? Jan 04 12:30:56 GNUtoo|laptop: yep; the PR is parsed correctly Jan 04 12:31:09 GNUtoo|laptop: I checked and the stamps files are also created Jan 04 12:31:14 ok Jan 04 12:32:07 * otavio is confused due that Jan 04 12:49:54 03Graeme Gregory  07org.openembedded.dev * r8d51ba82b8 10openembedded.git/recipes/gcc/gcc-4.2.2.inc: Jan 04 12:49:54 gcc-4.2.2.inc : to fix avr32 build apply the same .la file mangling as the Jan 04 12:49:54 gcc 4.2.4. I see the same problem as is commented on in the 4.2.4 file. Jan 04 13:10:39 I have been using slang 2.2.2 since I need to use newt in a project. Is it any objection to the update to it? Jan 04 13:11:08 i'd like to provide a custom /etc/network/interfaces file for an image, but I'm getting file name clashes between my config package and the netbase package. should I write a patch for netbase or is there some way to forcefully replace files from another package? Jan 04 13:11:27 03Koen Kooi  07org.openembedded.dev * r17796b0da2 10openembedded.git/recipes/ti/ (ti-dsplink.inc ti-dsplink/dsplink-BKL-fix.patch): Jan 04 13:11:27 ti-dsplink 1.65.00.03: better fix for BKL removal Jan 04 13:11:27 Signed-off-by: Koen Kooi Jan 04 13:15:39 beefheart: you can provide a specific file for your machine/distro Jan 04 13:18:14 otavio: ah, thanks Jan 04 13:34:33 03Bernhard Guillon  07org.openembedded.dev * r983568cfda 10openembedded.git/recipes/vlc/ (x264-r2245/uclibc_log2f_fix.HACK.patch x264_r2245.bb): Jan 04 13:34:33 x264-r2245: add a hack for uclibc - replace log2f(x) with logf(x)/logf(2) Jan 04 13:34:33 Modified to apply and to only be used for avr32 build which cant Jan 04 13:34:33 increment toolchain. Jan 04 13:34:33 Signed-off-by: Bernhard Guillon Jan 04 13:34:34 Signed-off-by: Graeme Gregory Jan 04 13:41:56 03Koen Kooi  07org.openembedded.dev * r76776f3d52 10openembedded.git/recipes/ti/ (2 files in 2 dirs): Jan 04 13:41:57 ti-local-power-manager 1.24.02.09: better fix for BKL removal Jan 04 13:41:57 Signed-off-by: Koen Kooi Jan 04 13:45:51 what is the correct way to modify /etc/modules.conf when creating an image? I need to add an alias but I've never used the update-modules stuff before Jan 04 13:47:36 tasslehoff: with today's version, SDK works Jan 04 13:52:24 mckoan: excellent :) Jan 04 14:23:23 any fosdem embedded devroom organizers here? Jan 04 15:03:15 03Bernhard Reutner-Fischer  07master * r884365228f 10bitbake.git/lib/bb/cache.py: (log message trimmed) Jan 04 15:03:15 cache: defer marking fn as clean Jan 04 15:03:15 Only mark fn as clean if it is clean. Jan 04 15:03:15 This saves us from removing (prematurely added) fn from our clean set Jan 04 15:03:15 and saves me a few percent of runtime (and misleading debugging output Jan 04 15:03:16 from remove()). Jan 04 15:03:16 Signed-off-by: Bernhard Reutner-Fischer Jan 04 15:03:17 03Bernhard Reutner-Fischer  07master * rba060160fd 10bitbake.git/lib/bb/data.py: Jan 04 15:03:18 data: fewer newlines for (un)export Jan 04 15:03:18 Previously we emitted two newlines for export and unexport. Jan 04 15:03:19 One newline for export and unexport is enough (and makes the scripts Jan 04 15:03:19 look better and a tad smaller). Jan 04 15:03:20 Signed-off-by: Bernhard Reutner-Fischer Jan 04 15:03:21 Signed-off-by: Richard Purdie Jan 04 15:03:21 03Bernhard Reutner-Fischer  07master * r413af91e56 10bitbake.git/lib/bb/event.py: Jan 04 15:03:22 event: fix unicode handler registration Jan 04 15:03:37 03Bernhard Reutner-Fischer  07master * r089dc31932 10bitbake.git/lib/bb/parse/parse_py/ConfHandler.py: Jan 04 15:03:37 ConfHandler: commentary typo fixes Jan 04 15:03:37 Signed-off-by: Bernhard Reutner-Fischer Jan 04 15:03:37 Signed-off-by: Richard Purdie Jan 04 15:40:13 * kergoth_ doesn't see himself doing any more proactive bitbake development, only what's required for work Jan 04 15:41:21 :-( Jan 04 16:07:17 kergoth_: I think thats sad. I've tried to talk about this but I'm not sure we're getting anywhere :( Jan 04 16:14:16 RP: the ui/server split was intended to help clean up the code. Since the server is now split off in its own process, it should be very easy to have it export an xmlrpc interface also. Jan 04 16:22:32 foerster: I understand the intent. The way its been handled isn't good though and if its so easy, why was this stuff removed? Jan 04 16:22:55 *sigh* Jan 04 16:23:15 where is the problem now? Jan 04 16:23:22 RP: It didn't appear as if xmlrpc was being used at all, so kergoth_ removed it for the time being Jan 04 16:23:23 why is everybody pissed? Jan 04 16:23:33 about this case Jan 04 16:23:48 03Simon Busch  07org.openembedded.dev * r9cec3724d3 10openembedded.git/recipes/freesmartphone/cornucopia.inc: Jan 04 16:23:48 cornucopia: bump SRCREV to latest version Jan 04 16:23:48 Signed-off-by: Simon Busch Jan 04 16:23:51 03Simon Busch  07org.openembedded.dev * r2ae0257100 10openembedded.git/recipes/freesmartphone/msmcomm.inc: Jan 04 16:23:51 msmcomm: bump SRCREV to latest version Jan 04 16:23:51 Signed-off-by: Simon Busch Jan 04 16:23:57 foerster: kergoth merged fixes to the xmlrpc backend which should have made it clear someone was using it Jan 04 16:24:15 RP: xmlrpc was broken in master, and had been for a while Jan 04 16:24:57 foerster: so a RFC to the mailing list might have been appropriate? Jan 04 16:25:11 RP: sounds reasonable. Jan 04 16:27:06 foerster: My big concern is that we've had discussions at OEDEM and on the mailing list about the overall roadmap for bitbake. Looking just at the changes in master, it could appear that roadmap had changed a lot Jan 04 16:27:43 foerster: I know I've made assumptions in various plans poky/yocto have based on that roadmap which is why I am concerned about this Jan 04 16:28:23 RP, so, hang on. Do you think some of the changes have made doing xmlrpc impossible / difficult? Jan 04 16:29:37 I think the issue is that some viewed bitbake as a library to use. The new changes make the bitbake backend more of a server in itself. Jan 04 16:33:01 Tartarus: What was a working fully functional abstraction was removed which is a regression to me. I don't think reimplementing it is impossible, how difficult it will be I don't know Jan 04 16:33:37 foerster: Making it more of a server is the direction we've collectively thought it should go Jan 04 16:33:50 foerster: If that isn't true, fine but it should be discussed Jan 04 16:34:09 RP: how is xmlrpc used? I don't know the use case. Jan 04 16:34:20 For eclipse tools, etc? Jan 04 16:34:39 foerster: Think of a UI on my laptop connecting to a remote build server Jan 04 16:34:45 RP, did the ability for other UIs get dropped, or just that specific one? Jan 04 16:34:51 I only see those specific ones being dropped Jan 04 16:35:29 RP: that case was being thought of, but instead of xmlrpc, it'll use the simpler mechanisms. Jan 04 16:35:54 .o(hm I would use pyro now any, thats the simplest) Jan 04 16:36:09 I keep seeing new screenshots / commits of the goggles UI, so I assume it's just that the xmlrpc UI would need to be updated for the current API Jan 04 16:36:59 foerster: What kind of simpler mechanism? Jan 04 16:37:15 Tartarus: Its all about the transport between the UI and the server Jan 04 16:37:19 python's multiprocessing that we're using will allow you to connect to a different machnie too Jan 04 16:37:35 foerster, yeah, but think non-python front-ends Jan 04 16:37:39 ie an Eclipse plugin Jan 04 16:37:43 foerster: Using what teansport? Jan 04 16:37:56 it just used python pickling over sockets Jan 04 16:37:58 transport Jan 04 16:38:13 uses* Jan 04 16:39:16 woglinde: no idea, RP is freaking out over nothing again. which is why I won't be doing proactive bitbake work, it's not worth the drama Jan 04 16:39:35 kergoth_: "again"? Jan 04 16:39:48 *sigh* Jan 04 16:40:00 rp what can I do that you are pleased again? Jan 04 16:40:06 * foerster thinks everybody is acting like children :) Jan 04 16:40:17 kergoth wgabt can I do that you are pleased again? Jan 04 16:42:15 kergoth_, it's not exactly nothing... Jan 04 16:42:35 Maybe we all need to take a 5 minute break and re think things Jan 04 16:42:44 * RP would be happy if we could just actualyl communate major changes before they're implemented Jan 04 16:43:11 If something does happen which turns out to cause problems instead of personal insults it would be good to find a way out of the siutation Jan 04 16:43:14 Tartarus: but it is. xmlrpc was broken. so it was dropped temporarily. it can be resurrected with one git command, and will be just as broken as it was, and it can be fixed from there. RP's too lazy to run a git command, so here we are Jan 04 16:43:46 kergoth_: If I just revert the commit, will the backend work? Jan 04 16:44:14 no, it'll be broken in a different way than it used to be, but will still be broken Jan 04 16:44:35 kergoth_: So its not just a git command ;-) Jan 04 16:44:47 I don't see how it being broken in one way is any worse than another Jan 04 16:44:49 RP, but kergoth is saying it wasn't working in master anyhow Jan 04 16:44:53 exactly Jan 04 16:44:53 Anyhow, in terms of action, I'm taking some. Poky is much more in sync with bitbake than it was Jan 04 16:45:05 Not perfectly yet but it is going to get there soon Jan 04 16:45:28 RP, prior to this round of updates / changes that it would need ot be updated for Jan 04 16:45:30 Tartarus: I'd question that as it was working in poky at least after some recent fixed which were merged Jan 04 16:45:45 poky is not master. maybe you don't get this anymore, but it remains the case Jan 04 16:45:57 personally, i don't want broken code sitting in master Jan 04 16:46:48 but, that's not my concern anymore Jan 04 16:46:53 kergoth_: Giving some opportunity to resolve things before deleting it would be nice though. Having it there also shows the intent to fix it up Jan 04 16:47:10 I think the intent has been and still is very clear Jan 04 16:47:50 What I'm interested in is a) How to we resolve this and get the problem fixed and b) How do we stop it happening again Jan 04 16:47:54 Again, I'm not seeing the problem. It was a temporary removal until it got fixed, and you freak out Jan 04 16:47:54 And we all agree on the intent, but kergoth has also been trying to leave the tree in a git bisect'able state, which isn't as nice with caveats Jan 04 16:48:19 RP, (a) bring back xmlrpc.py and update it for the current API Jan 04 16:48:48 Tartarus: and update Poky to stop all this stabbing I'm getting over it being out of sync Jan 04 16:48:51 (b) If you're swearing up and down, and I see that you are and believe you, that an RFC / whatever on the ML will get a timely (unless you're known on vacation) reply, how about we just do that? Jan 04 16:49:21 well, the overrides change to OE didn't get a reply from RP for a month or two, so I don't really see it being likely that we'll get timely responses to core changes Jan 04 16:49:27 but if we will, sure Jan 04 16:49:33 kergoth_, let history be history Jan 04 16:50:06 RP is saying his circumstances have changed and since he's an LF person not an Intel person, that's certainly true :)( Jan 04 16:50:08 :) Jan 04 16:50:39 kergoth_: I'm trying to resolve this. I've already suggested that if I miss something (and we all do), there are ways to assist this Jan 04 16:52:33 RP, so, does my a/b sound like a reasonable plan? Jan 04 16:53:02 Tartarus: I'm happy with both of them, yes. I'm already working actively on them too Jan 04 16:53:21 Great, now lets all take a deep breath Jan 04 16:53:24 _all_ Jan 04 16:53:51 kergoth_: on that note, what is the status of the poky-sync branch - is that ready to merge and are there any known outstanding problems? Jan 04 16:54:55 There's one remaining issue to my knowledge. Root filesystem construction fails due to an rpm "environment mismatch" when using it for a poky build Jan 04 16:55:41 kergoth_: No regressions fornon-poky use though? Jan 04 16:56:26 none that I've found, worked fine for the OE builds I ran, but we need more people to test it, as clearly a few builds with one or two configurations on my end isn't sufficient Jan 04 16:58:18 kergoth_, did you throw our autobuilder at it? Jan 04 16:58:25 Not that it's very blue atm, heh Jan 04 16:58:44 no, neither of us knew what needed to be done / how to do it Jan 04 16:58:48 * kergoth_ knows jack about hudson Jan 04 16:58:58 heh, k Jan 04 16:59:05 Where's the bitbake branch again? Jan 04 16:59:13 my github currently Jan 04 16:59:20 git://github.com/kergoth/bitbake - poky-sync branch Jan 04 17:03:02 RP: I see one issue in retrospect. the subprocess based bb.build provides a custom env to run in, with PATH/LC_ALL. because that isn't updated with os.environ contents, it's overriding that, and processes called by python tasks won't have the worker process env we set up in the runqueue. I'd say we just drop the env bits from bb.build, as I do in my build-shell-stdin branch, since the PATH crap is no longer necessary due to the runqueue env Jan 04 17:03:39 https://github.com/kergoth/bitbake/commit/f660940 Jan 04 17:04:18 course this means that the metadata or the runqueue would want to set LC_ALL=C, if we did it that way, or it should set that in exec_func, or it should keep the custom env, but add the os.environ bits to it (don't like that approach) Jan 04 17:05:30 kergoth_: I think that change is good and we should mandate the metadata should set this Jan 04 17:05:43 I think the poky environment script does currently but I don't like that Jan 04 17:06:17 agreed, though it is a compatibility concern, it should really be the metadata's responsibility, for the same reason we should move the env filtering responsibility there -- it knows what it's running, so it knows what env vars those things require Jan 04 17:07:46 Does someone has any guess about why linux gets rebuild every time with I use bbappend to set a PR? Jan 04 17:09:45 kergoth_: I definitely agree with the idea, quite how we do it I'm not 100% sure but I do agree Jan 04 17:11:13 at any rate, the above github commit will likely fix the rootfs construction bug. needs confirmation Jan 04 17:13:03 kergoth_/ foerster|away: Could you also try and help me and keep commits clean changing one thing per commit please? Jan 04 17:13:36 * RP understands things happen and I've screwed that up myself but it is good to do if at all possible Jan 04 17:13:52 That's always been the intent Jan 04 17:13:57 will continue to work on that Jan 04 17:14:18 kergoth_: thanks Jan 04 17:14:50 I think we all know how scm is supposed to be used, to assume otherwise is a joke. slipups happen Jan 04 17:15:39 kergoth_: :-) Jan 04 17:16:33 kergoth_: right, agreed Jan 04 17:32:55 hey when i build one of the kernels, where does bitbake get the recipe? there doesn't seem to be one for 2.6.36 Jan 04 17:33:11 nm Jan 04 17:33:14 bitbake -DDD Jan 04 17:34:55 ? Jan 04 17:35:47 run bitbake -DDD yourcommand Jan 04 17:35:51 gandhijee: bitbake's debugging arguments will show the recipes being parsed, so you seew here they come from Jan 04 17:36:01 o, cool. thanks Jan 04 17:36:04 thanks kergoth Jan 04 17:38:17 gm Jan 04 17:39:37 hi likewise Jan 04 17:44:07 hmm i don't understand how to add a kernel module for the x86 build Jan 04 17:44:17 the other archs have a defconfig that you can modify Jan 04 17:44:43 gandhijee external kernelsource or just .config? Jan 04 17:45:16 woglinde: ?? just from the .config. i want to add the coretemp module to my build but can't really figure it out. Jan 04 17:45:31 for the tx72xx platform there was a defconfig file that i could just edit to get my modules Jan 04 17:46:59 so what recipe is used for your build? Jan 04 17:47:04 thats important first Jan 04 17:47:18 i think its the linux_2.6.36.bb Jan 04 17:47:27 for the kernel Jan 04 17:47:31 okay Jan 04 17:47:55 than make a dir in recipes/linux/linux-2.6.36 which is the name of your machine Jan 04 17:48:05 and put the defconfig there Jan 04 17:48:16 so i can just make an i586 dir, that thats it? Jan 04 17:52:38 so that doesn't seem to work Jan 04 17:53:46 he said the name of your machine. as in, MACHINE. i really doubt that's i586 Jan 04 17:53:58 kergoth_: i'm building from the generic i586 Jan 04 17:54:24 oh sorry, its i586-generic Jan 04 17:54:27 :q! Jan 04 18:06:32 is there a function in OE to transform a variable to something suitable for a filename? i want to include a git branch name in a PV, but branches may contain characters like / Jan 04 18:12:09 hi ericben Jan 04 18:13:41 huh, i didn't know subprocess in 2.7 had these new features Jan 04 18:14:01 it comes with functions that raise a CalledProcessError if they fail, similar to our wrapper stuff Jan 04 18:14:08 was probably a common thing to do Jan 04 18:14:12 good to see Jan 04 18:14:48 ah, right, check_call was in 2.5, but check_output was in 2.7 Jan 04 18:37:00 gm Jan 04 18:37:15 gomorgengomoronhyväähuomrntagoodmorning Jan 04 19:18:06 03Tom Rini  07org.openembedded.dev * r4675f6234c 10openembedded.git/recipes/util-linux-ng/ (util-linux-ng.inc util-linux-ng_2.17.bb): (log message trimmed) Jan 04 19:18:06 util-linux-ng: Clean up native config bits. Jan 04 19:18:06 We don't need the ncurses stuff for how we use this, so disable it Jan 04 19:18:06 (and bump INC_PR). In util-linux-ng_2.17.bb the override to add Jan 04 19:18:06 some bits to the native recipe was killing all of the other parts Jan 04 19:18:06 so change the syntax so it doesn't, and set PR=INC_PR (now that Jan 04 19:18:07 INC_PR is bumped). Jan 04 20:18:44 eFfeM, as a native speaker, I find capthcha hard also :) Jan 04 20:21:41 :-) Jan 04 20:22:15 at least if you know the word you can guess a letter that is hard to read Jan 04 20:22:46 but we need to avoid that lots of work goes into cleaning Jan 04 20:22:59 well, hoefully the admins can find a balanc between usability and no spam Jan 04 20:23:02 btw just updated the wiki to state that the minimal bb is 1.10.2 Jan 04 20:23:38 btw, do yuo know of any links that reference www.openembedded.net? Jan 04 20:29:25 Crofton|work: google gives some: Jan 04 20:29:26 http://www.google.nl/search?q=site%3Awww.openembedded.net&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a#sclient=psy&hl=nl&safe=off&client=firefox-a&hs=uXt&rls=org.mozilla:en-US%3Aofficial&source=hp&q=url:www.openembedded.net&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=dfaebb53bc6659e9 Jan 04 20:29:45 and on the main page I see references to e.g. tinderbox.opemenbedded.net Jan 04 20:30:45 speaking of the main page, we might add fosdem11 to the recent news section, but I an not authorized to edit the front page Jan 04 20:30:59 hmm, I wonder if I am Jan 04 20:31:09 we need to check with Robert on the stand Jan 04 20:31:14 apparently he has been travelling Jan 04 20:32:08 is anybody using qt4-embedded with pkg-config? it seems to be broken, but i wonder how i could be the only one noticing Jan 04 20:32:29 it creates include paths like this: Jan 04 20:32:36 -I.../mipsel-oe-linux/usr/include/qtopia/QtCore Jan 04 20:32:36 -I.../mipsel-oe-linux/usr/include/qtopia/QtCore/qt4-embedded/QtCoreE Jan 04 20:32:36 -I.../mipsel-oe-linux/usr/include/qtopia/QtCore/qtopia Jan 04 20:33:04 hello folks, small question regarding BBCLASSEXTEND = "native" Jan 04 20:33:04 where the first line is ok, but the second and third don't make sense to me Jan 04 20:33:15 is do_configure_prepend executed for both? native and non-native? Jan 04 20:33:19 or just the non-native build? Jan 04 20:33:22 i'd expect -I.../mipsel-oe-linux/usr/include/qtopia instead Jan 04 20:37:25 Crofton|work: how about removing all junk users and only let people who login to modify wiki and make captcha mandatory only when you sign up Jan 04 20:37:45 khem, whatever the admins decide :) Jan 04 20:37:56 that sounds reasonable though Jan 04 20:38:26 mrmoku: it executes for both Jan 04 20:39:18 khem: ok, is the a way to execute something only for the non-native build? Jan 04 20:39:51 obi: hmm I tries to create a target override but was unsuccessful in my attempt Jan 04 20:40:00 ups s/obi/mrmoku Jan 04 20:40:16 khem: hmm... ok Jan 04 20:40:28 mrmoku: so you could do something like if BPN = PN Jan 04 20:40:33 than do target part Jan 04 20:40:44 else do the rest Jan 04 20:40:59 there is do_configure_prepend_virtclass-native in there too Jan 04 20:41:25 that one will only work for native recipe Jan 04 20:41:50 so right now you can have a generic _append which will work for target and native Jan 04 20:41:52 khem: ok, thx, will try to do the sed breaking the native build with that BPN = PN if Jan 04 20:42:00 and you can have override for native one Jan 04 20:42:28 oh BPN and PN and meta vars Jan 04 20:42:36 you can use them as it is Jan 04 20:42:59 sed -i "s#\$(top_builddir)/src/gdbus-codegen#${STAGING_BINDIR_NATIVE}/gdbus-codegen#g" ${S}/src/Makefile.am Jan 04 20:43:18 this is breaking the native build of gdbus-binding-tool as the bin is not yet staged Jan 04 20:44:39 mrmoku: hmm and the binary comes from same recipe ? Jan 04 20:44:44 so its like a catch-22 Jan 04 20:45:01 yup Jan 04 20:45:09 i c Jan 04 20:45:33 probably the target build is not even needed Jan 04 20:45:50 ahh... no, it is needed Jan 04 20:46:55 ok then you can do a little python magic to compare BPN and PN Jan 04 20:47:12 and you can put that under the conditional Jan 04 20:47:20 ok Jan 04 20:48:53 likewise, are you still using your openrd base board? Jan 04 20:48:53 I was planning on moving kirkwood from linux-kirkwood to mainline linux as the openrd git that is used now is not update for quite a while Jan 04 20:48:53 and I have 2.6.36.1 running on my sheeva Jan 04 20:49:05 still need to test on openrd-client Jan 04 20:50:06 "${@['', '']['${PN}' == '${BPN}']}" Jan 04 20:50:37 eFfeM: once in a while Jan 04 20:50:56 hello likewise Jan 04 20:52:06 khem: great, thx Jan 04 20:57:52 likewise: feel to test in on openrd-base, or do you have no problems with the upgrade Jan 04 20:59:28 evening Jan 04 20:59:46 khem: hello Jan 04 20:59:49 hi all Jan 04 21:05:54 eFfeM: I have no problems, openrd-base for always broken for me for pcie support Jan 04 21:11:51 eFfeM, I have openrd-client Jan 04 21:12:10 eFfeM please send me information on FOSDEM you want on wiki. Jan 04 21:12:22 hrw ping? Jan 04 21:13:37 ka6sox: I have openrd client too, so I can test on that myself, but can't test base Jan 04 21:13:53 dockstar already uses linux and there are no other kirkwood recipes Jan 04 21:14:04 sledz ping? Jan 04 21:14:54 the rd-base and sheevaplug are same? Jan 04 21:16:30 ka6sox: they use the same SoC, the peripherals are slightly different Jan 04 21:16:55 rd base is simpler than rd client but has pci-e whihc is used on the client for video Jan 04 21:17:15 likewise: I thought there was a patch for pci-e for openrd base Jan 04 21:19:52 ka6sox: for FOSDEM I propose to reuse the 2010-02-06 message, only changes are that the event is now in 2011-02-05 and it is FOSDEM'11 (but the link is to fosdem.org so still ok) Jan 04 21:25:51 for wiki....I suggest....Nuke, Pave, new user accounts for legit editors. Jan 04 21:27:54 this must be heading into the "dead" time Jan 04 21:33:20 ka6sox: fine with me Jan 04 21:33:47 florian: ping? Jan 04 21:33:50 calling it a day, cu tomorrow Jan 04 21:33:56 niters Jan 04 21:33:58 nite, eFfeM Jan 04 21:34:44 Jay7: i didn't break it ;) Jan 04 21:35:05 florian: hehe ;) I've question regarding kexecboot-devel ML Jan 04 21:35:34 it is registered by thesing but he can't remember password Jan 04 21:35:53 can you reset password or make me owner of this list Jan 04 21:35:56 or both :) Jan 04 22:52:45 some new bitbake bits hit the yocto repository today - nice work to the contributors! Jan 04 22:52:56 I like the new parsing progress meter Jan 04 23:32:57 03Klaus Kurzmann  07master * r0aa0a2adfc 10openembedded.git/recipes/shr/libshr-glib_git.bb: Jan 04 23:32:57 libshr-glib: new recipe Jan 04 23:32:57 Signed-off-by: Klaus Kurzmann Jan 04 23:33:15 03Klaus Kurzmann  07master * rc3ac25d61a 10openembedded.git/recipes/shr/libphone-ui_git.bb: Jan 04 23:33:15 libphone-ui_git.bb: adjust DEPENDS for switch to gdbus and bump rev Jan 04 23:33:15 Signed-off-by: Klaus Kurzmann Jan 04 23:33:27 03Klaus Kurzmann  07master * r7009c88722 10openembedded.git/recipes/shr/libphone-ui-shr_git.bb: Jan 04 23:33:27 libphone-ui-shr_git.bb: remove obsolete depends Jan 04 23:33:27 Signed-off-by: Klaus Kurzmann Jan 04 23:33:39 03Klaus Kurzmann  07master * r4fe0ecff0e 10openembedded.git/recipes/shr/shr-specs_git.bb: Jan 04 23:33:40 shr-specs_git.bb: use autotools Jan 04 23:33:40 Signed-off-by: Klaus Kurzmann Jan 04 23:33:52 03Klaus Kurzmann  07master * rf8f968e6ae 10openembedded.git/recipes/shr/phonefsod_git.bb: Jan 04 23:33:52 phonefsod_git.bb: fix DEPENDS for switch to gdbus and bump rev Jan 04 23:33:52 Signed-off-by: Klaus Kurzmann Jan 04 23:34:03 03Klaus Kurzmann  07master * rdcf3038584 10openembedded.git/recipes/shr/phoneuid_git.bb: Jan 04 23:34:03 phoneuid_git.bb: fix DEPENDS for switch to gdbus and bump rev Jan 04 23:34:03 Signed-off-by: Klaus Kurzmann Jan 05 00:54:15 okay wiki has been closed up...things "may" be different but it *should* work. Jan 05 00:54:37 we will remove the bad users ASAP. Jan 05 00:54:59 if you can't log in because it can't find your user just create a new account. Jan 05 00:55:11 and let me know here. Jan 05 00:56:29 * Tartarus tries Jan 05 00:56:55 works Jan 05 01:00:59 * mwester wonders if its worth reviving SlugOS-for-Sheevaplug Jan 05 01:03:01 mwester: I have updates for slugos package versions Jan 05 01:03:15 toolchain-related? Jan 05 01:03:23 mwester, I'd use it right now. Jan 05 01:03:25 mostly Jan 05 01:03:41 khem, go ahead and commit the changes! Jan 05 01:04:00 mwester: the changes I am testing makes it use gcc 4.5 Jan 05 01:04:57 mwester: http://pastebin.com/u2YVCnQ5 Jan 05 01:05:04 ka6sox - cool. Then I'll try to find the bits for sheevaplug support, and add that while I work on making it work with qemuarm as well (the latter to make development easier, since it's bloody hard to fly anymore with a modified NSLU2 in one's carryon!) Jan 05 01:06:00 khem, looks fine to me. Jan 05 01:06:01 mwester: how about including sane-toolchain.inc in conf/distro/include/preferred-slugos-versions.inc Jan 05 01:06:14 mwester: I need to test it well Jan 05 01:06:19 before I commit Jan 05 01:06:44 the advantage of using sane-toolchain.inc would be that it will always get a working toolchain Jan 05 01:06:58 so you dont have to hunt around Jan 05 01:06:59 I worry about losing control, things will break if someone changes the toolchain while we're trying to get ready for a release, for example. :( Jan 05 01:07:23 mwester: changes to toolchain.inc needs acks from stake holders Jan 05 01:07:25 its not easy Jan 05 01:07:46 khem, is this development branch Jan 05 01:07:47 Well, let's give it a try -- if someting breaks, we can change it. Jan 05 01:08:14 mwester: you mean trying sane-toolchain.inc ? Jan 05 01:08:22 yes. Jan 05 01:08:26 k Jan 05 01:08:38 I will test it Jan 05 01:08:53 ka6sox: dev or not toolchain is serious business Jan 05 01:09:05 we usually tend to not break it Jan 05 01:09:10 BTW, I'll be trying to get rid of tinylogin as well -- replace it with busybox (just an FYI). Jan 05 01:09:22 mwester: thats cool Jan 05 01:09:23 And we need to try thumb for SlugOS -- that would be good. Jan 05 01:09:32 we can then remove tinylogin from OE Jan 05 01:09:51 mwester: thats what you will get from sane-toolchain.inc Jan 05 01:10:00 :) Jan 05 01:10:10 mwester: for armv5te below it defaults to thumb Jan 05 01:10:37 mwester: you can also think about using uclibc Jan 05 01:10:48 if size is important Jan 05 01:11:49 It's not that important... I think there are other places to get back space. For example, ldconfig takes 500KB! Jan 05 01:11:57 Do we need ldconfig in the base image? Jan 05 01:12:08 mwester: uclibc is 600K and glibc is 2M Jan 05 01:12:57 mwester: ldconfig takes half meg Jan 05 01:13:04 you mean /etc/ld... Jan 05 01:13:08 I wonder what compromises, though. We want to be able to support a "real" Linux environment by use of opkg installs for those users who turnup to a hard drive or large flash device. Jan 05 01:13:09 or the binary itself Jan 05 01:13:34 mwester: opkg works fine Jan 05 01:13:43 with uclibc I have used it often Jan 05 01:13:50 The binary itself takes 500KB (ldconfig) Statically linked. Jan 05 01:14:02 thats an overkill Jan 05 01:14:14 you can remove ldconfig Jan 05 01:14:20 re: uclibc -- opkg will work, but what I mean is can users replace libc with a "normal" full-featured one using opkg? Jan 05 01:14:55 oh Jan 05 01:15:00 that may not happen Jan 05 01:15:21 upgrade may not work well I am not sure Jan 05 01:15:24 it may work too Jan 05 01:15:28 we have to try Jan 05 01:15:32 perhaps we can try. Jan 05 01:15:40 yeah Jan 05 01:15:48 no I think it wont Jan 05 01:15:49 And it may not hurt to have two SlugOS images (SlugOS-lite and SlugOS)... Jan 05 01:16:05 mwester: yeah I would say have two images Jan 05 01:16:19 slugOS-frugal Jan 05 01:16:20 There are some experimenters who might like a SlugOS that runs entirely in internal flash. Jan 05 01:16:38 mwester: ok Jan 05 01:16:42 let me try that out too Jan 05 01:16:47 :) Jan 05 01:16:52 it should not be a big issue Jan 05 01:17:06 I build minimal-uclibc for qemuarm regularly Jan 05 01:21:39 mwester, I have a slug that has been running slugOS for 4yrs without stopping Jan 05 01:21:45 from a flah Jan 05 01:21:49 er USB flash Jan 05 01:23:57 :) Cool. 3.10 then? Jan 05 01:24:56 mwester: PREFERRED_VERSION_linux-libc-headers ?= "2.6.23" Jan 05 01:25:06 do you still require that ? Jan 05 01:25:34 The kernel is awfully old. Jan 05 01:25:57 Not sure if we can go newer than the kernel version... Jan 05 01:26:02 mwester, ya, 3.10 Jan 05 01:26:14 it runs the weather station Jan 05 01:26:31 Davis? Jan 05 01:26:38 oww Jan 05 01:26:43 from Optware. Jan 05 01:27:07 but the base OS is 3.10 Jan 05 01:27:35 since it floats on the battery it hasn't been turned off in like 4yrs Jan 05 01:27:41 Ah. :) That's what I intend to be doing -- monitor my weather station as well as the HVAC system. Jan 05 01:28:11 the other 2 have been rebooted a lot as I've played with them... Jan 05 01:28:20 Right now I have a SlugOS system that's been running for a year connected to a dallas one-wire sensor network, monitoring the HVAC system here. Jan 05 01:28:20 the camera server and the mount controller Jan 05 01:28:53 well..I use other OWW sensors to detect dew and other things so that I can have it shut the roof. Jan 05 01:29:08 I bought the Sheevaplug in hopes that it would be large enough to handle the weather station, the HVAC system, and a web application to monitor/manage them all. Jan 05 01:30:29 mwester, thats why I bought the openrd-client Jan 05 01:30:42 so I could locally control it when I was there but replace the 3 slugs Jan 05 01:31:04 Same SOC - guess we can run SlugOS on that too. Jan 05 01:31:07 I have 3 slugs to control it. Jan 05 01:31:18 mwester, yup I'll test it there too. Jan 05 01:31:24 but it needs sata support too Jan 05 01:31:26 and some video Jan 05 01:31:31 so... Jan 05 01:31:45 I bought a 40GB SSD for it. Jan 05 01:32:39 right now I use 1 slug for camera server (gphoto), one for mount control(galileo) and 1 for environmental control/monitoring Jan 05 01:32:43 Sata is no problem. Not sure about the video though. Jan 05 01:33:05 I only need 2d video Jan 05 01:33:08 and not accellerated Jan 05 01:33:14 its 2D images Jan 05 01:33:20 X11? Jan 05 01:33:21 (and stic) Jan 05 01:33:25 er static Jan 05 01:33:28 ya, x11 please Jan 05 01:33:55 when I'm working out focus issues its important to be able to see things easily Jan 05 01:34:02 * mwester has nothing but troubles with x11 in the feeds. Jan 05 01:34:25 okay Xvnc is fine that works :D Jan 05 01:34:55 I really don't want to leave a LCD up there anyways Jan 05 01:35:52 and I suppose since my images take between 2 and 15minutes I could even just scp them off the box to a lappy Jan 05 01:37:15 The big problem was the old "lite" X11 stuff -- we have enough "oomph" on the Sheeva and OpenRD that we can build the full X11 libs. That should work ok. Jan 05 01:37:33 ya, it should work fine Jan 05 01:37:39 and 512MB is big enough Jan 05 01:38:21 if things are working the images don't stay long anyways...but I got a deal on a 40GB SSD so I put that on. Jan 05 01:39:51 the slugs are working fine but are getting OLD Jan 05 01:40:31 and I want to get a bigger camera that is larger than the 22MB left over after everything is running. Jan 05 01:40:39 Heh - my slugs are all fine, despite being old. But most of my original PSUs have failed. Linksys had a real problem with those. Jan 05 01:41:27 mwester these run off of a 34Watt Solar panel connected to a Truck Battery with a Regulator that I designed with redundancy Jan 05 01:41:34 I suppose that my dream system will need more RAM for the web UI, though. So I'll have to put the Sheevaplug in service at some point. Jan 05 01:41:44 Cool! Jan 05 01:42:01 during the day they are mostly "sleeping" Jan 05 01:42:31 the biggest draw is the Pelitier Jan 05 01:43:20 2.5A all night long Jan 05 01:43:41 but enviroslug controls that. Jan 05 01:43:54 via FT245 Jan 05 01:44:36 2.5A at watt voltage? Jan 05 01:47:02 12V 2.5A Jan 05 01:47:27 the CCD is only .375" SQ Jan 05 01:47:29 That's a lot of powerr. Jan 05 01:47:38 ya, thats the *biggest* draw Jan 05 01:48:00 but the slug controls the temp of it too. Jan 05 01:48:06 I keep it above the dew point Jan 05 01:48:18 Ah, got it. :) Jan 05 01:48:45 enviroslug keeps track of some 40 points of interest Jan 05 01:49:33 I have a second peltier that is hooked up as a generator...it tells me if we have clouds. Jan 05 01:50:05 anyways..the 3 slugs have been working fine for a long time Jan 05 01:50:27 I just need to get back on consolidating them into the 1 openrd-client Jan 05 01:50:47 both mountslug and cameraslug are maxed out Jan 05 01:51:01 (ram mostly) Jan 05 01:51:38 I almost went to ucslugc except I couldnt' get libusb and gphoto to work on it. Jan 05 01:52:30 mountslug runs a big python script that does the movement/tracking and scheduling Jan 05 01:53:07 Did you try openwrt on the slug? Jan 05 01:53:18 should be lighter-weight... Jan 05 01:53:21 ya, didn't like it for this application Jan 05 01:53:34 didn't run libusb and gphoto correctly Jan 05 01:53:46 * mwester ducks out to handle an interruption - back later! Jan 05 01:53:51 laters Jan 05 01:54:24 khem, okay let me know when you are ready for me to start testing for latest slugOS. Jan 05 02:02:17 my application need the qtdeclarative from Qt4 but when i compile with DEPENDS += "qt4-embedded" it give me a error like don't have the file QtDeclarative.h... I need include on DEPENDS qtdeclarative or anything like that? Jan 05 02:40:35 anyhelp? Jan 05 02:43:23 ok Jan 05 02:43:31 angelox_123, I can config kernels about 95% of the time but Qt is a Major Mystery. Jan 05 02:43:40 hehe Jan 05 02:44:01 i'd say that my qt4 didn't compiled the module QtDeclarative Jan 05 02:44:08 after the "ok" :) Jan 05 02:44:28 did you find it? is it staged? Jan 05 02:44:32 and i'd ask how to enable that module Jan 05 02:44:56 i searched about my sysroots Jan 05 02:45:05 and it isn't at that Jan 05 02:45:49 sorry, this is slack time...europe is asleep, and the US is home eating dinner. Jan 05 02:46:05 ok Jan 05 02:46:09 i'll sleep to..thanks Jan 05 02:46:19 angelox_123, sleep well.. Jan 05 02:46:33 I have no fear of haxoring a kernel but Qt scares me. Jan 05 02:46:34 ka6sox: thanks :) Jan 05 02:47:28 me too...i'm newbie on Qt...but with kernel i had a long life time with it :) Jan 05 02:48:00 same here Jan 05 02:48:05 from 2.0.x Jan 05 02:48:24 (yes, a newbie) Jan 05 02:49:40 thanks by all! good luck with your projects! Good Morning/Afternoon/Night (I don't know if you live on Europe or another place :) ) Jan 05 02:51:29 guh, our file format really sucks from a parsing perspective Jan 05 02:52:21 time to call in dba's Jan 05 02:54:18 my brother in law made a career out of working out metadata storage strategies. Jan 05 02:55:37 * mwester ducks back in just to mention that it beats the heck out XML Jan 05 02:56:01 parsing xml is "slow" Jan 05 02:56:19 just reading it is painful. Jan 05 02:56:57 mwester, now you got me all excited to stop using eh openrd-client as a thin client and use it for its intended purpose Jan 05 02:57:25 and I'll just use the nook as the controller Jan 05 02:57:29 :) I'd just like to get my Sheevaplug doing something other than being a paperweight Jan 05 02:58:02 Give me a couple of weeks; I'll be travelling for business again so it'll take a while. Jan 05 02:58:04 our LUG sheeva has Angstrom on it...but I'd rather run SlugOS. Jan 05 02:58:29 mwester, no worries...till SCALE is over I'm pretty booked. **** ENDING LOGGING AT Wed Jan 05 02:59:58 2011