**** BEGIN LOGGING AT Mon Apr 27 02:59:59 2015 Apr 27 06:47:08 can somebody have a look to this output? Apr 27 06:47:09 http://pastebin.com/JD1Mu19V Apr 27 06:47:20 It changes gstreamer versions from 0.10 to 1.0 and back Apr 27 07:01:15 Hello Apr 27 07:16:13 good morning Apr 27 08:11:24 morning all Apr 27 08:46:39 when I want to upload data to my device, I get a "/usr/lib/openssh/sftp-server: not found" Apr 27 08:46:47 so sftp-server is not available on it Apr 27 08:46:53 which package is providing this? Apr 27 08:47:13 wv: openssh-sftp-server Apr 27 08:48:01 thanks Apr 27 08:48:04 recompile :) Apr 27 09:20:41 bluelightning: is it so that it is not really recommended to carry on old kernel versions from earlier Yocto releases to new? Apr 27 09:21:02 I think the userspace generated by Yocto could break using some old kernel version as well as the buildsystem, etc. Apr 27 09:21:29 I am trying to asses whether it is worth for us to update Yocto at this point as I really cannot figure out why the kernel would not boot with Daisy :( Apr 27 09:22:52 I guess updating Yocto means having guys taking care of the kernel for the BSP. Apr 27 09:22:58 and that is not a minor project. Apr 27 09:23:15 and we do not have it currently, sadly, and when things fall apart like this, we cannot do much. Apr 27 09:23:45 we could try integrating a precompiled kernel version, but that could still be problematic with new userspace and of course, that kind of defeats Yocto's goal to generate an image from scratch. Apr 27 09:25:47 lpapp: is this perhaps a compiler issue? I recall in the 4.8.x timeframe there were kernel boot breaking issues requiring patches to the kernel and gcc Apr 27 09:26:26 either compiler or bitbake, yeah Apr 27 09:26:47 but we established that bitbake changes have not been done like this, so my old recipe still ought to work. Apr 27 09:27:02 I'm not following... Apr 27 09:27:06 I pretty much carry my recipe over from the denzil era ... Apr 27 09:27:16 I fixed some issues about it at the migration to dylan. Apr 27 09:27:27 but from dylan to daisy, the recipe does not require any change, right? Apr 27 09:27:36 we are disregarding the kernel recipes coming with Yocto Apr 27 09:27:57 for the reason that we inherited a huge custom patch set that is never going to be upstreamed because they have so many design flaws Apr 27 09:28:05 and so, we just carry the whole stuff ahead. Apr 27 09:28:11 sure, and many others do that as well... not ideal, but common Apr 27 09:28:12 of course, this cannot really be done for a long time. Apr 27 09:28:27 as things will fall apart at some point in userspace, the latest. Apr 27 09:29:08 but as for dylan to daisy, I think it is the toolchain... What else could it be? It is just a guess obviously, but yeah, I do not know how even that could cause it. What changes were you referring to above? Apr 27 09:29:19 was it done in the gcc project, linux kernel and/or Yocto? Apr 27 09:29:25 with gcc 4.8, that is. Apr 27 09:33:02 lpapp: both gcc and the kernel Apr 27 09:33:17 I don't have the details to hand I'm sorry Apr 27 09:33:48 but there was at least one issue that meant that the kernel itself needed a patch, maybe that's the thing you're missing Apr 27 09:33:57 quite possibly Apr 27 09:34:10 how to look for it? Did Yocto integrate that change as a patch in files/ or so? Apr 27 09:34:27 I believe we would have; you might also try looking at other BSPs Apr 27 09:35:04 you would have to pick one with a similarly old kernel though or I'd assume they'd just have automatically got the patch from upstream Apr 27 09:35:14 (maybe you could just look upstream?) Apr 27 09:36:52 are you aware of any public layer with such an old kernel version? Also, I would not know how to look for it in upstream as I do not know where exactly the issue is and so the linux kernel source code is quite huge to check the history for. Apr 27 09:37:02 I could not nail it down myself to a particular code path. Apr 27 09:37:58 I don't know, I don't even know what kernel version you are in fact using Apr 27 09:38:06 as for upstream, surely a keyword search on "gcc" would at least narrow it down... Apr 27 09:40:08 bluelightning: about old kernels version...ehm...can you please flush that old meta-hh stuff? Apr 27 09:42:32 ant_work: sorry been a bit busy, I'll try to get to it this evening Apr 27 09:43:47 np, nobody asked for support for 2.6x yet but we never know :p Apr 27 09:44:15 lpapp, how old kernel, and what platform? Apr 27 09:44:47 AndersD: arm, 3.2 Apr 27 09:45:01 I think it was the newest in denzil Apr 27 09:45:09 when we moved to Yocto Apr 27 09:45:12 but I could be wrong. Apr 27 09:45:42 Ok, last winter I migrated a 2.6.35 kernel to dora... One of the gcc changes that caused us trouble was related to unaligned accesses. Apr 27 09:45:59 as it may give a bit more hint, this is the backtrace with jtag: https://paste.kde.org/pzn4owmmn Apr 27 09:46:08 this is where it gets stuck: #0 0xc0016f40 in davinci_psc_config () Apr 27 09:46:11 In particular, we had to patch both u-boot and the kernel builds for this. Apr 27 09:46:20 this is called during the board initialisation. Apr 27 09:46:28 Ok, if you get that far, it should be that issue at least. Apr 27 09:47:16 AndersD: is this backtrace familiar to you? Apr 27 09:47:31 Unfortunately not... Apr 27 09:47:35 bugger Apr 27 09:47:59 or what the right word is in English :) Apr 27 09:48:04 unfortunate Apr 27 09:48:05 :) Apr 27 09:48:54 AndersD: do you think 3.2 is also affected by that unaligned access issue? Apr 27 09:50:08 No, I think it was fixed earlier, and besides, that should have caused the kernel to get stuck a lot earlier Apr 27 09:50:39 it gets stuck at Uncompressing Linux... done, booting the kernel. in my case. Apr 27 09:56:25 Hm, well, it could be worth a try... Depending on which gcc version were using successfully earlier. I thinkg we migrated from danny -> dora when we incountered this. I.e. in our case gcc went from 4.5.x to >= 4.6. Apr 27 09:56:46 dylan to daise, so it is 4.7 to 4.8 Apr 27 09:56:57 daisy* Apr 27 09:57:45 Then I'm pretty sure that your builds already takes care of. (Our solution was to add KERNEL_CC_append = " -mno-unaligned-access" to the kernel build) Apr 27 09:58:11 But I think the change that required this was introduced in gcc 4.6... Apr 27 09:58:58 hmm, thanks, let met check the build log Apr 27 10:00:50 AndersD: hmm, no, NOTE: make -j 8 uImage CC=arm-foo-linux-gnueabi-gcc -mno-thumb-interwork -marm LD=arm-foo-linux-gnueabi-ld.bfd Apr 27 10:00:54 does not look like it Apr 27 10:01:14 unless that option is implicit with these options. Apr 27 10:01:19 I would not know without reading. Apr 27 10:01:58 grep -rn "no-unaligned-access" ../meta* gives no results Apr 27 10:02:11 so is it implicit then or shall it be explicite? Well, it is worth a try I guess? Apr 27 10:03:32 On more recent kernels it should be fixed. I think it's this commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8428e84d42179c2a00f5f6450866e70d802d1d05 Apr 27 10:04:00 So, I'd guess that you're 3.2 kernel should be fine. Apr 27 10:04:19 Though I haven't double checked it ;) Apr 27 10:04:34 3.2 was released in July, 2012, so possibly, yes. Apr 27 10:05:21 let me check the git history just in case. Apr 27 10:05:53 interesting, git log | grep -rn "Allow kernel unaligned accesses on ARMv6+ processors" returns nothing Apr 27 10:06:25 Hm, it was at least part of the stable 3.2 series. It could of course have been back-ported... Apr 27 10:07:06 yes, we sadly use 3.2.1 Apr 27 10:07:10 Then you could always try to either cherry-pick it, or add the KERNEL_CC line from above and rebuild te kernel. Apr 27 10:07:35 ok, we have this line in the code, #if defined(CONFIG_ALIGNMENT_TRAP) && __LINUX_ARM_ARCH__ < 6 Apr 27 10:07:47 so this is fixed in 3.2.1 Apr 27 10:07:53 maybe with a different commit message, but it is. Apr 27 10:08:24 ok, git blame leads me to the same commit Apr 27 10:08:28 so this is integrated, indeed. Apr 27 10:08:41 would have been surprised if not as that would mean a fundamentally broken workflow. Apr 27 10:08:46 then I am not sure what else. Apr 27 10:09:11 For the moment, me neither Apr 27 10:13:11 AndersD: my idea is to go through the LTS branch Apr 27 10:13:20 and read the commit messages from 3.2.1 up to 3.2.68 Apr 27 10:13:33 looking for "stuck", "hang", "gcc", etc, in the commit message Apr 27 10:13:56 I really do not want to upgrade from 3.2.1. to 3.2.68. Even though they are bugfixes, I do not trust them completely :) Apr 27 10:14:05 but backport a fix from that LTS might be a good idea if there is one. Apr 27 10:14:12 backporting* Apr 27 10:14:21 my other idea is to use a precompiled kernel version for now. Apr 27 10:14:30 yet another idea is do not touch dylan. Apr 27 10:24:59 lpapp: diving in the commits will take long time. Have you tried to apply your patchset to a more recent LTS linux version? Apr 27 10:25:44 not yet, I assume that would be a huge change Apr 27 10:25:55 well, git log has the -S option for searching, doesn't it? Apr 27 10:26:37 if you don't have any idea about the culprit you should properly bisect and yea, that's painful :/ Apr 27 10:27:46 having said that, a quick ought to be easy by just updating the SRCREV in the recipe? Apr 27 10:27:54 quick check* Apr 27 10:32:10 lpapp: you should have the kernel spit more verbose logs (I'm not expert in that realm but the log you posted doesn't help much) Apr 27 10:33:43 ant_work: that is just backtrace, not log. Apr 27 10:34:04 and I could not get early_printk working for one reason or another. Apr 27 11:17:11 ant_work: problem is that if I change SRCREV, it takes ages to fetch the Linux kernel from that revision as that is not sstate-cached? Apr 27 11:28:44 is there anyone who knows where are the source of u-boot ? Apr 27 11:29:04 I'd like to modify the u-boot generated when creating an image with Yocto. Apr 27 11:30:26 lpapp: you should pull the latest git then go backwards Apr 27 11:35:14 ant_work: unfortunately, our patches do not apply against 3.2.68 Apr 27 11:35:52 Shanx_: just fetch it, and use .bbappend with your custom patches if it is a simple case. Apr 27 11:36:37 lpapp: I just want o modify the default boot using a custom command : fatload mmc 2:1 0x12000000 zImage ; fatload mmc 2:1 0x18000000 imx6q-sabresd-ldo.dtb ; setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk3p2 ; bootz 0x12000000 - 0x18000000 Apr 27 11:37:17 But I don't know how to patch it and generate for the board. Apr 27 11:39:20 Shanx_: OK, I am doing that myself, too, so I can probably give some guidance. Apr 27 11:39:29 but not now ... as I am busy with the kernel stuff. Apr 27 11:39:31 I'd like that. :) Apr 27 11:39:52 Can you tell me when you are free to help ? Apr 27 11:41:02 so in your own layer, you create recipes-bsp/u-boot Apr 27 11:41:20 then we create a patch file in there in a directory called files/ Apr 27 11:41:28 and then we use our custom recipe Apr 27 11:41:37 this is not recommended Apr 27 11:41:55 instead, I would suggest to do what we do with busybox Apr 27 11:42:03 we have a .bbappend file Apr 27 11:42:32 you could put this into the .bbappend file: FILESEXTRAPATHS_prepend := "${THISDIR}/${P}:" Apr 27 11:43:02 and then put the patch into a directory next to it, called: u-boot-myversion Apr 27 11:43:11 replace myversion with the version that you are trying to patch Apr 27 11:43:15 What is the name of the .bbappend ? u-boot.bbappend ? Apr 27 11:43:15 and I think this ought to work Apr 27 11:44:03 the same name as in meta/recipces-bsp/u-boot, but you use .bbappend instead of .bb Apr 27 11:45:16 if you want to use a custom version not shipped by your picked-up Yocto release, do what we do. Apr 27 11:48:01 hey, there is some machanism that boosts building time right? so lets say i have different machines, each builds an image. all of them need *-native packages. so there is a server holding these *-native packages.. how does that work? Apr 27 11:49:28 and one other thing: how to disable *-native packages? Apr 27 11:49:33 are you looking for sstate cache? Apr 27 11:51:34 lpapp: yes, thanks.. i think it is SSTATE_MIRRORS Apr 27 11:53:44 yep Apr 27 11:56:07 <_4urele_> hi all Apr 27 11:56:38 <_4urele_> is there a way to get which recipe is used for a package? Apr 27 11:56:52 <_4urele_> u-boot for example Apr 27 12:10:06 _4urele_: the Toaster web UI, or in recent master oe-pkgdata-util Apr 27 12:10:34 <_4urele_> bluelightning thanks Apr 27 12:10:54 well, recent master or 1.8 (fido) Apr 27 12:19:13 hi Apr 27 12:19:17 Hello everybody Apr 27 12:19:50 We are trying to build a family of packages based on the same source, but different defconfig (they are kconfig based) Apr 27 12:20:16 The idea is have multiple packages named bb-.rpm Apr 27 12:21:11 we tried first using BBCLASSEXTENDS and then by having each recipe including a common file Apr 27 12:21:40 boucman: multiple recipes including a common file would be my recommendation Apr 27 12:22:19 bluelightning: we tried that, next, but in both cases bitbake complains that some files in the second package built are already provided by the first Apr 27 12:22:35 RCONFLICTS doesn'ts seem to fix it either... Apr 27 12:23:12 we tried using virtual/bb to see if it helps, but it doesn't seem to Apr 27 12:23:21 boucman: that won't help, no Apr 27 12:23:48 ok, doc is not very clear on what a virtual package is, and how to use it, so we tried :P Apr 27 12:23:52 boucman: you can whitelist to avoid that warning; however if anything links to a binary in one of those packages then you'll probably be in trouble Apr 27 12:24:33 yeah, two versions of these packages should never be installed on the same machine Apr 27 12:24:44 sure, but that's not what I meant Apr 27 12:24:52 the warning is about files going into the sysroot Apr 27 12:24:53 but i'd like to understand exactly where the conflict comes from... Apr 27 12:25:20 I thought each package had a clean sysroot... am I wrong on that assumption ? Apr 27 12:25:30 no, there is a shared sysroot per machine Apr 27 12:25:40 files go into the sysroot so that other recipes can find them when building, and know which packages to depend upon when packaging Apr 27 12:25:50 ah, ok, I understand better what's going on then Apr 27 12:27:05 not sure how to solve my use-case then though... we should be safe since the conflicting libs are only used by the application itself and no external app, but that's not very clean... hmmm Apr 27 12:28:01 ant_work: AndersD: git show v3.2.1..v3.2.68 | grep "4\.8" gives many results :P Apr 27 12:30:24 lpapp, oh, yep. And quite a few of them seems to actually refer to gcc 4.8. You might be able to find something there! Apr 27 12:30:53 8 changes mention gcc out of those, yeah Apr 27 12:33:29 AndersD: might not be related, but it is an interesting commit, https://paste.kde.org/pn5g4lbhg Apr 27 12:37:58 ok, this is most likely unrelated, but it is funny: https://paste.kde.org/pt74t76am Apr 27 12:46:30 can I specify a different compiler file path for building a package from a recipe? Apr 27 12:46:55 I would like to try using a bit older gcc (4.7) for building the kernel with daisy. It is just for testing as of now. Apr 27 12:51:05 ericbutters: btw, you may also wish to look into icecc to speed up the build. Apr 27 13:01:09 lpapp: thanks Apr 27 13:01:28 how to checkout only one file from svn with bitbakeP Apr 27 13:37:21 ericbutters, completely untested, but what happens when you set SRC_URI to point to just that file? Apr 27 13:37:36 It might very well break for all I know Apr 27 14:02:38 bluelightning: I do not understand this paragraph. Can you explain it? http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#bsp-filelayout-binary Apr 27 14:03:24 1) What is the use case? Apr 27 14:03:36 2) How do you refer to those "bootable images"? Apr 27 14:14:13 lpapp: I didn't have any input to that document Apr 27 14:17:06 hmm, whom to ask? It is unclear to me what it is trying to write about. Apr 27 14:19:38 if I understand correctly it might refer to people distributing pre-built binaries (images, bootloaders, etc.) with their BSPs, which used to be something that people talked about doing Apr 27 14:20:23 hmm Apr 27 15:24:37 hi.. using SSTATE_MIRROR will not modify/change the mirror content itself right?! Apr 27 15:25:43 hi.. using SSTATE_MIRROR will not modify/change the mirror content itself right?! Apr 27 15:26:56 right, just read it Apr 27 15:28:08 nice Apr 27 15:56:33 Hi! I'm using the dizzy branch in yocto, but need the python 2.7.9 recipe (currently dizzy only has 2.7.3). What is the best approach to updating it? I'd prefer not to change things in the meta layer. I've tried getting the python recipe from the master branch and putting it in another layer (recipe with the same name), but bitbake still selects the 2.7.3 recipe. Apr 27 15:59:10 explicitly set PREFERRED_VERSION_python = "2.7.9" or up the priority of your layer (BBFILE_PRIORITY) Apr 27 15:59:52 also python-native, obviously — they need to match up for the crosscompilation to work Apr 27 16:01:54 kergoth thanks, I will try that Apr 27 16:12:29 bluelightning: one Yocto's sanity checker goes crazy, I cannot get bitbake back to working Apr 27 16:12:35 never seen this with dylan, only now with daisy. Apr 27 16:15:23 bluelightning: https://paste.kde.org/pluw8d8nz Apr 27 16:18:31 lpapp: sounds like a bitbake version / metadata version mismatch. bb.which was moved to bb.utils.which quite some time ago Apr 27 16:18:36 hmm Apr 27 16:19:31 yes, it looks like it Apr 27 16:20:08 so what is the right fix? Apr 27 16:20:12 lpapp: maybe there is some confusion between multiple versions of bitbake / the metadata? Apr 27 16:20:17 why did it come up all of a sudden? Apr 27 16:20:20 don't know Apr 27 16:20:31 run 'which bitbake', make sure it's the one you think it is? Apr 27 16:20:34 * kergoth shrugs Apr 27 16:20:39 I was overriding meta scripts bitbake and .template... Apr 27 16:20:50 I will run that in an hour Apr 27 16:20:53 I started a fresh clean build Apr 27 16:23:28 sigh Apr 27 16:28:53 always the first reaction after something goes horribly wrong :-) Apr 27 16:29:14 I rather spend one time on the full rebuild than debugging weird stray file and other issues for hours or days Apr 27 16:33:23 there's basically no chance of debugging it now though until the next time it comes up Apr 27 16:34:12 that is fine, I do not have time debugging it. Apr 27 16:34:31 but it comes up quite often to be honest Apr 27 16:34:40 I think we even discussed it at least twice already Apr 27 16:36:13 right, but I don't have any more information now than when you mentioned it before Apr 27 16:36:30 and if you blew away your build dir you have no means of providing it Apr 27 16:36:40 so there's not much I can do here... Apr 27 16:38:17 yeah, unfortunately I am also pushed with deadlines and all that Apr 27 16:38:28 and people cannot guarantee response time in here, so I cannot really wait... Apr 27 16:38:31 you may not reply for hours. Apr 27 16:38:36 and that is fine Apr 27 17:17:37 * darknighte thinks that khem` is doing the IRC hokey-pokey Apr 27 17:18:04 hrmm Apr 27 17:18:26 smart IRC clients Apr 27 17:18:40 they know when I am away and when not Apr 27 17:19:50 * armpit IRC big brother Apr 27 18:44:36 hmm so I think I need to shed the debug info for getting sstate to get bulkier for chromium Apr 27 18:44:51 life is all about compromises Apr 27 18:45:04 10 years ago it was in Mbs now its in Gbs Apr 27 18:45:14 same situation Apr 27 18:45:22 units have changed Apr 27 18:45:43 unstripped chomium binary is 2.1G Apr 27 18:45:45 :) Apr 27 18:46:14 thats where sstate kills it Apr 27 18:46:27 if it was package feeds then only the needed will be penalized Apr 27 18:46:32 but here everyone is Apr 27 19:23:18 Hi, my package ${PN} contain a library (/usr/lib/foo.so), packagesplit creates a ${PN}-dev. This leads to a QA Issue "dev-deps"... How can I avoid that OE splits the package? Apr 27 19:30:01 is /usr/lib/foo.so a symlink? Apr 27 20:16:51 hullo, question I need to create a new package during build which should not be installed Apr 27 20:48:24 JYDawg: so create a recipe and build it. no package gets installed unless it's added to IMAGE_INSTALL in the recipe you're building, or is a dependency of one of those Apr 27 20:48:36 hmm, the bitbake UI keeps exiting on me in the middle of a world build after a task fails even when using -k Apr 27 20:48:47 keep having to pkill the server process after that Apr 27 21:00:52 and it spontaneously exited again Apr 27 21:00:54 sigh Apr 27 21:03:07 hello Apr 27 21:06:38 kergoth: thanks, makes sense Apr 27 21:07:33 s/added to IMAGE_INSTALL in the recipe/added to IMAGE_INSTALL in the image recipe/ Apr 27 21:07:34 np Apr 27 21:10:57 is there a way to detect package upgrades? I've got a "pkg_postinst_${PN}" script that should only run at first boot, not image creation or package upgrades Apr 27 21:12:41 image creation is handled via $D. if that env var is set, then you're running at image creation time, and that's the full path to the rootfs Apr 27 21:12:53 i *think* there's a postinst argument passed in an upgrade case, but not sure offhand what it is Apr 27 21:13:04 I'm thinking a simple token file, but rather use something like rpms upgrade / post scriptlets Apr 27 21:13:14 i'd add echo "$@" to it, and test an upgrade Apr 27 21:13:36 also not sure if that behavior is identical between package managers.. Apr 27 21:13:44 using rpm Apr 27 21:15:27 either test what arguments are passed in what context, or read up on the package managers to see what they do Apr 27 21:15:33 or check the yocto docs to see if it's mentioned there, not sure Apr 27 21:15:39 * kergoth doesn't know offhand Apr 27 21:17:57 was just thinking, can also seperate the bootstrapping targets to a specific package. Apr 27 21:21:54 worx! Apr 27 23:54:38 hello guys Apr 27 23:54:47 I have a package with uses autotools Apr 27 23:55:09 it used to work just fine with dizzy, but now, after switching to fido i get this error: Apr 27 23:55:10 error: cannot find install-sh, Apr 27 23:55:26 configure: error: cannot find install-sh, install.sh, or shtool in Apr 27 23:55:27 try inheriting autotools-brokensep instead of autotools Apr 27 23:55:34 And this is because configure was generated wrongly Apr 27 23:55:38 it's possible that it's a non-automake recipe that can't handle the build and source directories being separate Apr 27 23:55:43 s/recipe/project/ Apr 27 23:55:51 for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do Apr 27 23:56:10 it used to work as it is with duzzy Apr 27 23:56:14 dizzy* Apr 27 23:56:17 in fido, we default to using a separate build/object directory from the source Apr 27 23:56:37 this has changed from previous releases Apr 27 23:57:16 i tried with brokensep and din't see any improvements Apr 27 23:58:11 the problem is the way configure was generated bu autoconf Apr 27 23:58:13 could also be they expect / are compatible with only certain versions of autoconf/automake,s o a version bump of one of those ccould have been problematic Apr 27 23:58:14 by* Apr 27 23:58:21 yes, i know how autoconf works Apr 27 23:59:22 kergoth: that's what i suspect too Apr 28 00:01:14 kergoth: is there any document where i can see the package versions on different yocto releases? Apr 28 00:02:34 yes, the release notes Apr 28 00:03:03 see the updates tab at https://www.yoctoproject.org/downloads/core/fido18 Apr 28 00:03:10 * automake: upgrade to 1.15 Apr 28 00:04:01 kergoth: thanks Apr 28 00:04:06 np Apr 28 00:04:21 kergoth: i managed to hack a fix Apr 28 00:04:28 removing AC_CONFIG_AUX_DIR from .ac Apr 28 00:04:40 does it ring a bell? Apr 28 00:05:55 there's nothing wrong with use of AC_CONFIG_AUX_DIR Apr 28 00:06:00 i've used it myself Apr 28 00:06:01 * kergoth shrugs Apr 28 00:06:33 well - removing that made it compile again Apr 28 00:06:44 so somebody else i think adds this macro too Apr 28 00:07:31 because in configure i end up with two blocks for finding install.sh Apr 28 00:08:42 and this package defines it only once in the .ac file Apr 28 00:08:55 so there must be a conflict in build system Apr 28 00:47:39 the linux-imx linux kernel in yocto for freescale imx6 does not seem to have support to build dm-crypt kernel module ... atleast I do not see it in defconfig for the kernel ...does anybody knows if there is a patch to enable it Apr 28 00:58:27 I have log out now..If anybody knows the answer to "how to enable dm-crypt in imx6 linux kernel" please post it here ..thanks Apr 28 01:27:35 otavio: you're doing crappy job and people are complaining ;-) Apr 28 01:27:40 otavio: see above :b Apr 28 01:28:42 to add the dm-crypt, you need to tweak the kernel config Apr 28 02:30:51 Marex : thank you for the reply. I do realize I need to change config Apr 28 02:31:29 I believe I have to do CONFIG_DM_CRYPTO=y Apr 28 02:31:35 however I do not see that config line Apr 28 02:31:40 do I have to add it Apr 28 02:42:10 imx6: that's possible, yes Apr 28 02:42:41 imx6: it's well possible that those kernel configs are the reduced forms, which do not define all of the config options, but just the differences **** ENDING LOGGING AT Tue Apr 28 02:59:59 2015