**** BEGIN LOGGING AT Wed Jan 16 02:59:59 2013 Jan 16 05:34:12 wmat: I'm using python 2.7.3 Jan 16 06:13:13 can someone help me with qt plugin linking problem Jan 16 06:13:43 Earlier i was using OE classic and now i shifted to oe-core Jan 16 06:13:58 with oe classic my application runs perfectly Jan 16 06:14:31 but after building with or core application plugin are not getting load Jan 16 06:17:16 when i checked the difference between these two, the difference is that plugins are not getting linked Jan 16 08:48:26 good morning Jan 16 09:00:50 morning all, hi mckoan Jan 16 09:30:20 morning all Jan 16 11:14:14 I am creating a distro-less system with oe-core tree master, bitbake core-image-minimal, but looks like the fs has a problem with /dev/console and /dev/null so I get "Warning: unable to open an initial console." Jan 16 11:14:52 if I create mknod -m 660 console c 5 1 and mknod -m 660 null c 1 3 in my NFS server /dev the system goes further Jan 16 11:15:20 Starting udev and so on Jan 16 11:16:41 which recipe is responsible for creating /dev in the rootfs? Jan 16 11:21:48 oe-classic creted a /dev with a proper major-minor for each device, oe-core set 0,0 for everything Jan 16 11:22:52 you should be running udev, and build your kernel with udev support Jan 16 11:23:06 (well, devtmpfs/udev stuff) Jan 16 11:38:12 bencoh: thx, udev is active and running of course. If I use a fs generated by oe-classic everything works because it has /dev/console with major,minor Jan 16 11:38:52 the problem seems to be the /dev entries created by oe-core Jan 16 11:41:21 maybe the distro-less doesn't set to include udev stuff in the fs Jan 16 11:42:16 yes, it will Jan 16 11:43:06 something like IMAGE_DEV_MANAGER ? Jan 16 11:52:30 mckoan: edit kernel configuration, enable CONFIG_DEVTMPFS, CONFIG_DEVTMPFS_MOUNT=y, build, boot machine Jan 16 11:52:47 mckoan: stop wasting time on managing static /dev/ Jan 16 13:17:57 hrw: I'll try, thx Jan 16 13:18:27 mckoan: I had similar problem when started armv8 work. devtmpfs solved it in 5 minutes Jan 16 13:32:55 mckoan: http://cgit.openembedded.org/meta-handheld/commit/conf/machine/include/zaurus.inc?id=dd531029edef4af718771af8f2703b487e1c1b0b Jan 16 13:34:57 mckoan: http://patches.openembedded.org/patch/7729/ Jan 16 13:37:31 if you have really old kernel ( pre 2.6.30 ?) Jan 16 13:38:03 ant_work: You have hit the mark! Jan 16 13:38:13 ant_work: actually I am using 2.6.30.10 Jan 16 13:38:54 ant_work: I couls use IMAGE_DEVICE_TABLES, but your approach is what I actually needed, thank you so much ;-) Jan 16 13:40:30 ant_work: now I have to understand which recipe expand the device_table-minimal.txt Jan 16 13:40:39 note that you have expressely to override Jan 16 13:41:01 +IMAGE_DEVICE_TABLES = "" Jan 16 13:41:11 if you want devtmpfs-only Jan 16 13:42:41 or you'll get the device-table-minimal form image.bbclass Jan 16 13:42:43 if devtables == None: Jan 16 13:42:43 devtables = 'files/device_table-minimal.txt' Jan 16 15:03:16 hrw, ant_work: neither enable CONFIG_DEVTMPFS, CONFIG_DEVTMPFS_MOUNT=y nor device_table-minimal.txt are working, I must change approach using a distro on the top of oe-core Jan 16 15:03:24 I'll try amstrong Jan 16 15:03:53 why that? sounds strange Jan 16 15:04:08 I wonder what is the purpose of core-image-minimal considering that it doesn't boot Jan 16 15:04:42 last I tried was ever lacking the modules... Jan 16 15:04:54 core-image-base is much better target Jan 16 15:05:05 ant_work: /dev/consolec6620551--- Jan 16 15:05:23 is aleady present in the standard device_table-minimal.txt Jan 16 15:05:35 mckoan: I just built it, it does boot here Jan 16 15:05:45 I've added static devices few days ago to an initramfs with old kernel. it did work Jan 16 15:06:48 I was exactly lacking /dev/console and co. Jan 16 15:07:00 bluelightning: I am using basically only oe-core/meta and a recipe for my kernel Jan 16 15:07:32 bluelightning: what do you have in your bblayer.conf ? Jan 16 15:07:35 it can only be then that the kernel is not configured appropriately... Jan 16 15:07:55 mckoan: meta and meta-yocto Jan 16 15:08:07 bluelightning: but the same kernel boots with an oe-classic generated fs '-( Jan 16 15:08:23 with much older versions of udev etc of course Jan 16 15:13:07 bluelightning: and which image name? Jan 16 15:13:28 mckoan: core-image-minimal... Jan 16 15:14:58 bluelightning: and DISTRO ?= "poky" right? Jan 16 15:15:04 yes Jan 16 15:15:16 it's unlikely that that makes any difference though Jan 16 15:16:28 bluelightning: I guess it is the difference Jan 16 15:17:03 I would doubt it Jan 16 15:17:11 mckoan: found that, about udev: Jan 16 15:17:13 # udev 169 and up require kernel 2.6.36 for ARM: Jan 16 15:17:13 # http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=67a77c8bf299f6264f001677becd056316ebce2f Jan 16 15:20:44 oh dear, [RFC v4]systemd integration Jan 16 15:21:24 mckoan: for my armv8 work plain oecore works fine Jan 16 15:22:19 mckoan: 2.6.30? no way to upgrade it? Jan 16 15:24:55 I wonder if we should be detecting and warning about such situations... Jan 16 15:24:59 over 3 years old kernel in production device... Jan 16 15:27:25 mckoan: hurry up, in the next days there will be surely some 'disturb' once systemd is implemented :) Jan 16 15:27:28 if it would be 2.6.20 then I would ask for ST-8815 cpu. but 2.6.30... sounds like at91 family line Jan 16 15:31:04 hrw: there are more old kernel in production device than you can imagine ;-) Jan 16 15:31:26 bbl Jan 16 15:31:38 mckoan: 2-3 years ago I removed last 2.4 running one from my collection Jan 16 15:32:16 mckoan: you have to add some kernel backports to satisfy dependencies of newer udev, then disable kernel checks in udev initscript Jan 16 15:32:40 mckoan: check efikamx 2.6.31 kernel from Genesi - they have similar problem Jan 16 15:34:34 or just add the recipe for an older udev in addition to your kernel recipe Jan 16 15:35:10 hrw: if is true that udev 169 and up require kernel 2.6.36 for ARM (as ant_work said) I suspect that keeping old kernels will face to various packages compatibilities Jan 16 15:35:27 the best solution would be to move to 3.x Jan 16 15:36:07 bluelightning: yes I'll spend some hour more trying recipe for an older udev Jan 16 15:36:13 mckoan: if you can update kernel then go to newest possible Jan 16 15:36:31 thank you all for your precious help Jan 16 15:36:45 mckoan: shouldn't take that long, you can just grab the udev 164 recipe we had before the update to 182 Jan 16 15:36:58 and especially for moral support :-D Jan 16 15:39:27 argh. Jan 16 15:39:39 for some reason I need to have image with all boost libraries Jan 16 15:40:04 ERROR: Nothing RPROVIDES 'boost-chrono' (but /home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/meta-linaro/recipes-linaro/images/linaro-image-sdk.bb RDEPENDS on or otherwise requires it) Jan 16 15:40:51 ok, skipped that one and goes Jan 16 15:43:41 NOTE: Preparing runqueue Jan 16 15:43:42 uf. Jan 16 16:16:18 bluelightning, ping Jan 16 16:16:37 hi Crofton|work Jan 16 16:16:39 hi Jan 16 16:16:50 we should talk about fosdem at some point Jan 16 16:16:56 on a call Jan 16 16:17:06 listening to davest .... Jan 16 16:17:15 can you reply to Ulf/ Jan 16 16:17:22 also, I ordered some stickers :) Jan 16 16:22:13 Crofton|work: I'm not sure I have a great answer... Jan 16 16:22:22 say that then :) Jan 16 16:22:38 Crofton|work: I plan on bringing an FRI2 at least assuming I can get one in time Jan 16 16:22:53 yeah, lets try and get some focus Jan 16 16:23:10 and we need to check with florian on the box Jan 16 16:25:39 Crofton|work: ok, will reply Jan 16 16:26:30 bluelightning, thanks Jan 16 16:48:45 bluelightning, hrw: using udev-164 I was able to see the prompt at last. thank you. Jan 16 16:49:42 ;) Jan 16 16:53:35 mckoan: np Jan 16 21:28:07 hi Jan 17 00:06:30 why commit 1659da8 wasn't applied to oe-core as well? Jan 17 00:06:40 its about the armel deb package problem **** ENDING LOGGING AT Thu Jan 17 03:00:00 2013