**** BEGIN LOGGING AT Sat Feb 25 02:59:59 2012 Feb 25 06:44:47 hi anyone here? Feb 25 10:17:00 Hi. Does anybody know, what's going on with angstrom-distribution website? Feb 25 10:23:16 not me but perhaps better ask in #angstrom or ping koen Feb 25 10:36:34 i asked in both channels, hoping to improve my chances to an answer Feb 25 11:26:42 how to add mirrors? Feb 25 15:26:04 re Feb 25 15:26:07 :-) Feb 25 16:47:48 moin Feb 25 16:48:44 hi Feb 25 16:48:49 * nerdboy suggests adding a note to the OE getting started page about the bitbake build tree sucking up all the inodes Feb 25 16:49:47 o.O Feb 25 16:50:10 do not kown which older version of bitbake you used Feb 25 16:50:17 "no space left on device" with many free gigbytes... Feb 25 16:50:41 hm when you optimized your fs for videos okay Feb 25 16:50:51 we're using the TI arago stuff which is currently stuck on 1.10.2 Feb 25 16:50:55 but with normal mkfs.fs I had no problems Feb 25 16:51:10 ti arago is most of the times outdated Feb 25 16:51:27 iit's the second build tree that does it Feb 25 16:51:48 i move the first one to tmp.old and then it fails on the second one Feb 25 16:51:58 sorry about that Feb 25 16:52:10 but dont know how you called mkfs.fs Feb 25 16:53:17 nothing special originally, just mkfs.ext4... Feb 25 16:54:03 if i give it a bunch of ectra inodes then everything is okay Feb 25 16:54:11 *extra even Feb 25 16:54:25 hm strange Feb 25 16:54:45 because I never heard yet of running out inodes Feb 25 16:54:54 maybe I default config of your os? Feb 25 16:55:03 to optimize it for large files? Feb 25 16:55:27 there's no gentoo default beyond the suggestions in the handbook Feb 25 16:55:52 hm hm Feb 25 16:56:18 maybe arago isnt using rm_work Feb 25 16:56:23 but I dont think so Feb 25 16:56:41 rm_work is enabled Feb 25 16:56:46 nerdboy why not go with oe-core and meta-texasinstrument? Feb 25 16:57:39 it least for now we're still going with our upstream TI guy's recommended stuff Feb 25 16:58:09 i guess we're on the bleeding edge of the hardware... Feb 25 16:58:23 dm8168 with all the bells and whistles Feb 25 16:58:44 and outdated software? Feb 25 16:59:43 their oe tree is following oe-dev pretty closely Feb 25 17:00:13 but we need several TI-specific packages out their latest SDK Feb 25 17:00:17 oe-dev is outdated Feb 25 17:00:26 we only make few changes to it Feb 25 17:00:42 hm but okay Feb 25 17:00:54 your ti sales guy might know it better or not Feb 25 17:00:56 sounds like you should talk to my coworker Feb 25 17:01:44 well, "sales guy" might be a misnomer... he's got his own 8168 git repo Feb 25 17:09:12 hi woglinde Feb 25 17:09:22 hi gnutoo Feb 25 17:20:36 woglinde: our "custom" is based on the TI dude's arago-c6a8.git which in turn is based on arago-oe-dev.git Feb 25 17:21:00 i'd love to migrate if we could... Feb 25 17:22:05 if it didn't involve hacking every package in the middle that is Feb 25 17:26:34 yeah I am found of it Feb 25 17:32:12 bluelightning, hi Feb 25 17:32:25 hi GNUtoo|laptop Feb 25 17:33:04 bluelightning, did you have the time to build opie? Feb 25 17:33:09 and to test Feb 25 17:33:36 GNUtoo|laptop: not yet, no Feb 25 17:33:43 might start a build now Feb 25 17:33:43 ok Feb 25 17:33:47 so I wait Feb 25 17:33:47 ok Feb 25 17:35:36 bluelightning, did you look at my patch btw? Feb 25 17:36:42 it contains [meta-opie] but not [PATCH] Feb 25 17:40:51 GNUtoo|laptop: looks ok, but I think we should enable package management using IMAGE_FEATURES instead Feb 25 17:41:25 package management? Feb 25 17:41:36 it's for the kernel and machine extra rrecommends Feb 25 17:42:19 ah sorry I saw ${ROOTFS_PKGMANAGE} , it just moved :) Feb 25 17:42:55 yes Feb 25 17:44:11 what concerns me is that these items were never needed in OE-Classic, so why should we add them to the image now? Feb 25 17:44:29 because things changed Feb 25 17:44:34 I don't know why tough Feb 25 17:44:39 also, what about systems that do not need the kernel in the rootfs itself? Feb 25 17:44:40 but I really need this fix Feb 25 17:44:45 else the system doens't boot Feb 25 17:44:54 hmmm Feb 25 17:45:00 yeah I understand that Feb 25 17:45:01 that's a concern Feb 25 17:45:09 in SHR we remove it after Feb 25 17:45:18 we rm the uImage in jffs2 and ubifs images Feb 25 17:45:20 like that: Feb 25 17:46:13 IMAGE_CMD_jffs2_om-gta01 = "rm -rf ${IMAGE_ROOTFS}-boot; mv ${IMAGE_ROOTFS}/boot ${IMAGE_ROOTFS}-boot .... Feb 25 17:46:28 and then comes the command for making the jffs2 image Feb 25 17:46:36 that just means the package system claims it's installed when it isn't... Feb 25 17:46:40 what happens on upgrade? Feb 25 17:46:41 and then mv ${IMAGE_ROOTFS}-boot ${IMAGE_ROOTFS}/boot" Feb 25 17:46:50 hmmm good question Feb 25 17:46:57 on upgrade it flashes the kenrel Feb 25 17:47:03 because of postinstall Feb 25 17:47:19 it detects that it's on NAND Feb 25 17:47:24 in postinstall Feb 25 17:47:29 and flash in the kenrel partition Feb 25 17:47:46 that's on gta02 Feb 25 17:48:07 the problem is that there are phones where you have to talk to the bootloader to flash the kernel Feb 25 17:48:19 but for theses phones nothing happen I guess Feb 25 17:56:41 hey. i'm having trouble overriding the FILESEXTRAPATHS_prepend from netbase_4.47.bbapend in my own layer. it seems THISDIR is defined to another layer (meta-ti) containing their own bbappend recipe. is this a bitbake glitch? Feb 25 17:57:06 i can see with bitbake -e that FILESEXTRAPATHS follows whatever I wrote inthere, but it uses the meta-ti paths for THISDIR Feb 25 17:57:37 the override would be my-layer/netbase.bbappend -> meta-ti/netbase.bbappend -> oe-core/netbase.bb Feb 25 17:58:22 because of layer priorities... Feb 25 17:59:05 oh! meta-ti's bbappend manually defines THISDIR? Feb 25 17:59:46 gah... i've read on the migration guide this is bad practice Feb 25 20:03:43 CMoH|notebook: yes, it should not be doing that Feb 25 20:08:29 bluelightning, hi again, at what point is the build? Feb 25 20:08:53 note that my build was from scratch Feb 25 20:27:13 GNUtoo|laptop: I got sidetracked investigating the best way to handle this patch you sent Feb 25 20:29:08 ok np Feb 25 20:30:36 I think we need to start a wider discussion on getting the kernel into the image Feb 25 20:35:06 ok Feb 25 20:35:21 and the way we handle it at SHR is not ok? Feb 25 20:38:21 GNUtoo|laptop: I don't know Feb 25 20:38:29 ok Feb 25 20:58:13 Hi everyone, I have some ipk and I don't want to build again that packages Feb 25 20:58:31 I want to tell OE to install those ipks into rootfs while generating rootfs image Feb 25 20:59:11 How can I do that? Is there an environment for that purpose to define a directory name where external ipk located? Feb 25 21:01:52 not so easy Feb 25 21:02:03 either you write an recipe and include it Feb 25 21:02:17 or you have to write an postinstall scrippt which is doing for you Feb 25 21:04:02 mgundes, you could re-do the ipk Feb 25 21:04:06 you extract what's inside Feb 25 21:04:18 and ship its content Feb 25 21:05:21 GNUtoo|laptop: yes I can extract it with ar and gunzip, but I thougt it may be an easier way Feb 25 21:05:42 because oe generates rootfs from deployed ipk, right? Feb 25 21:06:02 yes but once you generate an ipk with oe, I think it can re-use it Feb 25 21:07:11 yes I think so, however I wonder if there is a way to exactly telling installing those specific ipks. Feb 25 21:09:27 woglinde, what kind of postintall script? Do you know any example postinstall script in OE? Feb 25 21:11:14 no Feb 25 21:11:24 postinstall script in rootfscreatuion Feb 25 21:26:23 ok thank you all **** ENDING LOGGING AT Sun Feb 26 02:59:58 2012