**** BEGIN LOGGING AT Mon Jul 15 02:59:58 2013 Jul 15 08:16:57 morning all Jul 15 08:18:12 What's the recipe option to keep a package back from beig selected? I have a version 0.17 which I wish to keep back in favour of 0.14, only installing 0.17 if explicitly requested. Jul 15 08:22:23 jonatan: PREFERRED_VERSION Jul 15 08:23:57 rburton: That won't change the default version though? I guess I want to disable my newer version unless it is explicitly specified using PREFERRED_VERSION in local.conf Jul 15 08:24:56 DEFAULT_PREFERENCE Jul 15 08:25:08 but that work only when all versions are in the same layer Jul 15 08:25:32 Ah, that's it! Thanks! Jul 15 08:27:22 morning all Jul 15 08:29:31 what is PACKAGECONFIG variable? Jul 15 08:29:43 in xorg-xserver.inf, it has: Jul 15 08:29:43 +PACKAGECONFIG[dri] = "--enable-dri,--disable-dri,glproto mesa xf86driproto" Jul 15 08:30:59 PACKAGECONFIG is used per recipe to enable/disable part of the package's functionality Jul 15 08:31:08 I couldn't find a reference in either poky reference manua Jul 15 08:31:15 c00kiemon5ter: ok, but how does it take effect? Jul 15 08:31:19 eren: www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGECONFIG Jul 15 08:31:20 ie, vim may be built with ruby support but that requires ruby as a dependency Jul 15 08:31:39 bluelightning: oh, thanks Jul 15 08:31:42 you can use PACKAGECONFIG in order to have ruby "optional" Jul 15 08:32:51 ah got it Jul 15 08:32:55 how do you enable that feature, then? Jul 15 08:33:08 there's a PACKAGECONFIG variable that sets a default Jul 15 08:33:14 and your distro conf/local conf can override it Jul 15 08:33:50 ok, say I want to enable 'ruby' feature in vim Jul 15 08:34:10 how should I enable, or disable that in my distro/local conf? Jul 15 08:34:40 PACKAGECONFIG_pn-vim_append = " ruby" Jul 15 08:35:03 (to add it, or just override it without the append) Jul 15 08:35:59 okkie, thanks Jul 15 08:36:06 I just found that it was used in dbus-glib package Jul 15 08:36:18 PACKAGECONFIG_pn-${PN} = "tests" enable regression tests local.conf Jul 15 08:36:33 that won't work Jul 15 08:36:48 should fix that Jul 15 08:36:57 in local.conf, what's ${PN}? :) Jul 15 08:37:25 rburton: ah, it's dbus-glib :) Jul 15 08:37:30 I just copied from the recipe Jul 15 08:37:42 PACKAGECONFIG_pn-dbus-glib = "tests" Jul 15 08:37:51 should be the right way Jul 15 08:37:56 ok thanks, I got it :) Jul 15 08:49:49 good morning Jul 15 11:25:48 bluelightning: rburton: so we'll pull xinput-calibrator. Don't forget the patch for removing it from meta-oe Jul 15 11:26:28 yeah, laurentiu has a patch for that, when it lands in oe-core i'll be sure to prod him. Jul 15 11:26:43 great, thx Jul 15 11:40:04 Hello everybody, Jul 15 11:40:23 I've got a problem building my own kernel with yocto... Jul 15 11:40:56 I always get the following error message: Jul 15 11:41:04 | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed Jul 15 11:41:28 I think this is caused because make is called in the wrong directory, but I'm not sure. Jul 15 11:41:41 does anybody of you have an idea how to fix/check? Jul 15 11:41:50 Would be really great :-) Jul 15 11:45:36 g0hl1n: yeah, where is your kernel source and where did bitbake execute the command? Jul 15 12:07:02 zecke: that's what I'm trying to find out... Are there any variables for it? Jul 15 12:08:43 g0hl1n: the first thing to ensure would be that the value of the S variable is set to match the subdirectory in which the source will be extracted Jul 15 12:09:12 g0hl1n: is the source being fetched from git/some other scm or a tarball? Jul 15 12:10:52 Hi I'm having some strange issues with yocto and the poky distro Jul 15 12:10:55 https://gist.github.com/fenrig/5999482 Jul 15 12:16:44 bluelightning: I've set S and the source is in there. I'm fetching the source from a local git repository using: SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel" Jul 15 12:17:14 g0hl1n: so S = "${WORKDIR}/git" ? Jul 15 12:18:08 bluelightning: correct Jul 15 12:19:32 fenrig: what refers to rpm-postinsts in your configuration? rpm-postinsts is no longer being used (in favour of run-postinsts) Jul 15 12:20:02 bluelightning: I don't know actually Jul 15 12:20:37 fenrig: bitbake -e your-image | less and search for rpm-postinsts Jul 15 12:22:51 bluelightning: okay will do ;) Jul 15 12:27:19 bluelightning: I'm a bit overwhelmed by the output :o what should I do? Jul 15 12:28:06 fenrig: I'd just be interested in references to rpm-postinsts that are not paths Jul 15 12:28:15 fenrig: you can use / to search in the less output Jul 15 12:28:47 bluelightning: I actually replaced '| less' by ' > file ' Jul 15 12:28:59 so i could open it in a text editor Jul 15 12:29:16 fenrig: ah ok, in that case use your favourite text editor's search function :) Jul 15 12:31:35 bluelightning: I found multiple occurences :/ what are we searching for? Jul 15 12:31:58 bluelightning: I understand we need to pinpoint this to a recipe, a bbclass or a include file Jul 15 12:32:20 fenrig: are any of the references not preceded by /etc or ${sysconfdir} ? Jul 15 12:33:49 bluelightning: yes there are occurences without "/etc" or ${sysconfdir} prependded Jul 15 12:34:50 fenrig: ok, can you pastebin those? Jul 15 12:38:11 bluelightning: just parts? because it's not obvious what belongs to what :o Jul 15 12:39:37 bluelightning: https://gist.github.com/fenrig/4929083dc15dce391248 Jul 15 12:39:59 bluelightning: I did not now how much had to be pasted so if you want to know more, just let me know Jul 15 12:40:16 *know Jul 15 12:42:12 fenrig: ok, I just realised rpm-postinsts has been replaced only in master, I guess you are using dylan? Jul 15 12:42:36 bluelightning: yes I am :) Jul 15 12:43:06 since rpm-postinsts has made it into RDEPENDS I'm not sure how it could not have been built by the time the image got to build Jul 15 12:43:38 bluelightning: my vm malfunctioned, can it be cause by that? Jul 15 12:43:49 fenrig: how did it malfunction? Jul 15 12:43:59 bluelightning: well I had to force quit it :o Jul 15 12:44:11 and restart (and thus boot the virtual machineà Jul 15 12:44:17 fenrig: ah... well anything's possible if it corrupted the disk I guess Jul 15 12:44:29 fenrig: you could just bitbake rpm-postinsts Jul 15 12:44:37 bluelightning: okay Jul 15 12:45:22 bluelightning: I don't think that forced a rebuild Jul 15 12:45:41 Attempted 375 tasks of which 375 didn't need to be rerun and all succeeded. Jul 15 12:45:46 fenrig: bitbake -c cleansstate rpm-postinsts ; bitbake rpm-postinsts Jul 15 12:45:46 -.- Jul 15 12:46:05 bluelightning: ah yes, forgot about the clean :o Jul 15 12:47:26 bluelightning: okay retrying to build the image :) Jul 15 12:49:25 bluelightning: that fixed it, very strange error but nonetheless it's fixed, thank you for your excellent help ;)$ Jul 15 12:49:36 fenrig: no worries :) Jul 15 15:42:28 Sorry, real simple question - I've nicked the net-snmp recip Jul 15 15:42:37 y from oe into my system https://github.com/openembedded/meta-oe/tree/master/meta-networking/recipes-protocols/net-snmp Jul 15 15:43:57 But I cant see what links the init.d to S20? Jul 15 15:44:43 pev: https://github.com/openembedded/meta-oe/blob/master/meta-networking/recipes-protocols/net-snmp/net-snmp_5.7.2.bb#L84-L86 Jul 15 15:44:56 pev: these vars are used by the update-rc.d bbclass to do it Jul 15 15:45:22 So "20" is just a dynamically assigned index based of dependency? Jul 15 15:45:27 no Jul 15 15:45:32 not hardcoded like openwrt etc? Jul 15 15:46:27 it passes 'defaults' to update-rc.d. update-rc.d has its own knowledge of the default link configuration Jul 15 15:46:58 ok - so the "20" wasnt specified by our recipe but update-rc.d discerns it? Jul 15 15:47:44 https://github.com/philb/update-rc.d/blob/master/update-rc.d#L180-L181 https://github.com/philb/update-rc.d/blob/master/update-rc.d#L191-L192 Jul 15 15:48:14 update-rc.d.bbclass just arranges to run update-rc.d script at package install / removal to set up / remove the symlinks Jul 15 15:48:26 INITSCRIPT_PARAMS is just hte arguments for the script to set them up Jul 15 15:48:48 Ah...! I handt spotted that - so *everything* is 20 by sefault... doh! :-D Jul 15 15:48:51 update-rc.d is a debian thing, not unlike chkconfig in this context Jul 15 15:48:59 if you want something other than 20, you can change INITSCRIPTS_PARAMS Jul 15 15:49:00 Thanks :-) Jul 15 15:49:02 that's just a default Jul 15 15:49:09 np Jul 15 15:49:22 So... the bottom line I'm trying to figure out is how to *not* create and rcS / rcK link... Jul 15 15:49:30 so the init.d script is created but not started Jul 15 15:49:46 as I need to start one service from another as it's a dependency.... Jul 15 15:49:49 :-D Jul 15 15:50:21 multiple ways you can handle that. INITSCRIPT_PAKCAGES = "" would make it not set up the package postinst/prerm at all for any packages, so update-rc.d wouldnt' be called at all Jul 15 15:50:32 (of course, this is all specific to sysvinit, systemd images will be handled quite differently) Jul 15 15:50:54 Oh, don't start Jul 15 15:51:08 the numbers mean ordering, so you can use the ordering to express dependencies Jul 15 15:51:16 as a later part of the project Ive got to *drastically* improve boot times so probably have to move over to systemd Jul 15 15:51:21 rburton: good point Jul 15 15:51:23 and not used it before :-/ Jul 15 15:51:28 pev: good luck :) Jul 15 15:51:38 Pth! Jul 15 15:51:44 our sysvinit isn't that slow once you turn off the kernel being so noisy Jul 15 15:52:05 The request I was given was < 10s, pref <4s... Jul 15 15:52:07 :-O Jul 15 15:52:18 in that case i'll re-iterate "good luck" Jul 15 15:52:22 from power. Jul 15 15:52:31 yeah, I've said YMMV...! Jul 15 15:52:59 pev: at least demand it's measured from kernel start, so you're not punished by a slow hardware startup/bootloader! Jul 15 15:53:42 pev: its not a lot of work to make a linux on intel system that boots from boot loader to X faster than power to BIOS handover :) Jul 15 15:53:57 * kergoth chuckles Jul 15 15:54:15 kergoth: that's being worked on, thankfully! Jul 15 15:54:36 there are even rumours of bios implementations that start in less than ten minutes these days Jul 15 15:54:46 ooh, aah Jul 15 15:54:56 rburton: Yep, I'm aware of that. Effectively though i'm treating the init.d script for my app as a process monitor and making it responsible for starting / monitoring the app and the other daemons and software processes. So for the snmp daemon it makes sense to start from that rather than relying on rc ordering... of course I could do something similar via runlevels too and keep the same system but I'm not sure taht's exactly simpler... Jul 15 15:55:41 Oh, and the app monitoring script will be moved out from the sysvinit system and made its own inittab entry eventually ... Jul 15 15:56:11 rburton: yes - agreed. And I can optimise uboot quite a lot Jul 15 15:57:04 A guy I used to work with did a great demo booting (IIRC) a PPC board in about 0.5s from power. Was way cool. I think he did put a relatively handy whitepaper out on the web somewhere... Jul 15 16:00:33 pev: related presentations from OE/yocto community members that might be of interest: http://elinux.org/images/2/2b/Elce11_hart.pdf http://elinux.org/images/b/b3/Elce11_koen.pdf Jul 15 16:02:00 bluelightning: Those look smashing, thanks! Jul 15 16:03:08 pev: or videos if you prefer: http://www.youtube.com/watch?v=WHLvI8j31vk http://www.youtube.com/watch?v=aVcfjs02Srs Jul 15 16:19:32 Linus rage again Jul 15 16:19:45 There aren't enough swear-words in the English language, so now I'll Jul 15 16:19:47 have to call you perkeleen vittupää just to express my disgust and Jul 15 16:19:49 frustration with this crap. Jul 15 16:19:51 lol Jul 15 16:19:53 http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg467322.html Jul 15 16:20:02 haha Jul 15 16:20:11 there's plenty, he needs to learn british english Jul 15 16:20:31 FATALITY! Jul 15 16:20:37 hahah Jul 15 16:21:01 rburton: well the only thing I know about British English specific word is "bloody" Jul 15 16:21:44 good word Jul 15 16:24:31 :) Jul 15 16:27:02 The trick with proper english is putting people down in a savage manner without *actually* swearing Jul 15 16:27:06 it's an art-form :-D Jul 15 16:27:24 google translate says linus wasn't very inventive at all Jul 15 16:28:33 rburton: you'd have to ask a Finn whether that translation conveys the full expressiveness of the original epithet :) Jul 15 16:28:52 yeah Jul 15 16:29:04 i thought the rudest word in finnish involved a reindeer, but that might be a myth Jul 15 16:30:41 well, British people are really good at swearing without actually swearing, I guess Jul 15 16:30:41 sense of humor, maybe? Jul 15 16:33:38 poor hpa Jul 15 17:41:18 * kergoth hacks on r/o rootfs bits Jul 15 17:46:52 I'm trying to use the prebuilt poky SDK and I run the script as root and get: SDK could not be set up. Relocate script failed. Jul 15 17:47:13 Rather than try to fix it and discover it's something fundamental - is this a known bug? I'm on Fedora 19 Jul 15 17:47:27 I havn't run in on Fedora 19.. sorry Jul 15 17:47:49 there is a debug flag you can pass to the install script that might shed more light on what is happening Jul 15 18:27:08 fray: hey have you thought of putting rpm generation capability in SDK Jul 15 18:33:34 khem, we've had a request for the same.. Jul 15 18:33:41 my concern is how useful will it be... Jul 15 18:33:51 BTW unrelated.. toolchain issue/question Jul 15 18:34:20 when building for a 64-bit PPC machine, much of the time we have a 64-bit kernel, but 32-bit userspace.. which now results in the compiler barfing it doesn't know what -m64 means.. Jul 15 18:34:41 is there any type of a simple change we can make to the PPC compiler configuration to enable -m64 compilation (in the 32-bit compiler) so it can build the kernel? Jul 15 18:35:01 yes Jul 15 18:35:03 otherwise we're stuck having to have a 64-bit userspace for a 64-bit kernel.. (and then using the 'lib32-image') Jul 15 18:35:36 generally I would recommend that but practically may be not possible Jul 15 18:35:46 you would do a multib option to compiler Jul 15 18:35:49 during build Jul 15 18:36:00 let me dig it real quick Jul 15 18:36:10 does this mean we'd need to have the full multilib bootstrap? Jul 15 18:41:28 fray: I dont think so Jul 15 18:41:34 my gcc tree is hoses Jul 15 18:41:36 hosed Jul 15 18:41:54 hmm seems like unfinished bisect Jul 15 18:48:16 fray: what is the target triplet ? Jul 15 19:00:27 Short question. Is https://wiki.yoctoproject.org/wiki/Poky_Contributions still valid about sending a ssh-key to Richard or Michael to be able to push to poky-contrib? Jul 15 19:01:25 yes Jul 15 19:01:55 Thanks. Jul 15 19:03:27 khem, sorry by ssh connection dropped.. anyway.. powerpc64-....linux-gnu Jul 15 19:07:20 fray: biarch is feature you are looking for Jul 15 19:07:40 fray: and it works ok on 64bit compiler building 32bit kernel Jul 15 19:07:43 is this something to make universal, or should we add it to the BSP? Jul 15 19:07:49 but opposite is not true Jul 15 19:07:54 for SPE targets Jul 15 19:08:12 biarch is there currently valid ofr intel targets only Jul 15 19:08:20 in OE Jul 15 19:08:57 what I see is you want to have 32bit compiler do 64bit kernel Jul 15 19:09:04 that would need gcc plumbing Jul 15 19:09:04 I'm wondering if it's a problem on MIPS64 as well.. but 'n32' is often the same internals as n64.. so it might never have shown itself.. (or the default qemumips64 is just 64-bit only) Jul 15 19:09:22 its not an issue for mips as far as kernel is concerned Jul 15 19:09:28 the existing 32-bit compiler works fine.. the problem is how do we build the kenrel Jul 15 19:09:45 yes we configure gcc with *-*-spe* Jul 15 19:10:00 and gcc says no for biarch for 32bit Jul 15 19:10:05 for that target Jul 15 19:10:15 you could try to change it Jul 15 19:11:05 something like http://paste.ubuntu.com/5878457/ Jul 15 19:11:14 but that may be just the beginning Jul 15 19:13:39 the spe is only e500 though Jul 15 19:14:05 these machines are not e500 machines.. it's classic ppc and e5500/e6500 variants Jul 15 19:14:12 (which are pretty much classic minus fsqrt) Jul 15 19:20:39 ok, in such case we have to drop spe from target triplet for them Jul 15 19:20:53 then extend biarch to ppc and done (hopefully) Jul 15 19:21:08 but e5500+ are also e500v2 compatible Jul 15 19:21:28 so we have to make a call and say you cant do e500v2 multilibs in the new config Jul 15 19:21:47 afaik e5500 is only e500mc compatible, not e500v2 Jul 15 19:22:02 I think people have e500v2 code that they still want to keep running on these newer codres Jul 15 19:22:30 the spe was dropped for the e500mc Jul 15 19:22:35 dropping e500v2 with in 1 single processor rev ? Jul 15 19:22:38 no way Jul 15 19:22:48 optimization wise it may be the same.. but the spe was fleeting.. Jul 15 19:22:52 they did it from e500v1 to e500v2 Jul 15 19:22:59 the spe change and were not compatible Jul 15 19:24:10 from http://www.freescale.com/files/64bit/doc/white_paper/64BTTCHNLGYWP.pdf Jul 15 19:24:23 it seems to me e500v2 is well supported on e5500 Jul 15 19:25:00 e500mc -- classic fp unit, support for SPE, SPESFP, and DPESFP have been removed Jul 15 19:25:12 http://en.wikipedia.org/wiki/PowerPC_e500 Jul 15 19:25:25 get it from horses mouth Jul 15 19:25:56 if freescale's site was faster I could.. :P Jul 15 19:26:22 The e5500 core is also software compatible with the rest of the e500 family, Jul 15 19:26:29 is what it states Jul 15 19:26:30 http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf Jul 15 19:26:33 not in the block diagram Jul 15 19:26:45 reference I found (from freescale) for the e5500 says it's e500mc Jul 15 19:26:59 e500mc is not successor to e500v2 Jul 15 19:27:02 I'm still looking for that RM Jul 15 19:28:45 http://cache.freescale.com/files/64bit/doc/white_paper/64BTTCHNLGYWP.pdf Jul 15 19:28:51 Look at page 3.. it says the FP is classic Jul 15 19:29:10 e5500 core evolves the e500mc core Jul 15 19:29:21 e500 is gone in 5500 true however software still runs Jul 15 19:29:25 e500v1/2 is dead.. no more SPEFP instructions Jul 15 19:29:43 so if there are cases where people want to run e500v2 code ? Jul 15 19:29:54 on these newer chips it still runs Jul 15 19:30:00 not that I know of.. Jul 15 19:30:08 or is that not the case Jul 15 19:30:16 Honestly I can't find anything that says the SPEFP code -will- run there.. only the non SPEFP code Jul 15 19:30:31 there is no SPE/SPEFP unit in the block diagram.. Jul 15 19:31:02 so assuming e500mc+ is incompatible with older SPE cores then we can configure the newer machines to drop spe Jul 15 19:31:07 from triplet Jul 15 19:31:14 everything I've found says it is Jul 15 19:31:19 (incompatible) Jul 15 19:31:27 e500v1 was a dead end and e500v2 was as well Jul 15 19:31:46 unit is not important whats important is if they offer some _software_ emulation or some sort for backward compatiblity Jul 15 19:31:48 Freescale finally learned customers don't want half-assed FP units.. and went back to the classic unit on e500mc and future Jul 15 19:32:04 it would have to be in the kernel, and I'm not aware of any SPE emulation in the kernel Jul 15 19:32:08 yes they probably learned it long way back Jul 15 19:32:34 yes it would have to be in kernel Jul 15 19:32:44 there are still a few new designs on e500v2.. but they are being fewer and fewer Jul 15 19:33:08 thats fine. for e500v2 based cores we can still choose powerpc-*-gnuspe Jul 15 19:33:17 and it wont hurt Jul 15 19:33:35 for e500mc+ we can drop gnuspe Jul 15 19:33:58 that can then facilitate biarch Jul 15 19:34:28 it seems than one needs to port code forward if you are using old spe cores Jul 15 19:34:38 and are excercising SPE Jul 15 19:34:43 which could be rare Jul 15 19:34:58 ya Jul 15 19:38:30 ah ABIEXTENSION is empty for anything thats > e500v2 Jul 15 19:38:35 so thats taken care of Jul 15 19:38:37 thats what I thought Jul 15 19:38:53 so one problem is solved Jul 15 19:39:01 now I think look into biarch feature Jul 15 19:39:15 and submit a patch to enable it for ppc Jul 15 19:39:23 if you need help let me know Jul 15 19:46:21 ok.. I'll look at it in a bit Jul 15 19:53:18 khem, hi there Jul 15 20:46:44 so is there a bugtracker I can file against for the broken SDK installer? Jul 15 20:50:08 I put the -v output up on http://pastebin.com/vV0fayEc Jul 15 21:03:33 It looks like the relocate_sdk.py has a typo and should be < 3 or =< 4 rather than < 4 on the if len(sys.argv) test. Jul 15 21:09:04 How would I find out which version of gcc the yocto project itself uses? Jul 15 21:15:03 Because it has recipes for 4.7 and 4.8. Jul 15 21:19:09 Ummm, I've figured it out. Jul 15 22:19:37 Does it happen at least sometimes that a patch from a future release of gcc gets applied to the current release in order to pick up some desirable functionality, i.e., not a bug fix patch but an enhancement patch? Jul 15 22:36:10 mulhern: sounds reasonable, although i can't point to a specific one... Jul 15 22:38:34 mulhern: khem would be a good person to ask that question Jul 15 23:22:31 Hello - where is udhcpc being called on boot? I need to pass extra options to it. Jul 15 23:25:45 Circuitsoft: what image / target? Jul 15 23:26:12 crownbay Jul 15 23:26:26 The binary is part of busybox Jul 15 23:26:47 that's what I wanted to confirm Jul 15 23:27:33 Browsing the source of busybox, I see a "[[ %udhcpc_opts%]]" Jul 15 23:27:39 Any idea where that would come from? Jul 15 23:29:12 first, it looks like the udhcpc is not getting started automagically, this is mostly because connman is used on some images, but there is an init script (your using sysvinit, I assume) in the /etc/udhcp.d dir Jul 15 23:30:17 nevermind that one, I am confusing setups. Jul 15 23:32:02 udhcp is getting started. Jul 15 23:32:27 However, it is passed the "-n" option so that if it doesn't get a lease, it will quit rather than retrying. Jul 15 23:32:33 In my application, that is /extremely bad/. Jul 15 23:40:26 Found it - it's statically compiled into the ifupdown in busybox. Jul 15 23:40:31 I guess I need to make a new release. Jul 15 23:42:37 there's at least one recipe for the last "original" dhcpcd version Jul 15 23:42:54 works in my pi build... Jul 15 23:49:36 Well, the problem is actually in ifupdown, not udhcpc. Jul 16 00:47:52 mulhern: yes its normal but rare these days since releases are frequent and timely, what features do you have in mind Jul 16 00:48:27 khem: It's security related from a person who contacted me in France. Jul 16 00:48:51 khem: gcc 4.8 currently has two flags: -fstack-protector and -fstack-protector-all Jul 16 00:49:04 They implement the same mechanism. Jul 16 00:49:17 So, after making a busybox_1.20.2.bbappend and files/defconfig with corrected CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS, it's still building with the -n option in ifupdown. Jul 16 00:49:19 mulhern: we have recently added security feature Jul 16 00:49:31 look into that it should cover it Jul 16 00:49:42 khem: Where should I look? Jul 16 00:49:54 at OpenEmbedded core metadata Jul 16 00:52:45 khem: In bugzilla? Or in directory structure? Jul 16 00:53:04 directories Jul 16 00:53:08 e.g. meta/conf/distro/include/security_flags.inc Jul 16 00:53:18 you would include that in your distro Jul 16 00:53:26 and it should start to harden your distro Jul 16 00:54:10 or you can just add it to your local.conf Jul 16 00:54:17 require conf/distro/include/security_flags.inc Jul 16 00:54:34 khem: Is more complicated. There is a third flag now, -fstack-protector-strong, which seems to have gone into gcc 4.9. Jul 16 00:55:14 yes, that needs to be backported first into gcc 4.8 Jul 16 00:56:17 It works like the other two but causes the transformation to be applied more often than -fstack-protector but much less often than -fstack-protector-all. Jul 16 00:57:05 It's been used on chromiumos for a while now and seems well liked. Jul 16 00:57:26 I know this option Jul 16 00:57:33 seems less intrusive to me Jul 16 00:58:17 Reports are slowdown is minimal, whereas -fstack-protector-all it's pretty serious (typically). Jul 16 00:58:46 yes, Jul 16 00:59:04 I would only worry if the gcc testsuite regressions are OK Jul 16 00:59:12 are not ok Jul 16 00:59:44 Right. Jul 16 01:00:40 So, you would be open to it if it wasn't breaking stuff and the appropriate patch could be obtained? Jul 16 01:00:43 If you have plans to propose a backport its ok Jul 16 01:00:55 make sure that both gcc and metadata are fixed Jul 16 01:46:45 OK! **** ENDING LOGGING AT Tue Jul 16 02:59:58 2013