**** BEGIN LOGGING AT Fri Nov 15 02:59:59 2013 Nov 15 08:44:31 good morning Nov 15 09:02:09 hi mckoan Nov 15 09:37:34 hi all. When I run bitbake busybox -c menuconfig, ncurses are confused, everything is misaligned. Nov 15 09:37:46 can it be messed locale? Any ideas how to fix this? Nov 15 10:13:52 morning all Nov 15 10:23:26 where does kernel recipes inherit cml1? Nov 15 10:23:51 I'd like to see how do_menuconfig() is executed in the case of kernel Nov 15 10:24:02 and compare this to non-working menuconfig of Busybox Nov 15 10:32:17 drasko: in kernel.bbclass Nov 15 10:38:04 drasko: you may find run.do_menuconfig.* for each case more instructive Nov 15 10:38:13 though this problem may run a little deeper Nov 15 10:38:33 bluelightning, yes... http://patchwork.openembedded.org/patch/45493/ Nov 15 10:38:35 AIUI with the kernel there was some kind of fix in the kernel config system itself Nov 15 10:39:09 right, Jason (and also Bruce from WR) were at the forefront of fixing that Nov 15 11:02:49 Hi all, I can see tools-debug that can be added to EXTRA_IMAGE_FEATURES Nov 15 11:03:05 How to see list of files that are in this group? Nov 15 11:05:48 drasko: the "tools-debug" image feature is defined in core-image.bbclass Nov 15 11:06:17 this points to packagegroup-core-tools-debug Nov 15 11:06:54 see meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb for what that pulls in Nov 15 11:07:18 bluelightning, where to find ldd tool? Nov 15 11:09:05 drasko: the package containing it is called "ldd" Nov 15 11:09:13 drasko: it is produced by the eglibc recipe Nov 15 11:09:38 hmmm... I can not find it in my SDK Nov 15 11:09:45 what should I bitbake? Nov 15 11:09:48 eglibc? Nov 15 11:09:49 "Gosh, I though ldd, originally a hard-to-maintain script, was obsoleted a long time ago. This command: Nov 15 11:09:49 $ readelf --dynamic Nov 15 11:09:49 provides the same information, and readelf can be found in every cross toolchain." Nov 15 11:10:04 Isn;t this built every time? Nov 15 11:15:05 bluelightning, trying to bitbake eglibc: Nov 15 11:15:07 ERROR: Multiple .bb files are due to be built which each provide virtual/arm-linux-gnueabihf-libc-for-gcc Nov 15 11:15:20 ERROR: Multiple .bb files are due to be built which each provide virtual/libc Nov 15 11:15:34 I am actually using Linaro toolchain Nov 15 11:16:59 I see Nov 15 11:17:34 having no experience with the linaro toolchain I'm not sure if I can help... Nov 15 11:17:59 but you should not need to explicitly build eglibc Nov 15 11:18:11 just add ldd to IMAGE_INSTALL for your recipe Nov 15 11:19:13 bluelightning, yes but bitbake ldd does not work Nov 15 11:19:23 it reports recipe not found Nov 15 11:19:34 I am trying now to add this: meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb Nov 15 11:19:49 drasko: bitbake isn't expected to work, no Nov 15 11:19:57 i.e I added tools-sdk to EXTRA_IMAGE_FEATURES Nov 15 11:20:08 I hope that this will produce ldd Nov 15 11:20:10 drasko: you'd need to add it to IMAGE_INSTALL as I said Nov 15 11:20:18 koen: hi. when/how to you sync beagleboard/meta-beagleboard and koen/meta-beagleboard? i was trying to build your patch for the /boot issue, and realized it's not 'upstream' yet. Nov 15 11:20:27 bluelightning, let me try this Nov 15 11:22:41 ndec: I don't Nov 15 11:22:59 ndec: after I joined linaro my commit access was revoked to "upstream" Nov 15 11:23:17 so there's now "upstream" and "the repo that gets actual updates and fixes" Nov 15 11:23:28 koen: but owns 'upstream', then? Nov 15 11:24:27 I've stopped caring about who owns it Nov 15 11:25:46 koen: well... ok.. i will use yours. Nov 15 11:26:03 mine has a newer u-boot and zImage instead of uImage Nov 15 11:26:21 koen: so fresh uboot finally can boot zimage? Nov 15 11:26:24 hi all Nov 15 11:26:26 it only needs uefi+acpi and ARM ltd will support it Nov 15 11:26:29 hrw: yes Nov 15 11:26:36 hrw: 'bootz' Nov 15 11:26:54 koen: will have to try on chromebook one day Nov 15 11:27:10 koen: so far aarch64 takes most of my day Nov 15 11:27:40 * koen still hasn't setup a fastmodel to actually try armv8 stuff at runtime Nov 15 11:28:06 koen: http://pastebin.com/riSh01Vs may be handy Nov 15 11:28:15 koen: it is my boot-armv8 script Nov 15 11:32:23 thanks! Nov 15 11:33:21 koen: handles foundation model kernel/rootfs, foundation uefi, fullarmmodel Nov 15 11:33:34 morning all Nov 15 11:33:42 hm, this new bundle_initramfs stuff is all a bit weird. Nov 15 11:41:06 hi pb Nov 15 11:41:46 hi woglinde Nov 15 11:50:47 pb_: heh Nov 15 11:50:56 why does this crazy class think that I want it to uncompress my initramfs before bundling it? Nov 15 11:51:31 though, it also seems to be looking for the file with the wrong name in the first place, so I guess the lack of compression is the least of my worries. Nov 15 11:51:48 pb_: do you need modules in the cpio? Nov 15 11:52:07 no Nov 15 11:52:30 I was quite happy doing my own initramfs bundling, but kernel.bbclass seems to like to do that for itself nowadays. Nov 15 11:52:36 which would be fine, if only I could make it actually work. Nov 15 11:52:58 ok, then you could maybe use the old-compat mode, declaring INITRAMFS_TASK Nov 15 11:55:23 yeah, maybe that would be the winning strategy. Nov 15 11:55:38 does the code in kernel.bbclass work for you? Nov 15 11:56:09 http://tinyurl.com/px44nyb Nov 15 11:56:23 we could work arounf the new bundling code Nov 15 11:56:36 and we did Nov 15 11:56:53 right Nov 15 11:57:34 set just the 2 INITRAMFS: vars in kernel recipe. Don't touch local.conf Nov 15 11:57:43 yeah, maybe that's what I should do Nov 15 11:58:49 honestly I gave up trying to understand the reasons behind the new framework. iirc is modver Nov 15 11:59:20 it seems to be something to do with allowing you to put modules in the initramfs without needing to explicitly compile the kernel twice. Nov 15 11:59:41 hm. not only this Nov 15 11:59:50 which is a worthwhile goal, but it's a bit of a shame that it seems to have been done in such a way as to break initramfs generation for situations that previously worked. Nov 15 12:00:15 whith the imageI linked to you I embedded a full core-imagebase and kernel + its modules Nov 15 12:00:33 as proof Nov 15 12:01:00 but surely I'm missing some detail Nov 15 12:01:25 yeah, oh well Nov 15 12:01:31 I'm going to try the INITRAMFS_TASK thing now. Nov 15 12:03:23 no doubt there is some special situation where the new code is important for carrier grade and/or enterprise class systems but fortunately I don't need to worry about such things. Nov 15 12:08:19 right, excellent, that seems to be working Nov 15 12:08:41 seems that one line is all that I need to stop all the new craziness. Nov 15 12:09:30 so what should it be set to to go back to the previous behaviour? Nov 15 12:09:45 this ought to be noted in the migration notes... Nov 15 12:10:14 INITRAMFS_TASK = "${INITRAMFS_IMAGE}:do_rootfs" Nov 15 12:10:17 seems to be the magic Nov 15 12:10:37 however, I just discovered that this loses if INITRAMFS_IMAGE is empty, which it is for some of my configs. Nov 15 12:11:19 since you get: Nov 15 12:11:29 ERROR: Required build target 'brightsign-nfsroot' has no buildable providers. Nov 15 12:11:29 Missing or unbuildable dependency chain was: ['brightsign-nfsroot', 'kernel-modules', ''] Nov 15 12:11:47 which is clearly no good. It seems a bit dim of bitbake to be adding the empty string as a dependency, but still. Nov 15 12:13:04 the easiest fix for that seems to be to patch kernel.bbclass's python (about line 30) to check that both INITRAMFS_TASK and INITRAMFS_IMAGE are non-empty before adding the dependency. Nov 15 12:15:16 pb_: seems there is a new urge for versioned modules http://lwn.net/Articles/21393/ Actually if you create a linux-foo container of the same version you build with the same Symbols so I don't see the problem anyway Nov 15 12:15:49 same version as the kernel/modules in the initramfs Nov 15 12:16:53 pb_: ah, I always set INITRAMFS_IMAGE, once setting this one was enough ;) Nov 15 12:17:20 your fix makes sense, though Nov 15 12:17:58 this alternative path is only taken when INITRAMFS_TASK is set Nov 15 12:18:15 yeah Nov 15 12:18:41 it turns out that you also need another fix: the shell code in kernel_do_compile() also needs to refrain from setting CONFIG_INITRAMFS_SOURCE if INITRAMFS_IMAGE is empty. Nov 15 12:20:19 ant_work: that lwn article that you linked to is from 2003! I'm not sure this counts as a "new urge". :-) Nov 15 12:23:44 ;) a bird talked to me about that kind of reason behind the ework Nov 15 12:24:07 I was also surprised Nov 15 12:24:28 florian: ping about xserver-common :) Nov 15 12:26:07 ant_work: heh Nov 15 12:26:31 right, with those two fixes to kernel.bbclass I am now able to proceed as far as linux:do_package. Nov 15 12:26:59 pb_: in fact CONFIG_MODVERSIONS is still available Nov 15 12:28:54 pb_: do youreally intend topackage and upgrade at runtime ? Nov 15 12:29:04 argh this kb Nov 15 12:34:21 ant_work: are you asking if we use package management on the target? Nov 15 12:34:31 if so, no, we don't. we do upgrades by just reflashing the whole rootfs. Nov 15 12:34:41 pb_: yes, if it is the case, just wrap this kernel in another recipe together with the installer/flasher Nov 15 12:35:56 pb_: I see, we wrap this kernel+cpio like this http://tinyurl.com/mrhwyw5 Nov 15 12:37:32 in theory the flasher could be called as postinst... Nov 15 12:37:40 imo, the kernel.bbclass should be more modularized; e.g. the initramfs stuff can be wrapped into 'INITRAMFS_STYLE ??= "yocto"; include initramfs-${INITRAMFS_STYLE}.inc' Nov 15 12:37:55 this would e.g. remove the expensive "addtask bundle_initramfs after do_compile before do_build" Nov 15 12:38:03 right Nov 15 12:38:41 well, in a sense, that's what ${INITRAMFS_TASK} is: if you set that variable then it magically switches off all the bundle_initramfs stuff. But I agree, it would be nice if this was more explicit and there was a clearer separation. Nov 15 12:39:27 ant_work: our situation is a bit different to that, but yeah, that's approximately what we do as well. Nov 15 12:40:01 we actually have an initramfs in the primary mission kernel for most machines because we need it to mount the rootfs from nand. Nov 15 12:40:22 pb_: the "addtask bundle_initramfs after do_compile before do_build" causes rebuilds of complete kernel due to do_bundle_initramfs[nostamp] = "1"; rp suggested to remove the nostamp but I do not know the sideeffects Nov 15 12:40:40 ensc|w: oh, right, that sucks. Nov 15 12:40:58 I agree with rp, that nostamp should be removed. I don't think it should ever have been added in the first place. Nov 15 12:42:30 anyone seeing build fails for lttng? Nov 15 12:44:19 pb_: my point was that setting the INITRAMFS_IMAGE in local.conf you get it already set around Nov 15 12:44:59 sorry, I still don't understand. why would I want to set that in local.conf? Nov 15 12:45:07 I find rather horrible hack this way to share it between kernel/image rebuilds Nov 15 12:45:26 but again it seems there is no workaround Nov 15 12:46:24 heh, check local.conf.sample.extended Nov 15 12:46:43 oh, I see Nov 15 12:47:30 "NOTE: You can set INITRAMFS_IMAGE in an image recipe, but Nov 15 12:47:31 # INITRAMFS_IMAGE_BUNDLE can only be set in a conf file" Nov 15 12:47:47 that seems pretty bogus. I can't think of any reason why setting INITRAMFS_IMAGE_BUNDLE in a recipe oughtn't to work. Nov 15 12:48:12 but, then, the whole edifice seems fairly bogus anyway. Nov 15 12:49:15 to me it seems indeed a special-case Nov 15 12:49:54 guys, can we start a thread on the mailing list for this? I'd suggest you CC in Jason Wessel who implemented the change Nov 15 12:50:06 pb_: again, it is possible to embed modulex in an initramfs Nov 15 12:50:42 pb_: try yourself for fun embedding a core- image ;) Nov 15 12:51:11 ant_work: why does that require you to set this variable in a .conf file? Nov 15 12:52:32 afair otherwise the kernel doesn't embed any cpio Nov 15 12:52:54 initially I tried to adapt that ecipe to the new style Nov 15 12:52:57 surely if it's set in the kernel's own recipe then that ought to suffice, right? Nov 15 12:53:14 but failed ...so I was told to set it in the local.conf Nov 15 12:53:52 ah, well, fair enough I suppose. Nov 15 12:54:03 did not suffice last I tried... Nov 15 12:54:45 pb_: there are more issues for initramfs anyway... Nov 15 12:55:28 seems there are unconditionally created dirs, update-rc and postinst iirc Nov 15 12:55:41 it's hard to keep the cpio clean ;) Nov 15 12:56:22 but this is totally another issue Nov 15 12:59:49 oh, that sucks as well Nov 15 12:59:52 I hadn't noticed that. Nov 15 13:00:42 bluelightning: pb_: I added my observations in the september thread http://lists.openembedded.org/pipermail/openembedded-core/2013-September/084829.html Nov 15 13:00:56 I really don't know what to add more than that Nov 15 13:02:39 this was the august thread: http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082921.html Nov 15 13:03:36 if this is not really working for more than just one person I think it's worth having a wider discussion Nov 15 13:04:01 well, it does work but maybe not optimally Nov 15 13:05:36 I just sent a patch for the two bugs that I encountered this morning. Nov 15 13:05:41 ok, cool Nov 15 13:05:50 ensc|w: will you send a patch to remove the spurious nostamp? Nov 15 13:06:15 I'll have a read through those two threads and see if I have anything useful to add. Nov 15 13:06:31 I don't have them in my inbox any more since hetzner deleted all my old oe-core email but I can read them in the archive. Nov 15 13:07:57 We'd really need a dummy recipe showing exactly the needs some entities encounter Nov 15 13:09:02 afair was about CONFIG_MODVERSIONS Nov 15 13:12:32 pb_: I can not test such a patch (e.g. whether initramfs will be recreated when deps change) Nov 15 13:13:40 well, bitbake's task dependency tracking works for every other task in the system. Nov 15 13:14:13 I don't think there's any particular reason to believe it would fail here. Nov 15 13:18:02 is it possible to define a machine alias, or inherit completely from an existing machine type? Nov 15 13:20:18 not entirely straightforwardly. you can "require other-machine.conf" and add other-machine to OVERRIDES explicitly, but I'm not sure this guarantees that you would get everything that it does. Nov 15 13:20:45 MACHINEOVERRIDES, I guess, not OVERRIDES Nov 15 13:21:41 hm, I just realised that even with those changes to kernel.bbclass I still lose because copy_initramfs() is looking for the wrong filename. Nov 15 13:21:51 thx Nov 15 13:22:15 I guess there must be some other magic that's needed. ant_work, how is it that your initramfs images in tmp/deploy/images/ don't have ".rootfs" in the name? Nov 15 13:23:18 also, what is "lzmash"?! Nov 15 13:25:09 pb_: I set it in kernel config Nov 15 13:40:49 it feels like lttng-ust has issues when you change machines? Nov 15 13:46:31 what was lttng usefull for? Nov 15 13:48:55 koen: in your most recent meta-beagleboard patch, i think s/kernel-devicetrees/kernel-devicetree/ could be useful ;-) Nov 15 13:49:16 tracing I think Nov 15 13:54:44 pb_: sorry, I'm back now Nov 15 13:55:26 pb_: are you setting INITRAMFS_IMAGE_BUNDLE ? Nov 15 13:55:34 no, not any more Nov 15 13:55:57 I'm now using the old-style stuff with INITRAMFS_TASK. Nov 15 13:56:16 everything seems to be working fine except that copy_initramfs() is looking for the wrong file in deploy/images. Nov 15 13:56:51 it wants ${INITRAMFS_IMAGE}-${MACHINE}.cpio, but what I actually have is ${INITRAMFS_IMAGE}-${MACHINE}.rootfs.cpio. Nov 15 13:57:19 and I can't see any obvious way to persuade the image builder to stop putting that ".rootfs" in there. Nov 15 13:57:52 I was also previously having some lzmash trouble but I sent a patch for that. Nov 15 14:00:29 ndec: ah right, khem renamed it Nov 15 14:00:43 ndec: in 'dylan' is was plural since it has multiple DTs Nov 15 14:00:48 but we changed it to match oe-core Nov 15 14:04:19 ndec: should be fixed now Nov 15 14:06:16 koen: thx Nov 15 14:08:05 pb_: a suspect Nov 15 14:08:42 try to set INITRAMFS_FSTYPES ?= "cpio.gz cpio.lzma" Nov 15 14:09:25 in your machine.conf and IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" in the image Nov 15 14:09:45 so we are sure about the suffixes Nov 15 14:10:40 I already have IMAGE_FSTYPES = "cpio.lzma" in the image recipe. Nov 15 14:10:52 INITRAMFS_FSTYPES doesn't appear to be used by anything in oe-core so I don't think it can be significant. Nov 15 14:10:53 ok then Nov 15 14:11:06 the only redefinition we do is for the kernel symlink Nov 15 14:11:28 pb_: I see in bitbake.conf INITRAMFS_FSTYPES ?= "cpio.gz" Nov 15 14:11:36 hm, right. and your image ends up in tmp/deploy/images/.../ without the ".rootfs" bit in the name, right? Nov 15 14:11:43 yup Nov 15 14:11:58 ant_work: yeah, it's set there, but nothing looks at that value except core-image-minimal-initramfs.bb Nov 15 14:12:04 and that latter recipe only uses it to set IMAGE_FSTYPES Nov 15 14:12:19 so it doesn't seem that INITRAMFS_FSTYPES is serving any real purpose, it appears just to be a decoy. Nov 15 14:13:01 there was once a split, maybe for clarity, can't remember Nov 15 14:13:30 the scope is only for that image anyway Nov 15 14:13:51 right Nov 15 14:14:48 so, IMAGE_CMD_cpio (in image_types.bbclass) seems to be fairly clearly hardwired to add the ".rootfs" Nov 15 14:15:08 cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio) Nov 15 14:16:36 check at the bottom Nov 15 14:17:23 of what? Nov 15 14:18:39 all COMPRESS_CMD are doing that Nov 15 14:18:53 doing what? Nov 15 14:19:04 > ${IMAGE_NAME}.rootfs. Nov 15 14:19:38 right Nov 15 14:19:48 so I still don't understand how your images are ending up without the ".rootfs" Nov 15 14:20:17 both IMAGE_CMD_cpio and COMPRESS_CMD_* seem to use ${IMAGE_NAME}.rootfs.${type} Nov 15 14:23:31 pb_: I'll check later exactly, what I can say is last I verified in detail was when this fix was pushed: Nov 15 14:23:32 http://cgit.openembedded.org/openembedded-core/commit/meta/classes/kernel.bbclass?id=36faac868e086e9c23537b107cdd973d7fd980bd Nov 15 14:26:13 pb_: now that I see it, it looks like the cpio is indeed decompressed..will verify Nov 15 14:28:21 pb_: up to that I was copying part of the old code, like that Nov 15 14:28:22 http://patchwork.openembedded.org/patch/59077/ Nov 15 14:52:40 righto, thanks Nov 15 14:54:39 bluelightning: that might explain the kernel oversize I've seen recently Nov 15 15:03:48 decompressing the initramfs doesn't seem totally unreasonable (since it will get re-compressed as part of the kernel image anyway) but it does seem a bit surprising. Nov 15 15:04:16 you'd think that people who wanted to embed an uncompressed image into the kernel would just select an uncompressed format for their initramfs in the first place, rather than compressing it and then immediately decompressing. Nov 15 15:05:04 pb_: I'm badly needing that 30-40 kb ;) Nov 15 15:06:18 heh | ERROR: This kernel (size=1058824 > 1048576) Nov 15 15:07:01 pb_: fwiw xz (lzma2) has some marginal gain over lzma (1) Nov 15 15:07:57 pb_: 0,5% in my tests with mini-kernel Nov 15 15:08:07 do you find that you get better results by xz'ing the initramfs before it's embedded than just from xz'ing the entire kernel+initramfs in one go? Nov 15 15:08:31 I'd assumed it would be the other way around. Nov 15 15:08:34 when I tested it, it was much better to compress the cpio before Nov 15 15:08:49 oh, right, strange. using xz for both, right? Nov 15 15:09:39 pb_: honestly I did check yesterday changing only kernel to xz and letting cpio.lzma (or at least I think, maybe is uncompressed) Nov 15 15:31:04 bbl Nov 15 16:56:35 pb_: compression seems respected: I see in kernel do_compile GEN usr/initramfs_data.cpio.lzma Nov 15 17:01:55 pb_: and about the foobar-rootfs.cpio, symlinks are created Nov 15 17:03:06 check out run.do_rootfs , end of do_rootfs() Nov 15 17:03:32 I have # Now create the needed compressed versions Nov 15 17:04:25 and # And create the symlinks Nov 15 18:52:44 building oe on a btrfs fs sucks :( disk io related tasks are extremely slow so that building an image which was built on ext4 in 1 hour needs now 5 hours :( Nov 15 18:53:25 ouch Nov 15 18:54:01 might be better on an ssd, but defragmentation on spinning disks is horrible Nov 15 18:55:12 defragmentation is very slow so that a recursive 'btrfs fi defragment' will finish in around 10 years or so Nov 15 19:09:28 ensc|w: thank you! that's good information to know for those people using distributions which are considering moving to btrfs by default (e.g. openSUSE) Nov 15 21:06:47 how can I override the local gcc binary used by oe? Nov 15 21:53:59 ccube: you mean use an an external toolchain instead of the default? Nov 15 22:29:30 Can someone put http://www.mlbassoc.com/misc/xserver-common-1.34.tar.gz in the mirror? this is missing and many people complaining about failures Nov 15 22:38:35 ka6sox: ^ Nov 15 23:21:54 hi. i use some years ago openembedded-clasic to create images for mobile phones. recently i wanted to recompile a image for the sciphone that exist as reciepe in the oe-classic version but found out that the project changed the very easy build process. now it only provide a core functionallity with missing all the reciepes. my question is how can i create a image with oe-core for the sciphone? Nov 15 23:22:43 the majority of recipes from oe-core are just split into other layers Nov 15 23:22:43 meta-oe, meta-multimedia, meta-handhelds, etc Nov 15 23:23:02 you just need to glue together the right hardware and software layers (or re-use a distro that does this, such as angstrom) Nov 15 23:23:55 meta-smartphone, but iirc nobody migrated sciphone Nov 15 23:24:09 xperia: there is also wiki page about abandoned oe-classic recipes Nov 15 23:24:19 layers.openembedded.org/layerindex/ and this will help you as well Nov 15 23:25:08 rburton: hmmm to be honestly this sound quite complicated compared to openembedded-clasic. i nned to have sciphone as it looks like it is the only reciepe for the mediatek MTK SOC Platform ... Nov 15 23:25:59 xperia: oe-classic was "quite complicated" when it was everything in a single place... Nov 15 23:26:14 xperia: feel free to continue using oe-classic if you want though, the source is still there :) Nov 15 23:27:26 rburtun: i disagree. find openembedded-classic as a user, builder and image creator much more better and easyer. really pity that you changed this. can not understand it. Nov 15 23:28:11 compare the 5+ minute parse times of oe classic to how it is now, for one. for two, layers have maintainers, unlike pretty much anything in classic.. that's just to start with, off the top of my head Nov 15 23:29:45 kergoth: if it is that much better why a simple question like how can i create the image for the sciphone can not be answered with openembedded-core. with openembedded-classic the answer will be just go to the directory of your mashine and execute bitblake. Nov 15 23:29:58 again, go the layer index Nov 15 23:30:01 as you were told to already Nov 15 23:30:13 xperia: jama told you, nobody migrated that one yet Nov 15 23:30:36 or feel free to use oe-classic if you find it that much better. Nov 15 23:30:48 yeah, you can still use it with an old bitbake, feel free, but you'll be maintaining it yourself Nov 15 23:31:38 and it's not a matter of "better" or "worse". as with anything else, there are tradeoffs. it was felt this had more advantages than disadvantages Nov 15 23:35:37 xperia: migrating recipes from oe-classic is in most cases fairly simple, if you want to maintain sciphone, send patch for meta-oe or meta-smartphone and I'll happily apply it Nov 15 23:36:56 xperia: you're first (we know of) who wants to use sciphone, so don't compare whole build system by availability of one fairly unused recipe Nov 15 23:43:20 JaMa: i want try to build sciphone with openembedded-core but first i am confused with all this new hierarchy and second i just looked to find meta-smartphones in my oe-core git clone and i cant find it, beside this also step by step instructions and information for porting old reciepes can not be find with google really. you may say that this is a non used reciepe but you have to know that... Nov 15 23:43:21 ...this reciepes actually represent the future of embedded linux. on kickstarter just recently backsers spent over 1'000'000.--- US Dolars for the nearly exaclty SoC Platform and guess what this platform was supported in oe-classic and now is not supported in oe-core! what does this tell about openembedded. in my opinion that openembedded does not go with the time really. Nov 15 23:47:39 xperia: yeah like xserver-kdrive used in sciphone_g2.conf.. that's the future :) Nov 15 23:48:37 JaMa: last week i learnt that kdrive from xorg git hasn't worked for ~ 18 months Nov 15 23:50:47 I've switched from kdrive on om-gta02 few years before that, so I was lucky :) Nov 15 23:53:27 JaMa: rburtuon: I am talking about this Embedded Device here that is based on the same MediaTek MTK SoC like the SciPhone and got 1000% more money than it requested on Kickstarter => http://www.kickstarter.com/projects/omate/omate-truesmart-water-resistant-standalone-smartwa Nov 15 23:53:29 Ofcourese tweeks of the old reciepe would be necessary but at least i would have with openembedded-clasic a base to start. with oe-core i have nothing! Nov 15 23:58:05 hm, the automatic package upgrader claims to have a vala upgrade patch for me, but the only way to test it is to build webkit Nov 16 00:00:45 xperia: oe classic recipes can be ported to oe core trivially, as you've been told multiple times already Nov 16 00:11:45 xperia: tune-arm926ejs.inc is available in oe-core, linux-mtk, u-boot-mtk belong to BSP layer, what else are you missing? Nov 16 00:21:12 JaMa: hmmm i can not find anything like this in my OE-Core Installation that was installed based on the official oe wiki http://www.openembedded.org/wiki/OE-Core_Standalone_Setup Could it be that you have a total different setup? I searched the Wiki Page for Information to improve my OE-Core installation but could not find anything. Nov 16 00:22:14 maybe i am looking also in the wrong directory. /meta/conf/machine does not have anything like this Nov 16 00:22:54 xperia: meta/conf/machine/include has the tune file Nov 16 00:27:11 xperia: yes the layout is completely different Nov 16 00:28:58 xperia: with layers it's "modular" so people can fetch multiple layers from different sources and use them together Nov 16 00:30:31 JaMa: rburton: okay thanks a lot have found now tune-arm926ejs.inc did not look in the include directory. my fault. asking me now how can i build a minimal image with x11 for testing on a MediTek SoC Platform- its really bad that i can not find on the internet some good OE-Core explaing tutorial and the wiki does not provied really this information Nov 16 00:31:07 xperia: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html is the current documentation Nov 16 00:33:59 rburton: thanks a lot. studying it at the moment. will try it out for sure. Nov 16 00:34:33 oh god will webkit please finish compiling Nov 16 00:35:07 xperia: check BSP manual as well, that's what you'll need soon Nov 16 00:35:25 rburton: is it major vala upgrade? check meta-fso layer, it uses vala quite havily Nov 16 00:35:44 rburton: and most major vala upgrades required many changes in fso components :/ Nov 16 00:36:10 yeah its 0.16 -> 0.22. totally expect breakage in even oe-core and probably need to version the recipes. Nov 16 00:37:29 to be honest *not* versioning the vala recipe so you can parallel install several copies sounds like a dangerous thing to do Nov 16 00:38:00 might just have to do that. will test with meta-fso, thanks. Nov 16 00:47:38 building the first minimal image under oe-core with a minimal modifyed local.conf version targeted for the arm machine. looking forward to my first sucess experience with oe-core lol Nov 16 01:03:30 JaMa: rburton: while the image is building with openembedded i would like to ask what would be needed to port ubuntu-touch (the new promising user interface for mobile devices) to openembedded? exist some people who are working on this allready? i am interessted having ubuntu-touch in openembedded if i succeed to build a image for the MediaTek Platform. Nov 16 01:04:17 with having i mean that i would put effort to get it working with openembedded. Nov 16 01:06:41 we have some components from ubuntu-touch in meta-smartphone and meta-webos-ports, but not trying to support it from OE, just cherry-picking useful pieces for our images Nov 16 01:13:03 JaMa: thanks a lot for your very helpfull and informative answers. good to know that you have allready some ubuntu-touch components. my focus is to try using openembedded for the new computer watch phones that are getting more and more popular. i have allready several buyed but i am absolute not happy with the android software on it. hope to be able to create my own linux based images and... Nov 16 01:13:04 ...flash it on the devices. Nov 16 01:20:39 xperia: sounds like exciting project, good luck with that Nov 16 01:25:32 JaMa: thanks a lot. its a very painfull undertaken. i have spent the last 3 Months only to get the Linux Kernel Sources for the MediaTek SoC Platform and to rebuild finally the kernel for the device. Hoped to be able to test the Kernel on the Android Virtual Mashine with the Manufacturer ROM only to discover that the Android Virtual Mashine Emulator accept a sepcific Kernel called GoldFish.... Nov 16 01:25:33 ...Android drives me Crazy. Nov 16 02:09:24 otavio, sourcemirror updated **** ENDING LOGGING AT Sat Nov 16 02:59:59 2013