**** BEGIN LOGGING AT Sat Dec 03 02:59:57 2011 Dec 03 10:22:01 hmm, linux-yocto-3.0.8+git1+ae3e64c077972fe87f09946bd215620df68ca327_1+fea3842615c13a54180b6600783b222f499002ef-r2 fails in do_install for i586 (qemux86) target Dec 03 10:44:27 it's debian stable, the find command used in the kernel.bbclass does seem to fail Dec 03 10:44:29 http://pastebin.mozilla.org/1391416 Dec 03 10:45:09 hello.... I m getting an error when I insert D-Link DWA-125 USB Wifi dongle..... phy1 -> rt2x00lib_request_firmware: Error - Failed to request Firmware. Dec 03 10:46:06 snkt: I am just wildly guessing, but maybe the firmware file is just not installed on the image? Dec 03 10:47:08 Jin^eLD, I have it in /lib/firmware .... still I dont know which firmware it requires..... Dec 03 11:52:41 bluelightning: hi Dec 03 11:53:21 bluelightning: did you find solution on bluetooth power control for different devices? Dec 03 14:30:17 hmm, is it possible to undo or prevent a bbappend from an other layer to be appended? Dec 03 14:31:07 the base-files bbappend in angstrom messes up things for me Dec 03 14:38:12 anarsoul: yeah I just used rfkill Dec 03 14:39:53 bluelightning: ok, but what happens if there're two rfkills? Dec 03 14:40:25 one for platform, and one generic allocated by hci_core Dec 03 14:44:33 doh! Dec 03 14:44:39 when I put the .bb file into my layer Dec 03 14:44:47 then lower prioritized layers STILL do .bbappend to my recipe Dec 03 14:44:52 any way to prevent that? Dec 03 14:45:19 basically that means that if some layers messes up you can't do anything about it except removing the .bbapend recipe from that layer.. Dec 03 14:45:24 or is there any other way? Dec 03 14:47:57 Jin^eLD: priorities will not stop bbappends from applying, they only influence the order in which they are applied Dec 03 14:48:28 anarsoul: I'm not sure how I coded it, will have to check Dec 03 14:49:11 bluelightning: but what to do if you don want a bbappend to get applied at all? Dec 03 14:49:19 * anarsoul 's thinking about making bluetooth driver know about platform-specific rfkill Dec 03 14:50:00 bluelightning: currently I am in a situation where a .bbappend from angstrom is doing things that I do not want, is there really no hack to somehow prevent that its applied? Dec 03 14:50:24 I thought it would work if I move the whole recipe into my layer which has a higher prio, but that was not the case and you just confirmed that Dec 03 14:50:35 so that's not an option either Dec 03 14:50:49 Jin^eLD: the only thing you can do is have a bbappend in your layer which overrides whatever it's doing Dec 03 14:51:21 Jin^eLD: out of curiosity which bbappend is causing you problems? Dec 03 14:51:22 you mean which undoes whatever the other one is doing? Dec 03 14:51:25 Jin^eLD: yes Dec 03 14:51:27 base-files Dec 03 14:51:49 ./meta-angstrom/recipes-core/base-files/base-files_3.0.14.bbappend Dec 03 14:51:52 that's the evil one :P Dec 03 14:52:18 ok I can undo volatiles, I can filter_out dirs755 which won't look nice but would work.. Dec 03 14:52:29 and I'd have to overwrite pkg_postinst_${PN} Dec 03 14:53:03 Jin^eLD: do you really need to undo all of this? Dec 03 14:53:28 I need to have these directories in volatile space Dec 03 14:53:36 otherwise network will not come up after power loss Dec 03 14:53:55 and at least for my use case there is no point to have those dirs in persistent flash anyway Dec 03 14:54:01 no clue why angstrom does this Dec 03 14:54:22 anarsoul: the code I wrote for opie looks for the first rfkill device marked "persistent" Dec 03 14:54:43 Jin^eLD: probably to do with systemd Dec 03 14:55:42 well, systemd is another evil thing that I had to patch out of some recipes Dec 03 14:55:51 :) Dec 03 14:56:18 if you don't like systemd I would say you probably won't want to be using angstrom as a base for much longer; koen intends to switch completely over to it Dec 03 14:56:46 doh... Dec 03 14:56:56 are there any other maintained distros? Dec 03 14:57:38 well, there are some distro layers in the layer index Dec 03 14:58:04 but it sounds like you want to set your own policy more or less, which suggests you may want to have your own Dec 03 14:58:48 in the new oe-core structure having your own distro is not so much of a burden Dec 03 14:59:06 well, angstrom was doing a lot of fixes and tuning Dec 03 14:59:16 so it is nice basing on top of it Dec 03 14:59:21 at least it was... Dec 03 14:59:36 bluelightning: ok, but what does 'persistent' mean for rfkill? Dec 03 15:24:12 anarsoul: well, in my experiments I found that the persistent device was present even when the hardware rfkill switch was off on my laptop Dec 03 15:24:35 the others are created and removed when the switch is used Dec 03 15:34:22 bbl Dec 03 16:14:32 Jin^eLD: you might be better off writing your own image recipe Dec 03 16:15:12 no systemd here either (actually also no rc scripts; this is for an embedded system so the few services I need are started from init Dec 03 16:42:52 eFfeM_work: we do use use initscripts and I do have my own image recipe Dec 03 21:18:00 MACHINE_KERNEL_PR anyone knows history why we needed it ? Dec 03 22:07:21 khem: I know koen is very keen on it, perhaps he can tell you more about that Dec 03 22:07:45 where are mpc8315e-rdb and beagleboard machine .conf these days? Dec 03 23:11:16 bluelightning: I got the history with some digging Dec 03 23:11:18 :) Dec 03 23:11:44 now my annoying problem is that agstrom source mirror is so slooow for me Dec 03 23:11:54 3.1 Kbps Dec 03 23:12:19 so its downloading eglib src from there and says it will take around 3 hrs Dec 03 23:12:37 is there provision in a recipe to ignore premirrors ? Dec 04 00:31:53 khem: sure, just set PREMIRRORS = "" in the recipe Dec 04 00:32:00 or even a bbappend Dec 04 00:32:08 * bluelightning -> bed Dec 04 00:49:04 problem is angstrom does PREMIRROR_append :( Dec 04 00:50:16 you should be able to set PREMIRROR_append = "" in your recipe **** ENDING LOGGING AT Sun Dec 04 02:59:58 2011