**** BEGIN LOGGING AT Mon May 20 02:59:59 2013 May 20 03:20:59 should we remove tinylogin and enable the login applets in busybox? last tinylogin release was 10 years ago and it has since been integrated into busybox May 20 06:58:27 Hi, does anyone have any idea about yocto openssl warning "WARNING: can't open config file: /usr/lib/ssl/openssl.cnf" ? May 20 07:05:54 qchen2: /usr/lib/ssl/openssl.cnf isn't installed unless you install openssl-misc as well May 20 07:07:50 thanks, is there other method except using RRECOMMENDS_libcrypto += "${PN}-misc" to add openssl-misc ? May 20 07:08:59 I mean I want to build the openssl-misc to rootfs automatically. May 20 07:09:22 qchen2: IMAGE_INSTALL += "openssl-misc" ? May 20 07:10:49 Got it. Thanks a lot ! May 20 08:44:52 morning all May 20 08:50:06 hi bluelightning May 20 08:52:17 hi RP May 20 09:45:45 good morning May 20 14:15:52 hi there. is it 'safe' or supported to build for several different MACHINES in the same build? is OE/bitbake going to build common packages only once (as expected)? what if the 2 MACHINES are a panda and a beagle both built with armv7-hf, are most packages built once? May 20 14:16:26 and in that regards can we do MACHINE = "pandaboard beagleboard" and expect to get 2 complete builds? May 20 14:16:56 you can only set MACHINE to a single value May 20 14:17:35 i've been doing: set MACHINE, do a build, change MACHINE, do another build. seems ok to me so far May 20 14:17:37 ndec: use the same sstate cache and tmp dir for both builds and all relevant parts will be reused May 20 14:17:40 it's safe to build for multiple machines in a single tmpdir, but it's multiple bitbake commands May 20 14:17:51 it will mostly work but its not supported to switch MACHINE in a build dir May 20 14:18:10 but thanks to sstate when it breaks you can just delete sysroot and it will rebuild in seconds May 20 14:18:20 rburton: really? I've done that for ages and have yet to hit a snag :) May 20 14:18:27 Zagor: oh me too :) May 20 14:18:31 its just not supported May 20 14:18:44 for a while we hit file conflicts in sysroot messages doing it, but i think those have been fixed now May 20 14:18:55 hmm... what if this is needed to be deployed in a 'production system'. e.g. i need something which is known to be supported. May 20 14:19:07 ndec: multiple build directories sharing a sstate May 20 14:19:18 ie ". oe-init-build-env build-panda" May 20 14:19:25 and build-beagle May 20 14:19:34 tell the conf files to use the same sstate and you're sorted May 20 14:19:42 ok, i see. May 20 14:19:57 thanks. May 20 14:20:19 Zagor: if you have two BSPs that have the same package but different versions, you'll get breakage. hours of fun flipping between eg atom-pc and emenlow, as they have different X servers May 20 14:20:34 i added some checks to make that error out at image time instead of when X starts May 20 14:20:53 the earlier the better ;-) May 20 14:21:02 ah, ok. yeah the machines I switch between are more different than that. May 20 14:24:32 also, tell them to use the same downloads directory May 20 14:24:59 Do you have any recommendations for handling package feeds for multiple machines? As they'll each put packages in 'all'. I'm currently leaning towards one feed per MACHINE, set in the config that gets written to the image. May duplicate a bit but not much and ensures there isn't any clashes. May 20 14:25:58 packages put to "all" should be the same for all MACHINEs you're building May 20 14:26:20 if they are not, then it's issue in metadata (you can use sstate-diff-machines script to detect such cases without building them) May 20 14:35:57 rburton: one more thing... if i do what you suggested, i will end up duplicating the 'deploy/ipk' folder which contains more or less the 'same' thing for 2 machines. so there is no way to 'construct' a unified package repo across multiple machine builds? May 20 14:36:23 you could merge the contents and re-generate the package index May 20 14:38:29 well. ok. May 20 14:39:01 doing a rsync from the repos that bitbake writes to a centralised repo that you then re-generate the indexes on won't be hard May 20 18:21:11 I'm trying to make it so I can include syslinux tools in a nativesdk. syslinux depends on mtools, which in turn depends on glibc-gconv-ibm850. I can't seem to figure out where that package comes from? May 20 18:22:00 I see it depended upon in a few places, and I see it referenced in meta/conf/distro/include/tclibc-eglibc.inc May 20 18:22:22 tclibc-eglibc.inc gets referenced in meta/conf/distro/defaultsetup.conf May 20 18:22:59 any suggestions? May 20 18:25:00 glibc-goconv should come from eglibc May 20 18:26:09 yeah, given the tclibc- business, I thought that'd be reasonable May 20 18:26:44 but then eglibc already supports nativesdk, no? May 20 18:27:47 I'm seeing "Missing or unbuildable dependency chain was: ..., 'nativesdk-syslinux-isolinux', 'nativesdk-mtools', 'nativesdk-glibc-gconv-ibm850'] May 20 18:31:23 hum, I see eglibc-gconf-.* in glibc-locale.inc May 20 18:32:04 ok, it's eglibc-locale May 20 18:32:07 the locale packages come out of eglibc-locale, using files put in the sysroot by the main eglibc recipe May 20 18:32:18 which doesn't have nativesdk support May 20 18:32:31 kergoth`: thanks May 20 18:49:58 I have a more general question. Say I have package X that, out of the box, doesn't inherit nativesdk and doesn't BBCLASSEXTEND nativesdk. Other than creating a .bbappend for that recipe, is there another way to coerce it into a nativesdk package? May 20 18:50:58 I'm afraid I'm introducing a maintenance nightmare, for when X_Y goes to X_Y+1 I'll need to move/copy .bbapend files May 20 18:51:05 best to use a bbappend to add to BBCLASSEXTEND. could try BBCLASSEXTEND_append_pn-eglibc-locale = " nativesdk" or something, but i've never tried that May 20 18:51:28 it's worth a short May 20 18:51:35 shot* May 20 21:02:27 Hmm, forgot about http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-March/004613.html, wonder if something along those lines would be useful again nowadays May 20 21:02:29 * kergoth` ponders May 20 21:37:02 halstead: yay on the mailing lists! May 20 21:37:59 RP, Thank you. May 20 21:38:34 RP, florian and I just found out the bitbake-devel@list.openembedded.org didn't get moved. May 20 21:38:42 RP, Do you know if it should be? May 20 21:38:50 halstead: yes, it should May 20 21:39:02 halstead: I just sent mail to that, was wondering where it went... May 20 21:41:36 RP, Do you have the list admin passwords on linuxtogo? May 20 21:42:36 halstead: I do for some of them May 20 21:43:17 RP, Could you visit http://lists.linuxtogo.org/cgi-bin/mailman/admin/openembedded-core/privacy and turn off announcement? May 20 21:43:48 halstead: done May 20 21:51:04 RP, Thanks. bitbake-devel is online now. I think you will need to repost. May 20 21:54:15 halstead: ok, will resend the mails May 20 21:55:53 * RP sighs. Sending several emails at once appears to deadlock evolution :/ May 20 21:57:07 a deadlocked evolution sounds like a bad thing for mankind! May 20 22:02:46 halstead: resent and it appears to be flowing through this time May 20 22:03:59 * halstead cheers. May 20 22:15:53 kergoth`: on the note of that kind of recipe data, yocto has its package reporting system. For some reason the code isn't shared but that should get sorted shortly May 20 22:16:06 (driven by distrodata.bbclass) May 20 22:16:38 I'll have to take a closer look at that, never looked at how that stuff works. **** ENDING LOGGING AT Tue May 21 02:59:58 2013