**** BEGIN LOGGING AT Wed Nov 21 02:59:58 2012 Nov 21 08:05:28 good morning Nov 21 09:53:23 morning all Nov 21 09:54:21 hi bluelightning Nov 21 10:15:02 hi Noor Nov 21 10:53:47 i made a custom distro that inherits from defaultsetupd.conf, and i'd like to remove ipv6 from DISTRO_FEATURES_LIBC_DEFAULT, anyone knows an easy way to do that ? Nov 21 10:57:15 afournier: if it's your own custom distro you should just set DISTRO_FEATURES to your own desired value Nov 21 10:57:23 ok Nov 21 10:58:26 (we do have the DISTRO_FEATURES_BACKFILL mechanism to handle features added in future that would otherwise cause reduction in functionality by not being present in custom values of DISTRO_FEATURES) Nov 21 11:00:56 so ipv6 will be removed if i do DISTRO_FEATURES="largefile ipv4" for example ? Nov 21 11:02:20 yep Nov 21 11:02:27 great Nov 21 11:03:32 you will probably want to include more than just those features though Nov 21 11:07:58 (e.g. you're eliminating all libc features, that's probably going to break things) Nov 21 11:08:23 hello all Nov 21 11:09:13 hi eren Nov 21 11:10:01 bluelightning: setting 2 features like in my example, will remove all the libc features ? Nov 21 11:10:32 afournier: yes Nov 21 11:10:32 bluelightning: i was setting DISTRO_FEATURES instead of DISTRO_FEATURES_LIBC_DEFAULT Nov 21 11:10:37 ok Nov 21 11:10:38 afournier: run bitbake -e | grep DISTRO_FEATURES and you will see what its current value is Nov 21 11:10:47 ok Nov 21 11:10:48 thx Nov 21 11:11:46 FYI you can use oe_filter_out() in conjunction with := to remove just one feature, but personally I think that's messy Nov 21 11:18:25 the tmp directory became tmp-eglibc-eglibc instead of tmp-eglibc (wtf?) Nov 21 11:31:37 what is the best way to cleanup the deploy directory? Nov 21 11:31:51 i.e. only leave the latest iterations of each image Nov 21 11:31:58 kernel, u-boot etc... Nov 21 11:32:33 the readme mentions cleaning up the image after removal, but I don't want to clean the entire image, just the old ones Nov 21 11:37:26 afournier: that doesn't sound right... Nov 21 11:38:30 bluelightning: i guessed Nov 21 11:38:32 :) Nov 21 11:38:41 bluelightning: but i still don't know why Nov 21 11:39:12 is it ok to require conf/distro/defaultsetup.conf at the begining ? Nov 21 11:39:45 that's already included by bitbake.conf Nov 21 11:39:57 ah ok Nov 21 11:40:12 so you have meta/conf/distro/defaultsetup.conf:TMPDIR .= "${TCLIBCAPPEND}" Nov 21 11:40:15 twice Nov 21 11:40:21 that's why then Nov 21 11:40:25 thanks Nov 21 11:41:32 JaMa: good catch, thanks Nov 21 11:54:51 I like the new bitbake/knotty2 changes, it's amazing what a difference and bit of bold text and colour does! Nov 21 11:55:08 s/and/a Nov 21 13:19:54 Hi all, I have a question. I wan't to output the terminal to fb0 this is currently being written to ttyAMA. does anyone here know what I need to change? If u need more information please let me know. thanks, Nov 21 13:23:53 you need a kernel with fbconsole or such and need to put a getty on it Nov 21 13:29:05 is it not possible to duplicate the output wich is written to ttyAMA tot fb0 ? Nov 21 16:04:21 I am seeing this now: http://pastebin.com/B0ypEqSk Nov 21 16:25:39 Crofton|work: I wonder if we should be removing unsafe-references-in-binaries and unsafe-references-in-scripts from the default WARN_QA value Nov 21 16:26:12 out of my expertise area :) Nov 21 16:26:35 I just want to see if I can get to a point where my builds ahve no QA errors :) Nov 21 16:26:41 bluelightning: I agree, there are more important QA warnings then this one to show Nov 21 16:27:19 if someone submits a patch to do this I will ack it... Nov 21 16:27:53 (as long as there is a decent commit message) Nov 21 16:32:45 * JaMa would ack it too Nov 21 16:34:50 I'll see if I can figure out how the QA stuff works .... Nov 21 16:37:18 Crofton|work: it's just a series of named values one for each test that can appear either in WARN_QA or ERROR_QA or neither - see meta/classes/insane.bbclass Nov 21 16:37:51 the default values for WARN_QA and ERROR_QA for OE-Core are set within that class as well Nov 21 16:59:22 so unsafe refs is basically thing in / that depend on things in /usr? Nov 21 17:01:00 why do we want to disable the warning? Nov 21 17:03:53 Crofton|work: because those particular warnings are only interesting to people who want / and /usr on separate filesystems Nov 21 17:04:37 ok, just trying to make sure what I put in commit message makes some sense Nov 21 17:04:50 pb_, can you update the board alias on ltg? Nov 21 17:04:59 (which, afaict, nobody outside wind river does) Nov 21 17:05:17 Crofton|work: yes, sure. who should be on it now? Nov 21 17:05:33 I'll send you an email Nov 21 17:05:37 ok, thanks Nov 21 17:05:53 I need to see what address likewise and Sean want to use Nov 21 17:07:09 righto Nov 21 17:10:18 -WARN_QA ?= "ldflags useless-rpaths rpaths unsafe-references-in-binaries unsafe- Nov 21 17:10:19 +WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir xorg-driver-abi text Nov 21 17:10:19 ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la perms Nov 21 17:10:30 is the right way to disable them? Nov 21 17:10:47 yes Nov 21 17:11:14 that is the easy part Nov 21 17:26:59 khem: ping Nov 21 18:29:08 WARNING: QA Issue: udev: Files/directories were installed but not shipped Nov 21 18:29:08 /usr/sbin Nov 21 18:29:17 after surpressing the oterh warnings Nov 21 18:51:41 crofton wasnt there a long thread on the ml about the udev tools Nov 21 19:13:15 Hi. I have a program that is the session manager and I want x-session-manager to be a link to it. What's the proper way to do that with update-alternatives? I'm trying Nov 21 19:13:15 ALTERNATIVE_${PN} = "x-session-manager" Nov 21 19:13:15 ALTERNATIVE_LINK_NAME[x-session-manager] = "${bindir}/oskiosk-manager" Nov 21 19:13:19 but it generates Nov 21 19:13:22 update-alternatives --install /usr/bin/oskiosk-session x-session-manager oskiosk-session.oskiosk-session 10 Nov 21 19:13:25 in the postinst file. Nov 21 19:13:28 In the end, what I want is just "ln -s ${bindir}/oskiosk-manager ${bindir}/x-window-manager" Nov 21 19:13:34 hi mario-goulart Nov 21 19:13:50 Hi woglinde Nov 21 19:14:07 mario update-alternatvies is the right way Nov 21 19:15:10 okay my son needs me Nov 21 19:15:12 till later Nov 21 19:15:19 :-) Nov 21 19:23:51 Hmm, should add a statusbar to knotty with context (machine, distro, ..) so i remember what the hell i was building in which window without scrolling back to the build summary Nov 21 19:33:57 damn it, ran out of chocolatwe, must go back to .eu Nov 21 19:40:41 why base_prefix is set to STAGING_DIR_NATIVE in cross.bbclass? Nov 21 19:41:18 because that's where native stuff is built, installed, and run Nov 21 19:42:13 ideally everything would be happily relocatable, but this is the real world. we set prefix into staging, then mangle and unmangle (sed, etc) the paths to adjust things to make the sstate archives reusable in other locations Nov 21 19:42:54 I was surprised to see such a long path: http://paste.debian.net/211332/ Nov 21 19:44:02 kergoth: oh, I guess I won't delve into how cross compiling is done in OE yet Nov 21 19:44:27 however, I would love to get any written doc about the idea behind changing base_prefix Nov 21 19:44:32 mangling, unmangling etc Nov 21 19:46:19 native isn't crosscopmiling by definition Nov 21 19:46:26 native is native. binaries built for the build machine, to run on the build machine Nov 21 19:47:13 right. It's defined in "cross.bbclass" so I thought it's related with cross compiling Nov 21 19:48:21 cross is used to build crosscompilers, its true, but it isn't for crosscompiling things Nov 21 19:48:31 as a result, the outpuot of such builds is tied to both the build machine and the target Nov 21 19:48:48 so it gets installed into the native sysroot, but its binaries are dropped in a target specific location Nov 21 19:49:26 sorry, my comments on native were because i misread the original question Nov 21 19:49:31 hopefully that makes it clearer Nov 21 19:58:09 kergoth: thanks, but I still miss the basic, why do we need to change base_prefix for *-native packages? I was just delving into the directories and saw the directory structure that I pasted. I later found that in {cross,native}.bbclass , base_prefix is changed. I would be happy to learn why this is done so, and what's the use case Nov 21 19:58:24 I just told you Nov 21 19:59:20 a great deal of software is not relocatable. this means it has to run where it's built to go. native/cross software runs from staging, so that's where it gets built to go and installed Nov 21 20:03:57 thanks, it's more clear now. By 'not relocatable', I understand that a great deal of software does not obey the flags, paths that we gave on build. Hence, we fake the environment? Nov 21 20:16:27 eren yes and to mot interfere with host installed stuff Nov 21 20:16:34 ups not to Nov 21 20:20:15 thanks Nov 21 20:59:43 heh, apparently eren doesn't own a dictionary. relocatable, as in 'relocate' Nov 21 21:51:26 otavio: ping **** ENDING LOGGING AT Thu Nov 22 02:59:58 2012