**** BEGIN LOGGING AT Fri Jun 26 02:59:58 2015 Jun 26 07:29:08 <[w00t]> Hi, I've been having some trouble with vlan configurations on my yocto machine. I've set up the /etc/network/interfaces configuration with an existing interface, included vlan and net-tools in my build and set up the kernel with 8021q built in. Still getting an error that ifconfig cannot find the device Jun 26 07:29:53 <[w00t]> However, setting up the same vlan using ip or vconfig works Jun 26 07:52:24 Is this what I should be doing if I want source rpms for my image: Jun 26 07:52:26 ARCHIVER_MODE[srpm] = "1" Jun 26 07:52:28 INHERIT += "archiver" Jun 26 07:53:48 that seems to work for some recipes but at least linux-yocto fails: Jun 26 07:53:51 | DEBUG: Executing shell function do_patch Jun 26 07:53:53 | ls: cannot access .meta*: No such file or directory Jun 26 07:53:55 | find: `.meta/cfg/scratch': No such file or directory Jun 26 07:53:57 | ERROR. Could not locate meta series for qemux86 Jun 26 08:04:08 hi.. is there a way to start bitbake and get build information using a webfrontend? Jun 26 08:04:28 ericbutters: your buzzword is: "toaster" Jun 26 08:05:10 thanks Jun 26 08:19:57 finally got a recipe done for my image, however the package's included on that recipe are not packed on the image, but they are still compiled Jun 26 08:20:15 .ipk file can be moved to destination and installed just fine Jun 26 08:21:21 IMAGE_INSTALL += "mypackage" this should work on my image recipe, right? Jun 26 08:32:08 basically yes. Jun 26 08:32:49 i got error from do_package_write_rpm: error: File not found by glob: /build/tmp/work/armv7a-vfpv3-poky-linux-gnueabi/i-hmi/1.0-r0/package/opt/hmi/frontend/p_[f01]@2x.png Jun 26 08:33:05 could this be related to the "[" in the filename? Jun 26 08:35:59 "[" should be escaped at all times Jun 26 08:38:42 ddalex: how to do this? how to tell do_package_write_rpm to escape? Jun 26 11:20:04 anynone here using toaster? Jun 26 11:20:20 ericbutters: just ask the question :) Jun 26 11:22:16 i got error OperationalError at /toastergui/landing unable to open database file (from 127.0.0.1/toastergui/landing page) -- is this because my 'bitbake core-image-minimal' is ongoing? Jun 26 11:24:29 here is the log from that page: http://paste.ubuntu.com/11778078/ Jun 26 11:32:41 okay.. error comes because "no module named MySQLdb" Jun 26 11:36:03 i installed the package, now 'nohub bitbake --observe-only -u toatergui >toaster_ui.log' works and the log shows NOTE: ToasterUI waiting for events Jun 26 11:36:48 calling bitbake core-image-minimal then shows: ERROR: Could not connect to server 127.0.0.1:55003 (503 Service Unavailbale) Jun 26 11:47:02 Hello guys Jun 26 11:47:25 I was wondering I anyone has tried to build fido with linaro as external toolchain ? Jun 26 11:47:57 I suggest to start with the problem :) Jun 26 11:48:38 lpapp: me or ericbutters ? Jun 26 11:50:07 everyone :) Jun 26 11:52:10 lpapp: Haha :) Okay well, I have been trying to build a minimal image for an imx6 based board using the external linaro toolchain. Jun 26 11:52:38 lpapp: The problem is that the image boots sucessfully, but ldconfig is not present ... Jun 26 11:53:47 have you tried checking the build log? Have you tried pinning down where ldconfig would come from? Have you tried to check whether that is packaged, etc? Jun 26 11:56:18 Yes, I am in the process of doing that, but I realised I needed help. Jun 26 11:56:35 lpapp: As far as I understand, the ldconfig is provided by ldconfig-native Jun 26 11:56:50 lpapp: Which is in turn provided by the glibc in general. Jun 26 11:57:28 lpapp: Now, there seems to be two different providers for the glibc, (a) the one embedded with poky, and (b) the one in the meta-linaro layer Jun 26 11:59:06 lpapp: So, my first reaction was to try on set the flag TCLIBC = "external-linaro-toolchain", instead of leaving it undefined, in order to make sure that the one in the meta-linaro layer was used Jun 26 11:59:45 ldconfig-native won't provide a ldconfig for the image Jun 26 11:59:48 the glibc would Jun 26 12:00:00 lpapp: But that led to the error : ERROR: Unable to parse conf/bitbake.conf: ParseError at [...]/fsl-community-bsp/sources/poky/meta/conf/distro/defaultsetup.conf:10: Could not include required file conf/distro/include/tclibc-external-linaro-toolchain.inc Jun 26 12:01:59 rburton: Ah, interesting ! So, what is the role of ldconfig-native ? And is there something wrong with my glibc or the way I defined my glibc ? Jun 26 12:02:19 it is just about host vs. target Jun 26 12:02:26 a binary can be present on both. Jun 26 12:02:46 e.g. gdb, you can debug an application right on the board as well as remotely through the server/client architecture. Jun 26 12:02:57 and remotely, you would not use an arm binary. Jun 26 12:03:03 (given that the board is ARM) Jun 26 12:03:08 ldconfig-native builds just a ldconfig for the host Jun 26 12:03:19 lpapp: Ok, so the native one is the one to be used on the host machine, then. I get it :) Jun 26 12:03:29 Thanks Jun 26 12:03:44 but regardless this, TCLIBC ought to be used anyway as far as I remember. Jun 26 12:04:23 sorry, no, I was confusing that with the toolchain variable. Never mind. Jun 26 12:05:26 not sure if it helps, but in general, you can set the preferred version when different layers provide something that would clash. Jun 26 12:06:00 lpapp: Ok, I will look into that, see if the two provided version differ maybe. Jun 26 12:06:22 but I am not sure how it is handled in this specific case. Jun 26 12:06:34 whether it is modified through .bbappend, etc. You will need to see that. Jun 26 12:07:41 lpapp: As for the TCLIBC variable, I assumed I didn't need to provide it as the external-linaro-toolchain.bb has PROVIDES += "glibc". Was I wrong, do I have to define it in my local.conf also ? Jun 26 12:08:12 I would not know for sure, I am afraid. Jun 26 12:08:16 I am just a Yocto user. Jun 26 12:08:23 trial and experiment :) Jun 26 12:08:29 Indeed :) Jun 26 12:25:32 zeddii, any ideas why __LINUX_ARM_ARCH__ isn't defined with master and 3.0 era kernel? Jun 26 12:45:45 nicolas_: generally TCMODE needs to be set for external toolchains, not TCLIBC, unless the external toolchain isn't a glibc/eglibc-based toolchain, obviously Jun 26 12:52:20 kergoth: It's actually what I've done, I've set TCMODE, and a path to the external toolchain but that is it. Thank you. I'm going to have a try with a more recent version of toolchain. Jun 26 13:17:39 BANG Jun 26 13:30:46 halstead: ping? autobuilder looks unwell :( Jun 26 13:45:18 rubrton: Ok, other question. Let's say I end up with a working armhf image for my imx6 based board. And let's also say that this image has been built using package management, deb packages, and that dpkg and apt are working. Jun 26 13:46:08 rburton: By adding the debian official repos, will I be able to install new software from them, or won't it be possible for some ... differences in compilers used for example ? Jun 26 13:47:04 it's generally not a good idea to use binary packages from one distro in another, even on the desktop :) Jun 26 13:48:34 kergoth: Why :) ? Jun 26 13:51:17 libraries versions are often different, so the binaries won't run. also differences in compiler options and tuning and whatnot, and thats not even going into distributionisms like where config files go, what init is used, how network/etc is configured, etc Jun 26 13:51:38 also differing package names, etc Jun 26 13:51:45 means there's often broken package management dependencies Jun 26 13:54:30 kergoth: Mmm, ok. And are you aware of any way of using an existing base rootfs in yocto ? Jun 26 14:10:06 nicolas_: don't. Jun 26 14:10:47 i guess with an evil layer you could rewrite package names and versioning massively to align with a different distribution Jun 26 14:10:50 but my god the horror Jun 26 14:19:57 rburton: Yeah, I'm not fond of that either. Jun 26 14:20:54 rburton: I turned to yocto a few days ago as it seemed to be the preferred choice for building images for the sabrelite board that would include hardware acceleration features. Jun 26 14:21:49 nicolas_: read the BSP guide. Jun 26 14:22:08 nicolas_: layers.openembededd.org will let you search all the layers that are registered if you want to find more software Jun 26 14:22:11 rburton: And I'm trying to find a way to have both : (a) the flexibility of a debian system, and (b) the hardware acceleration. Jun 26 14:23:11 nicolas_: well, you could rip out the hardware accel bits and put it on a debian box, but then you're dealing with a very unsupported system again Jun 26 14:23:22 lpapp: Yes, in particular meta-fsl-arm and meta-fsl-arm-extra, those are the one that provide the hardware acceleration. Jun 26 14:23:47 ah ok, so you are settled. Jun 26 14:24:11 how/where would I best set a default root password for my image? Jun 26 14:24:37 hellerbarde: I am not sure about the best these days, but I went through this Jun 26 14:24:48 I take that you do not want to set plain password, but the encrypted variant, yeah? Jun 26 14:25:59 lpapp: it wouldn't matter if it lied around in the git repository in plain text, but in the /etc/shadow or /etc/passwd file it should be hashed, yes. Jun 26 14:26:06 hellerbarde: for development purposes there's an image-feature to leave it blank. for production, https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password Jun 26 14:26:06 rburton & lpapp: Do you think I could as well build a linux kernel the regular way, use a existing minimal debian rootfs, and only use the meta-fsl-arm* yocto layers to build the deb packages that would provied what i need in userspace for the hardware acceleration ? Jun 26 14:26:26 nicolas_: you could, yes. it would be very painful. Jun 26 14:26:35 rburton: thanks, I'll read through this now Jun 26 14:26:59 rburton & lpapp: But then again, I would need to make sure that my kernel and the userspace hardware acceleration code do match. Which might - yes, indeed - be painfull. Jun 26 14:27:32 hellerbarde: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5675 Jun 26 14:27:33 Bug 5675: enhancement, Medium, Future, Qi.Chen, NEW , Add a ROOT_PASSWD feature for images Jun 26 14:28:02 git repository, plain text? Hopefully not public for curious eyes. Jun 26 14:28:16 rburton & lpapp: Or what about building kernel and hardware acceleration deb packages with yocto, and doing the rest manually with a debootstrap generated rootfs ? Jun 26 14:29:07 rburton & lpapp: Unless there is something I am missing. Do you see a better idea ? Jun 26 14:29:59 nicolas_: either 1) use yocto or 2) use debian Jun 26 14:30:31 for (2) the recipes show how to integrate the binary drivers, so do the same with your own debian packaging Jun 26 14:30:44 yeah, I would not mix them either :) Jun 26 14:30:45 obviously you're on your own at that point without any hope of support Jun 26 14:30:56 what do you miss from Yocto that is in debian? Jun 26 14:31:03 hello, i bitbaked an image for a zedboard (core-image-sato) which actually is booting, but I'm not sure everything worked fine since x11 and so on doesn't boot..I#ve got the bootlog(line 169) Jun 26 14:31:10 http://pastebin.com/8KJx3GdD Jun 26 14:31:32 I would consider whether it is possible to get Yocto complete your goal. Jun 26 14:31:48 without involving debian; if it is far from it... then yeah, just use debian. Jun 26 14:33:45 lpapp: Basically the amount of packages provided by debian. One thing is rather clear, it will not be necessary to have that feature in our end product, so then yocto might be perfect. But it is "nice to have" right now, as will be using the board for prototyping, trying new things, new software, etc. Jun 26 14:34:12 do not overengineer Jun 26 14:34:20 lpapp: Haha Jun 26 14:35:06 but yeah, if you want to have 30K packages available right away, Yocto might not be your choice. Jun 26 14:35:16 lpapp: I get what you mean, and I was slowly coming to that conclusion. Jun 26 14:36:02 Yocto in turn is far more flexible with what you can get. Jun 26 14:36:10 so question yourself what you really need :) Jun 26 14:37:09 If I override patch but I still want to call base.patch ... how do I make that happen? Jun 26 14:37:56 raykinsella781: replace the original patch through .bbappend Jun 26 14:37:57 lpapp & rburton: Thank you very much guys for your advices :) Jun 26 14:38:01 but I would consider incremental patches. Jun 26 14:38:07 is the name really that worthy? :) Jun 26 14:38:22 raykinsella781: i assume you're talking about the functions, rather than the patch files, cause the latter would be obvious? Jun 26 14:38:27 raykinsella781: if that's the case, then assuming your patch is also python, bb.build.exec_func('base_do_patch', d) Jun 26 14:38:53 if you mean patch files, as lpapp says, don't replace the base one at all, just apply yours next Jun 26 14:39:08 oh, true :) Jun 26 14:39:29 got it thanks! Jun 26 14:44:55 rburton, lpapp: thx for your help! :) Jun 26 14:57:28 Failed to execute /init...is that a problem? or just a warning? Jun 26 15:06:03 Hello, I was wondering what would be the best way to to host my own provides for bitbake so when i build bitbake pulls the same sorces every time Jun 26 15:06:23 sources * Jun 26 15:06:30 there's support for that Jun 26 15:06:40 it's called mirror Jun 26 15:08:21 mweger: I used our local mirror to where I pushed the downloaded files and sstatecache files. Jun 26 15:08:35 this way, our build is much faster. Jun 26 15:08:48 lpapp: interesting Jun 26 15:09:10 I will check this out thank you Jun 26 15:09:19 SOURCE_MIRROR_URL = "http://mydomain/mirror/yocto/daisy/downloads" Jun 26 15:09:49 Crofton|work, hmm. I haven't seen that ARM problem myself. a grep through the tree didn't get me a clear answer. Jun 26 15:09:50 SSTATE_MIRRORS ?= "\ Jun 26 15:10:01 file://.* http://mydomain/yocto/daisy/sstate-cache/PATH" Jun 26 15:10:08 grr Jun 26 15:10:18 I wonder if the issue is somethign in th e.config Jun 26 15:10:28 or B != S? Jun 26 15:14:28 OT, but http://www.brainpickings.org/2015/06/16/neil-gaiman-how-stories-last/ is good stuff Jun 26 15:15:02 mweger: do not miss that above. I forgot to highlight you. :) Jun 26 15:15:56 Crofton|work. I have a 3.0 tree around, let me see if I can build something. I lost 5 hours yesterday debugging a corrupted git tree (the fetcher's ears are burning with my swearing) Jun 26 15:16:18 that would be helpful Jun 26 15:16:41 if I can get some confidence it is a local problem that would be great Jun 26 15:18:34 is a 32 bit qemuarm build representative of the problem ? or something else ? Jun 26 15:35:04 damnit, keep getting parse hangs, wonder if its something in my metadata, bitbake, or just unrelated build VM hiccups Jun 26 15:35:06 * kergoth grumbles Jun 26 15:37:17 guys, could somebody support me with this Errors: http://dpaste.com/0Z43HDX.txt ? Jun 26 15:38:49 turn on ipv6? Jun 26 15:39:00 paulg: but I don't want ipv6 Jun 26 15:39:27 then I guess you get to mine into uclibc and determine why the dependency exists. :) Jun 26 15:39:47 paulg: ok, thanks Jun 26 15:41:24 the glibc REQUIRED_DISTRO_FEATURES is set to the DISTRO_FEATURES_LIBC Jun 26 15:41:31 one more question, what should I append to local.conf for building an image by external toolchain? Jun 26 15:41:36 which includes both ipv4 and ipv6 by default in DISTRO_FEATURES_LIBC_DEFAULT Jun 26 15:42:10 I'm not sure why that isn't conditional upon the ipv6 distro feature, however Jun 26 15:42:12 that seems problematic Jun 26 15:42:47 regardless, DISTRO_FEATURES_LIBC_remove = "ipv6" or DISTRO_FEATURES_LIBC_DEFAULT_remove = "ipv6" should probably do Jun 26 15:48:56 ok, what about toolchain? Jun 26 15:49:06 I don't understand the question. Jun 26 15:49:13 oh, i see Jun 26 15:49:16 read the docs. Jun 26 15:50:13 it depends entirely on which external toolchain you want to use, generally. Jun 26 15:50:41 Sourcery_G++ Jun 26 15:50:52 https://github.com/MentorEmbedded/meta-sourcery Jun 26 15:50:55 as I see I have to download meta-sourcery Jun 26 15:50:57 the readme there explains usage Jun 26 15:50:57 yep Jun 26 15:51:05 thanks Jun 26 15:51:09 np Jun 26 15:58:44 http://dpaste.com/1JKK3EH.txt Jun 26 15:59:01 don't understand why Jun 26 16:09:02 and another issue: ERROR: No recipes available for: /home/int/dev/sandbox/poky/meta-sourcery/core/recipes-kernel/lttng/lttng-ust_2.6.0.bbappend Jun 26 16:10:31 your meta-sourcery and oe-core don't match branches, or meta-sourcery is broken. Jun 26 16:10:52 possibly your meant to be using a poky release instead of master Jun 26 16:13:23 ow do I tell yocto apply the patch with 'git apply' instead of patch Jun 26 16:14:13 how do I tell yocto apply the patch with 'git apply' instead of patch? Jun 26 16:16:26 raykinsella781: PATCHTOOL = "git" Jun 26 16:16:52 great thanks Jun 26 16:17:13 Ox4: that pastebin error is usually due to EXTERNAL_TOOLCHAIN not being set, i need to fix that to fail more pleasantly Jun 26 16:17:28 * kergoth just ran into that yesterday Jun 26 16:18:38 kergoth: I set the EXTERNAL_TOOLCHAIN variable actually Jun 26 16:19:15 what sourcery g++ version? Jun 26 16:20:14 kergoth: http://dpaste.com/0XHYHY4.txt Jun 26 16:20:52 ah, 2010.09-50. pretty old, but afaik should still work.. let me see if i can repro Jun 26 16:21:49 I know, it is very old, but TI recommends this toolchain for one of the their board Jun 26 16:25:14 there it is, downloading Jun 26 16:29:11 omg Jun 26 16:29:26 RP: rburton: is it safe for me to queue a fido-next run on the AB? Jun 26 16:29:56 http://dpaste.com/0VPNEHV.txt Jun 26 16:30:04 libtool fails Jun 26 16:30:11 halstead: safe to queue another build? Jun 26 16:30:30 joshuagl: probably, we're having a few ab issues atm although they do appear to be more metadata now Jun 26 16:30:59 RP: I can try again on Monday? Jun 26 16:31:16 Ox4: check /home/int/dev/sandbox/poky/build/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/libtool-cross/2.4.6-r0/*/config.log Jun 26 16:31:35 kergoth: already checking :) Jun 26 16:32:08 should be an error from the gcc execution. it might be hard to find, the easiest is to go down to the end of the file, then scroll up past the cache variable assignments to the actual tests, and it'll be the last one of those Jun 26 16:32:15 joshuagl: just queue it, worst case it fails and we retry Jun 26 16:32:22 okey dokey Jun 26 16:34:24 kergoth: http://paste.pound-python.org/show/QJ2nDMeEyQCxmoitPD1N/ Jun 26 16:34:41 hmm, my auth is failing on the ab Jun 26 16:35:52 guess I'm not queueing a build tonight :-/ Jun 26 16:36:40 kergoth: I fond Jun 26 16:37:31 http://dpaste.com/2MAJXHE.txt Jun 26 16:38:24 joshuagl: which branch? I can queue Jun 26 16:40:11 joshuagl, I can check your auth. Jun 26 16:40:23 Ox4: heh, my build failed differently with qemuarm, but also due to tuning (which seems to be why yours is failing), due to armv5e being an unknown architecture. you're sure that's the right toolchain for that branch of that bsp? Jun 26 16:41:03 kergoth: yes, I am Jun 26 16:41:24 seems tremendously unlikely, given it seems like the tuning used by your bsp doesn't work with that toolchain version Jun 26 16:41:29 * kergoth shrugs Jun 26 16:41:53 kergoth: the kernel doesn't start if I build it another one toolchain manually :) Jun 26 16:45:32 kergoth: I am afraid this toolchaing is not acceptable by yocto :-( Jun 26 16:46:39 it may be possible to arrange things so your kernel builds with a different toolchain than the rest, by overriding KERNEL_CC and KERNEL_LD — i'm not sure if that'd be supported, however Jun 26 16:47:40 kergoth: https://lists.gnu.org/archive/html/libtool/2010-02/msg00002.html it is known problem as I see Jun 26 16:48:01 no, libtool is irrelevent. Jun 26 16:48:10 what do you mean? Jun 26 16:48:15 your problem is an error coming from gcc, and would fail in any recipe Jun 26 16:48:23 libtool-cross just happened to be the first to try to run ./configure Jun 26 16:48:27 it's early in the dependency graph Jun 26 16:50:09 RP: joshuagl/fido-next thanks sir! Jun 26 16:50:28 actually I am not sure it will work together if I build kernel by one toolchain and rootfs, etc by other toolchain. Jun 26 16:51:30 it almost certainly would. but it'd be a hack either way, so perhaps best to avoid it Jun 26 16:52:10 joshuagl: queued Jun 26 16:52:33 much obliged to you RP! Jun 26 16:52:53 it appears the ab has forgotten I ever existed, halstead is helping to make it reaquainted with me Jun 26 16:54:17 mwhahaha Jun 26 17:05:08 RP: the SDK generated by fido doesn't have /usr/include in the C preprocessor search path (maybe because of 678e8798e (poky)?). SDKs generated by dizzy used to have that dir in the search path. What's the recommended way for application developers (i.e., SDK users) to deal with that change? Jun 26 17:09:00 mario-goulart: it should still be there as long as you specify --sysroot= to the tools Jun 26 17:09:23 mario-goulart: I'm guessing a --sysroot option is going missing somewhere Jun 26 17:12:56 RP: should that missing --sysroot be visible in the environment? I mean, I'm running the environment-setup script from dizzy and fido SDKs, and diff'ing the output of env, but I can't see any difference related to --sysroot. Maybe I'm looking at the wrong place? Jun 26 17:13:37 mario-goulart: presumably the CPP environment variable has a --sysroot? Jun 26 17:13:50 mario-goulart: It is likely getting lost in the build system of whatever you're building Jun 26 17:14:33 * RP -> afk Jun 26 17:14:43 Right, --sysroot= is present in both CPP Jun 26 17:18:20 Anyone know offhand if a linux-yocto kernel will use ${WORKDIR}/defconfig, or if it'll ignore it and do its own thing with the .scc & fragments? Jun 26 17:19:16 I'm assuming it won't Jun 26 17:19:37 but there is mention of ${WORKDIR}/defconfig in linux-yocto.inc, so i was unsure Jun 26 17:23:55 Does anyone know why do we need to use recipe with NATIVE ? What is the difference with the recipe without it ? Jun 26 17:27:28 RP: I've pasted more information here: http://privatepaste.com/c51ab6fcb2 Note that the output of fido's cpp doesn't show /opt/iep//sysroots/ppce500v2-iep-linux/usr/include as dizzy's (the last path before "End of search list"). Jun 26 17:47:49 realBigfoot_: what do you mean? Jun 26 17:48:06 kergoth, i've seen recipes with Jun 26 17:48:14 a native recipe is built for the machine you're building on, rather than the target. they're required to be able to run those tools to build other things Jun 26 17:48:24 if we didn't need them, they wouldn't exist Jun 26 17:48:32 wow I got it Jun 26 17:48:39 makes sense Jun 26 20:10:03 is someone doing systemd 221 upgrade ? Jun 26 20:10:07 let me know Jun 26 20:13:53 * paulg_ wonders if that is the "mandatory kdbus" version. Jun 26 20:16:22 mandatory in that support is always on Jun 26 20:16:28 of course if your kernel doesn't support it, its not used Jun 26 20:19:17 rburton, there was some fuss about a systemd version releaser announcement where they said kernel kdbus was no longer optional ; I don't know much more about it than that. Jun 26 20:19:31 aside from generally not liking ultimatums. Jun 26 20:20:11 rburton, it is mandatory now Jun 26 20:20:16 for userspace Jun 26 20:21:07 but at runtime it can be disabled Jun 26 20:21:18 but compile time its mandatory Jun 26 20:21:38 one needs to specify kdbus=0 to kernel cmdline Jun 26 20:21:44 to disable it at runtime Jun 26 20:22:37 or may be just dont install kdbus.ko Jun 26 20:56:41 WIP recipetool convenience plugin for kernel config bits: https://gist.github.com/kergoth/14ea8d0932f321b60d49#file-kernel-py-L12-L17 Jun 26 20:59:24 paulg, khem`: support in systemd is mandatory, obviously unused if the kernel doesn't support it, or if it does you can disable it at boot Jun 26 20:59:35 paulg: basically, don't panic. Jun 26 20:59:45 paulg: (http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html, second point) Jun 26 21:00:15 as long as we dont start using kdbus as default on OE Jun 26 21:00:29 until a given version is accepted upstream Jun 26 21:00:31 we are ok Jun 26 21:01:16 otherwise we will become gunnea pigs Jun 26 21:01:21 it hasn't been merged yet, has it? Jun 26 21:01:27 (in the kernel, that is) Jun 26 21:58:16 mario-goulart: if you run powerpc-iep-linux-gnuspe-cpp -Wp,-v --sysroot=/opt/iep/15.1/sysroots/ppce500v2-iep-linux-gnuspe I'd bet it will work Jun 26 21:58:42 mario-goulart: as I stated earlier, the sysroot option looks to be missing when you're calling cpp **** ENDING LOGGING AT Sat Jun 27 02:59:58 2015