**** BEGIN LOGGING AT Wed Nov 02 02:59:57 2011 Nov 02 06:00:10 ka6sox: ping Nov 02 06:02:46 Denix0 pong Nov 02 06:02:56 what is the message you are seeing? Nov 02 06:04:24 ka6sox: by bad, had to logout and login again... working now. thanks! Nov 02 06:04:32 ah, good... Nov 02 06:04:40 see, I knew you could pass :D Nov 02 06:04:47 and sorry for the trouble! Nov 02 06:04:52 np... Nov 02 06:05:58 although I wasn't seeing my name on active users list. I guess I need to start editing first? Nov 02 06:07:25 yep... Nov 02 06:07:27 that would help! Nov 02 08:44:52 mornin Nov 02 10:02:53 hi, all! Nov 02 10:07:02 slapin: privet Nov 02 11:30:49 how could I configure startup tol force loadeing of some kernel modules? Nov 02 11:30:55 *to Nov 02 11:34:22 slapin: could udev take care of that? Nov 02 11:34:22 or just do it in the rcS script Nov 02 11:34:22 I'm no OE expert... but isn't that usually done in /etc/modules (on most distros at least) Nov 02 11:34:22 not sure how OE works... I just try and keep the servers alive, lol... which I am currently failing at :( Nov 02 11:34:23 cryptk: not necessarily, on my fedora I do not have an /etc/modules at all Nov 02 11:34:23 I guess that's very distro specific Nov 02 11:34:23 most of my experience is on the Deb/Ubu side... Nov 02 12:03:57 hehe :) kann mach garnicht mehr daran erinnern Nov 02 12:04:00 oops wrong window Nov 02 13:18:12 03Philip Balister  07master * r51682f9ee3 10openembedded.git/recipes/gnuradio/ (6 files in 2 dirs): Nov 02 13:18:12 gnuradio : Update version and build with qt support. Nov 02 13:18:12 * Updated git rev to latest master. Nov 02 13:18:12 * Add hacks to build gnuradio with qt support. Still need to build PyQ*t on Nov 02 13:18:12 the target. Nov 02 13:18:12 Signed-off-by: Philip Balister Nov 02 14:15:41 morning kergoth_ Nov 02 14:45:27 hey Nov 02 15:56:47 any reason there's no task-proper-tools.bb in oe-core (yet)? Nov 02 15:57:32 I'm not familiar w/ "proper-tools" what is it? Nov 02 15:59:39 fray: in oe-classic there's a recipe that adds "real" versions of the busybox tools. Nov 02 16:01:08 there is an lsb task that does that.. but it's goal is to provide the base tools for LSB compliance Nov 02 16:01:28 there is also a series of tasks that incrementally add more base tools... Nov 02 16:01:33 fray: http://cgit.openembedded.org/openembedded/tree/recipes/tasks/task-proper-tools.bb?h=org.openmbedded.dev Nov 02 16:01:37 fray: lsb? Nov 02 16:02:07 that looks like the LSB set Nov 02 16:02:24 http://www.linuxfoundation.org/collaborate/workgroups/lsb Nov 02 16:02:49 note, unless you set yoru distribution to be "LSB".. the LSB image types/tasks only add in the required apps -- but not necessary the full config Nov 02 16:03:35 task-core-lsb is what you want Nov 02 16:03:42 fray: ah, thanks Nov 02 16:05:57 if you want fewer sets then what LSB requires.. look at the "task-core-*" list Nov 02 16:06:10 they progressively add more and more capabilities Nov 02 16:06:26 'er.. they can be USED to progressively add more and more capabilities Nov 02 16:07:22 fray: I think I want all. adding task-core-lsb to IMAGE_INSTALL and DEPENDS in my image should do it? Nov 02 16:07:50 should work -- there is an lsb image type as well.. Nov 02 16:08:28 fray: cool. I have my own image based on the angstrom console-image, so I'll add it there. Nov 02 16:09:18 thanks for the help - gotta run. Nov 02 16:09:22 np Nov 02 16:09:24 hi, i m trying to build an sdk with bitbake meta-toolchain-sdk and oe-core but i get this error : http://pastebin.com/nT7wcAYp Nov 02 16:12:37 not sure.. it's something to do with the angstrom.. I believe Koen was working on a fix for that Nov 02 16:14:28 hum ok, i will ask on angstrom then Nov 02 16:39:05 otavio: ping? Nov 02 16:39:12 bluelightning: pong Nov 02 16:39:25 otavio: hi, I think I fixed combo-layer Nov 02 16:39:31 bluelightning: yey Nov 02 16:39:47 otavio: also implemented proper init and added a per-component branch setting Nov 02 16:40:09 what else did you think would be worth implementing? Nov 02 16:40:51 bluelightning: the sync autocommit Nov 02 16:41:04 bluelightning: is no sense to expect the user to commit the .conf file byhand Nov 02 16:41:25 otavio: I'm not sure the conf file should be part of the repo... Nov 02 16:41:44 bluelightning: it must otherwise it is a nightmare to maintain it Nov 02 16:41:51 bluelightning: and you can easily mess it up Nov 02 16:42:24 bluelightning: I'd say to have it as 'autocommit = true' by default and be allow to be disabled to more "weird" setups Nov 02 16:42:47 bluelightning: how you'd setup it? Nov 02 16:43:48 well, I figured having a commit each time last_revision got changed would be noisy... but then again having it tracked by git is also useful Nov 02 16:47:06 thats what i hate about submodules -- all the 'updated the submodules' commits :\ useful, but noisy indeed Nov 02 16:47:08 heh Nov 02 16:49:04 otavio: in my test configuration the conf file is outside the combo repo tree (it has to be, or the script complains) Nov 02 16:49:26 bluelightning: here I have it as ... Nov 02 16:49:46 bluelightning: http://paste.debian.net/142096/ Nov 02 16:49:52 bluelightning: and conf is on my repo Nov 02 16:50:03 bluelightning: so anyone that clones it can keep working on it Nov 02 16:50:33 bluelightning: do a single commit at end Nov 02 16:51:23 bluelightning: another thing I dislike is how difficult is to handle non-working patches. We ought to end with the conflicts on the tree so we can hack and merge it byhand Nov 02 16:52:04 otavio: yes... unfortunately we're limited by how git-am behaves Nov 02 16:52:24 there might be some options we can use to improve matters, I haven't checked Nov 02 16:52:59 bluelightning: the biggest problem is that 3way is not in use as the base hashs are different due the changes on parent objects Nov 02 16:53:38 otavio: yes, but there's no way for us to fix that is there? Nov 02 16:53:44 bluelightning: one possible way to fix it is to parse the log and keep a database of parents of each component ... Nov 02 16:53:57 bluelightning: and hack the patch to use the "new ones" Nov 02 16:54:06 hmm, that sounds a bit painful Nov 02 16:56:10 bluelightning: less painful then handling it byhand Nov 02 16:56:15 bluelightning: technically possible Nov 02 16:56:34 bluelightning: when it fails to apply it is hard to figure WHY Nov 02 16:57:00 bluelightning: and I am not an begginer so for new commers it will be a nightmare Nov 02 17:01:13 otavio: as a stopgap it looks like git-am has a "--reject" option that should leave the patch half-applied... Nov 02 17:01:33 bluelightning: that would be better Nov 02 17:22:51 JaMa|off: there? Nov 02 17:23:11 bluelightning: once you have the patches ready, send them for me to apply and test them Nov 02 18:12:20 otavio: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/combo-layer-fixes2 Nov 02 18:12:34 even added the autocommit feature :) Nov 02 18:13:15 it's not optional at the moment; because of the mechanics I think it's fairly safe (there can't be any prior changes because the repo can't be dirty) Nov 02 18:17:52 bluelightning: in case the merge has a diff Nov 02 18:17:58 bluelightning: it will be missing Nov 02 18:18:13 otavio: ? Nov 02 18:18:20 bluelightning: you can't use --no-merges to workaround it Nov 02 18:18:33 bluelightning: you ought to check if the merge has a diff or not or so Nov 02 18:19:17 otavio: hmm... I guess some more work is needed here Nov 02 18:19:28 bluelightning: got what i meant? Nov 02 18:19:31 yes Nov 02 18:19:46 git-format-patch will not output those diffs though I suspect Nov 02 18:19:50 bluelightning: the merge can have a diff and in this case this need to go Nov 02 18:20:00 bluelightning: I guess it will Nov 02 18:20:09 bluelightning: after all it is a changeset Nov 02 18:20:37 otavio: if you have time you could help me by confirming this solution doesn't work... Nov 02 18:21:06 or at least, seeing how format-patch behaves over a merge commit Nov 02 18:21:10 that contains a diff Nov 02 18:23:24 bluelightning: I am thinking of a project I have that has a diff in a merge to test Nov 02 18:23:31 ok Nov 02 18:28:11 bluelightning: all projects I looked, up to now, I didn't find it Nov 02 18:28:21 bluelightning: it usually happens when it fix a conflict Nov 02 18:28:38 bluelightning: so the conflict fix is recorded into the merge object Nov 02 18:29:09 kergoth: how repo can be used in case you have local changes in the tree? Nov 02 18:29:18 otavio: the linux kernel would be one place where they use merges a lot I guess Nov 02 18:29:28 bluelightning: I am looking at it now Nov 02 18:29:52 bluelightning: but most of time they has no conflicts due the next tree automerging Nov 02 18:37:02 otavio: no differently than submodules, just it can track branches, and will automatically rebase local commits on the branch when updating Nov 02 18:41:50 kergoth: so you have branches for each product/client and one for upstream? Nov 02 19:35:29 otavio: pong Nov 02 19:44:11 JaMa|off: i noticed the problem you had with dbus user Nov 02 19:44:20 JaMa|off: i fail to see how the number could end up different Nov 02 19:46:04 if you opkg upgrade and you already had ie messagebus user Nov 02 23:26:24 huh, i didn't know about vim's "autoread" option, time to turn that one on Nov 02 23:26:42 autoread? Nov 02 23:30:03 automatically re-reads teh open file if its changed outside of vim Nov 02 23:30:26 ah Nov 02 23:42:39 * kergoth yawns **** ENDING LOGGING AT Thu Nov 03 02:59:59 2011