**** BEGIN LOGGING AT Mon Jan 26 02:59:59 2015 Jan 26 03:50:09 Anyone know if there's a channel dedicated to Intel Edison? Jan 26 08:12:34 anyone know if Yocto's been cross compiled for the ARM6 platform (Raspberry Pi)? it's light overhead would help me on a project I'm in the planning phases of Jan 26 08:14:41 <_qwerty_> Hi all, Are there a configuration parameter to save space on disk removing old bitbake images Jan 26 08:31:28 good morning Jan 26 09:04:38 hi, is there any utility on Linux that i could use to replace mfgtool. its stupid to find a windows pc for flashing image using mfgtool just because my vendor ships with mfgtool. Jan 26 09:07:24 ironically the complete release is yocto based with only flashjing done by mfgtool Jan 26 09:08:08 hitlin37: google: http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-u-boot-mxs-without-fsl-tools.pdf Jan 26 09:08:23 hitlin37, google: https://community.freescale.com/thread/284170 Jan 26 09:08:47 and it looks like mfgtool itself is due to the storage tech of the device Jan 26 09:09:53 Datalink: you mean flashing to nand is fixed with windows usb driver? Jan 26 09:13:23 LetoThe2nd: is that link works for imx5/6? looks good on first look. Jan 26 09:13:28 thanks for the link., Jan 26 09:14:06 hitlin37, while I own a freescale based ARM device (Teensy 3.1) I haven't worked with their processors beyond that, though I do want to get into freescale more Jan 26 09:15:34 its pain to see that flashing requires a PC. Jan 26 09:16:32 hitlin37, possile to get the software to work in WINE? Jan 26 09:16:50 ui have wine..i can give it a try Jan 26 09:17:08 but since it access the device, wine isn't nice when you talk outside. Jan 26 09:17:26 true, forgot about that... blah Jan 26 09:17:36 ReactOS in VirtualBox, maybe? Jan 26 09:18:21 https://www.reactos.org/ Jan 26 09:20:12 haven't heard of reactos before....looks something to try with. Jan 26 09:23:09 but its in alpha stage. Jan 26 09:23:29 i'll use my collegues window system for the time being. Jan 26 09:24:52 it's alpha because it's not stable enough to be a person's daily driver OS yet, but for a one off application use, it could work Jan 26 09:24:59 good morning Jan 26 09:30:53 Datalink: now you persuaded me, i'm play with it during evening time. thanks! Jan 26 09:32:59 hitlin37, heh, it's cool, but again, not a daily driver, so I haven't played with it a lot either, I think I still have a VirtualBox image somewhere on one of my systems... Jan 26 09:33:13 I think the TB drive I don't even have plugged in is the one... Jan 26 09:41:35 morning all Jan 26 09:42:14 morning bluelightning Jan 26 09:42:21 hi Datalink Jan 26 10:08:20 good morning Jan 26 10:10:11 how can I specify from which recipe to pick up packages for an image? Currently, I have two recipes with different build targets for make and an .inc file shared some common package parts. Jan 26 10:16:35 instead of preferred_version, is there something like preferred_recipe? Jan 26 10:19:30 lpapp: I guess PREFERRED_PROVIDER is what you want Jan 26 10:19:55 but that is at the configuration level, there is no way to do it on a per-image basis Jan 26 10:21:27 bluelightning: really Jan 26 10:22:25 bluelightning: http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#var-PREFERRED_PROVIDER do I always need to write virtual/ or that is not a requirement? Jan 26 10:25:44 lpapp: if the recipes produce the same named packages, then there isn't a way to select between them in the image, no Jan 26 10:26:31 lpapp: no, virtual/ is just a convention for naming build-time PROVIDES where more than one provider exists and a selection is expected to be made Jan 26 10:26:57 bluelightning: ok, maybe the example could mention that, or give a non-virtual example. Jan 26 10:27:15 lpapp: probably ought to yes, it's a common confusion point Jan 26 10:38:26 mago_: hi - can you help me at all with https://bugzilla.yoctoproject.org/show_bug.cgi?id=7024 ? Jan 26 10:38:28 Bug 7024: minor, Medium, 1.8, paul.eggleton, NEEDINFO , Need dependencies from tasks on postprocessing variables Jan 26 10:39:14 bluelightning: sorry, yes, i will try to reproduce it today. i've been travelling most of last week, so haven't had time to do any hacking Jan 26 10:39:43 mago_: ok, no worries - thanks Jan 26 10:48:18 bluelightning: ok, thanks. Jan 26 10:59:22 bluelightning: after putting PREFERRED_PROVIDER into my distro conf, bitbake myimage is not enough? I am still getting the conflict messages for the files in question. Jan 26 11:01:58 lpapp: PREFERRED_PROVIDER won't actually stop both being built if there are dependencies such that the system thinks that needs to be done, although you should get a warning if the stated PROVIDES are valid and both recipes actually have that in PROVIDES Jan 26 11:04:53 bluelightning: there are common.inc, A.bb and B.bb. When I prefer the B.bb provider, I thought A.bb would be completely ignored. Jan 26 11:05:03 A.bb and B.bb only differ with regards to the make target. Jan 26 11:06:11 lpapp: does the common inc file set up a common PROVIDES that you are setting PREFERRED_PROVIDER on? Jan 26 11:07:34 grep -rn PROVIDES ../meta-foo/recipes-foo/foo/common.inc -> empty output. Jan 26 11:11:04 just checking, your A and B have different PN values (derived from their file names) right? Jan 26 11:12:11 bluelightning: that is possible. Jan 26 11:12:54 are there any other recipes that have a build-time dependency on either of these recipes? or is it solely brought into the build based upon one of the packages produced going into IMAGE_INSTALL? Jan 26 11:15:50 bluelightning: these are "topmost" packages, with no dependencies on top of. Jan 26 11:16:08 bluelightning: the packages from common.inc are in our specific packagegroup that is put into the image, yes. Jan 26 11:19:06 hmm, well you'll have to see whether this is going to work or not, I'm not sure to be honest Jan 26 11:19:15 what is? Jan 26 11:19:29 PREFERRED_PROVIDER to resolve this particular issue Jan 26 11:19:48 I wiped my build folder out. Jan 26 11:19:52 in any event, if you want to use PREFERRED_PROVIDER you will need to have a common PROVIDES to select a provider for Jan 26 11:19:55 let us see if it works with clean build... Jan 26 11:20:08 there probably wasn't a need for that Jan 26 11:22:10 maybe, but I feel safer. Jan 26 11:29:01 bluelightning: I am not sure why I need to write PROVIDES explicitly. Does bitbake not know already what recipes provide what packages? Jan 26 11:30:06 lpapp: it does, but those are runtime provides and at present the build system does not support selecting between those Jan 26 11:30:45 lpapp: it just struck me, surely the best way to handle this would be to ensure the package names are different and just be explicit in IMAGE_INSTALL Jan 26 11:32:18 hmm? Bitbake is build time thing, not runtime. Jan 26 11:33:14 does it not have a mapping like a recipe provides a1, a2, and a3, whereas b recipe provides a1, a2, and a3. Then the preferred provider would tell bitbake which key to look up? Jan 26 11:35:52 I'm not sure if the code is written like that Jan 26 11:37:12 bluelightning: I am thinking about removing A.bb and merge common.inc with B.bb Jan 26 11:38:53 bluelightning: earlier i mentioned that i was getting the following error for zlib package: ERROR: The recipe zlib is trying to install files into a shared area when those files already exist. Jan 26 11:39:14 bluelightning: this is no dizzy-12.0.1 Jan 26 11:40:45 darkhorse: can you please pastebin the full error? Jan 26 11:41:20 bluelightning: in the zlib recipe, under meta/recipes-core/zlib, there is a function do_install_append_class-target() with the following comment: do_install_append_class-target() : We move zlib shared libraries for target builds to avoid qa warnings. Jan 26 11:41:46 bluelightning: when i comment out the function, it works fine. Jan 26 11:43:33 bluelightning: i can pastebin if you tell me where/how :) Jan 26 11:44:05 darkhorse: paste the error into http://pastebin.com/ and then copy & paste the URL here Jan 26 11:47:53 bluelightning: wow that's cool! here's the link: http://pastebin.com/rTZyf0ia Jan 26 11:48:49 bluelightning: the same problem occurs with ncurses Jan 26 11:49:12 darkhorse: there's something messed up here with external-sourcery-toolchain; it's not the zlib/ncurses recipe at fault here Jan 26 11:49:39 darkhorse: are you using the dizzy branch of meta-sourcery to match up with the build system version? Jan 26 11:51:58 bluelightning: to be honest, i didn't find any references to specific branches of yocto when i downloaded meta-sourcery. i tried the master branch which didn't work. then i picked up the last release branch which was 2014.12-async1.zip. Jan 26 11:52:14 bluelightning: and that's what i am using Jan 26 11:53:29 darkhorse: ok, well you'll need to talk to kergoth I suspect regarding this issue Jan 26 11:53:41 silly simple question, how concerned do I have to be about power cycling a Yocto based device? Jan 26 11:54:14 Datalink: its a linux system, so same as any other. ideally shut down cleanly so you don't have the deal with filesystem corruption… Jan 26 11:54:28 Datalink: it's not so much about the OS, but what storage devices your device uses and how you are writing to them Jan 26 11:55:06 kergoth: which branch of meta-sourcery should I be using with dizzy-12.0.1 Jan 26 11:56:15 rburton, bluelightning it's an Intel Edison, so eMMC, lemme check the filesystem types Jan 26 11:59:36 ext4, for mail filesystem Jan 26 11:59:41 er, filesystems Jan 26 12:00:00 its journaling so generally recovers fine Jan 26 12:01:07 hopefully, yeah, but yeah, I agree with you that shutdown is a good idea when viable Jan 26 12:01:37 I need to get a battery for this thing, very cool little computer Jan 26 12:16:46 kergoth: i have tried master branch again. I wasn't setting TCMODE as you previously hinted. the only assignment happening to TCMODE is a weak assignment happening in meta/conf/distro/defaultsetup.conf which is TCMODE ?= "default" Jan 26 12:19:26 kergoth: so like I mentioned earlier it blows up with "variable libc_baselibs references itself!! error. please find full detail here: http://pastebin.com/8Ki23znh Jan 26 12:57:52 bluelightning: it turns out that there is no official release of meta-sourcery for dizzy yet :( there is fairly recent branch that seems to work but I am intrigued by your comment that the error is is with toolchain setting. if that was the case, why all other packages seem to okay? Jan 26 13:09:09 darkhorse: don't know, but this error does not occur in a build without meta-sourcery, and you'll note the mention of external-toolchain-sourcery in the error Jan 26 13:19:27 bluelightning: reading through dev manual for runtime image testing I find the following statement: Jan 26 13:19:32 bluelightning: When running tests (independent of whether the image has been deployed automatically or not), the device is expected to be connected to a network on a pre-determined IP address Jan 26 13:20:03 bluelightning: question is, can I use a serial connection instead. it does seem to suggest serial connection for bootloader interactions Jan 26 13:20:42 darkhorse: at the moment we expect to be able to make a connection over SSH Jan 26 13:21:12 we do support serial connection for the bootloader yes Jan 26 13:21:20 in theory it would be possible to do it all over serial, but that's not implemented Jan 26 14:28:07 complex question, running yocto install, the root filesystem's full, I've added an entry to /etc/systemd/journald.conf to limit the SystemMaxFileSize to 200K, is there a way to flush the oversized journal? a reboot didn't do it Jan 26 14:30:25 may have been a typo, rebooting to find out Jan 26 15:15:14 .... Jan 26 15:15:27 is there some reason my root password isn't working for single user mode? Jan 26 15:19:28 Just tried "bitbake -c menuconfig" && "bitbake -c -f deploy linux-yocto"; however bitbake doesn't seem to build the modules I selected although it's clearly set as module in .config - any clue? Jan 26 15:24:26 mavin1, wouldnt you need to do a do_compile_kernelmodules ? Jan 26 15:26:44 mavin1, ideally you would save and use the new kernel defconfig in the recipe, which would trigger all required rebuilds automatically Jan 26 15:36:12 let me try - I might have missed it Jan 26 15:38:56 @kroon - do_compile_kernelmodules doesn't change anything :-( Jan 26 15:40:59 mavin1, aha, maybe something else is missing then Jan 26 16:11:41 can't seem to get to http://adtrepo.yoctoproject.org anyone know about it's status? Jan 26 16:17:03 adyer: I think it's probably related to the autobuilder being down for maintenance at the moment, should be back up by EOD tomorrow US time I think was the last ETA I heard Jan 26 16:19:38 bluelightning: thanks. do you know of a mirror somewhere? Jan 26 16:24:20 adyer: I don't know of one I'm afraid, but then it's not something I personally use Jan 26 16:26:50 bluelightning: thx again. Jan 26 16:41:35 btw, Datalink which vendor actually gives good supprt with yocto. any idea? atleast any know next time if such a vendor exists which gives linux tools for flashing Jan 26 16:43:07 hitlin37, I only have 1 device with Yocto on it, so I'm not the best to ask on that one, I'm afraid Jan 26 16:44:32 :) Jan 26 16:44:34 np Jan 26 17:02:48 bluelightning: after i build one of my kernels, i get a mysterious stripping error which starts like this: ERROR: runstrip: ... Jan 26 17:03:28 bluelightning: it doesn't say which task failed etc. but it looks like it fails while trying to strip some file as part of kernel packaging Jan 26 17:03:32 does it continue with more of an error ? Jan 26 17:22:31 bluelightning: no that all. and surprisingly when i run the same command again, it thinks everything is fine and succeeds! Jan 26 17:23:19 darkhorse: I really don't know I'm afraid Jan 26 17:23:49 I can only suggest trying a -c cleansstate and seeing if you can reproduce the error, and then filing a bug Jan 26 17:27:32 bluelightning: yeah, i have done that. it does show up first time after a clean build. next time, building from the cache, its okay Jan 26 17:28:44 ok, can you please report this? we shouldn't have incomprehensible errors and especially ones that don't stop the build Jan 26 17:33:46 I found an interesting bug in the Intel Edison... yocto was configured to have journald run persistant rather than volitile, /var is also mounted on / Jan 26 17:35:25 bluelightning: will do - thanks Jan 26 17:43:46 adyer: for a list of YP compliant vendors: https://www.yoctoproject.org/ecosystem/compliance-program-registrar Jan 26 20:48:45 With this kernel-dev rework Jan 26 20:48:57 I am seeing that generated headers are missing Jan 26 20:49:31 like packages-split/kernel-dev/usr/src/kernel/include/generated/autoconf.h Jan 26 20:49:40 where would it be in new scheme of things Jan 26 20:50:01 * khem pokes at zeddii Jan 26 20:54:58 khem. it's there in my builds. what exactly are you building ? Jan 26 20:55:16 it is in work-shared with the rest of the generated files Jan 26 20:55:42 in my case its not Jan 26 20:55:50 so prolly something in kernel recipe Jan 26 20:55:57 this is custom kernel Jan 26 20:56:01 3.3 Jan 26 20:56:24 work-shared/$MACHINE/kernel-build-artifacts/ which is the STAGING_KERNEL_BUILDDIR Jan 26 20:56:49 if you invoke do_shared_workdir do you see them ? Jan 26 20:56:59 could just be a missing dependency on that function ? Jan 26 21:06:37 zeddii: who creates the dep on do_shared_workdir Jan 26 21:09:00 I see two dirs kernel-build-artifacts/ kernel-source/ Jan 26 21:09:17 sec. it's in the commit. let me get the right hash. Jan 26 21:09:27 I don't want to steer you wrong from memory Jan 26 21:09:33 ok Jan 26 21:10:15 oe-core hash: 6a1ff0e7ea Jan 26 21:10:16 do_configure[depends] += "virtual/kernel:do_shared_workdir" Jan 26 21:11:21 OK all those changes my recipe should get Jan 26 21:11:30 since I am inheriting kernel Jan 26 21:11:53 ah Jan 26 21:11:54 -do_configure[depends] += "virtual/kernel:do_install" Jan 26 21:11:54 +do_configure[depends] += "virtual/kernel:do_shared_workdir" Jan 26 21:11:54 yup. Jan 26 21:12:01 let me see Jan 26 21:17:24 hmmm this external module is inheriting module Jan 26 21:17:30 so seems simple Jan 26 21:19:04 oh now we need to use STAGING_KERNEL_BUILDDIR Jan 26 21:19:28 instead of STAGING_KERNEL_DIR Jan 26 21:19:34 API change Jan 26 21:20:00 export LINUX = "${STAGING_KERNEL_DIR}" Jan 26 21:20:05 halstead: ping Jan 26 21:20:10 needs to be export LINUX = "${STAGING_KERNEL_BUILDDIR}" Jan 26 21:21:41 yah. RP had to fix some other instances as well. There's a reason why we wanted it called 'build-artifacts' since the source is one place, the build another, and the external build artifacts are in a third (the builddir) Jan 26 21:21:58 * zeddii has to bolt soon-ish, I've been fighting with systemd all day :( Jan 26 21:29:42 zeddii: its more than that so build-artifacts contains scripts and bins needed to build kernel pieces and modules Jan 26 21:29:45 right ? Jan 26 21:29:49 what is in kernel-source Jan 26 21:29:58 is that the prepared source tree ? Jan 26 21:30:22 then the generated headers should be inside prepared sources Jan 26 21:30:30 not inside build artifacts Jan 26 21:30:54 nope. Jan 26 21:31:06 kernel-source is the patched tree. and then the split build happens. Jan 26 21:31:34 so the generated header files are in ${WORKDIR} like they always have been. if they go into the kernel-source, it is dirty and no other builds can happen. Jan 26 21:32:01 then to support external builds, we grab the minimum out of the build dir and get it into the kernel-build-artifacts dir, right beside kernel-source Jan 26 21:32:36 there was a failed attempt before the end of december that left the tree dirty and broke a lot of workflows horribly. Jan 26 21:32:49 yeah just saw the symlink Jan 26 21:32:55 was typing out loud Jan 26 21:33:02 np Jan 26 21:33:35 so kmods which were looking at STAGING_KERNEL_DIR should now look into STAGING_KERNEL_BUILDDIR Jan 26 21:33:51 I think it would have been better of the API was kept as such Jan 26 21:33:58 yes. that's what we build lttng-modules against. Jan 26 21:34:19 meaning STAGING_KERNEL_DIR would point to kernel-build-artifacts Jan 26 21:34:24 and not kernel-source Jan 26 21:34:28 which is the case now Jan 26 21:35:00 we had a few variants of the variables when the patches were in progress. they all had different issues. Jan 26 21:35:20 there were different users of the variables that broke in different wonderful ways. Jan 26 21:36:26 I am just another one Jan 26 21:38:06 * zeddii heads afk for a bit. will be back later. Jan 26 21:38:17 khem: dont external modules need to point to both directories, not just one? in which case it doesn't matter which one STAGING_KERNEL_DIR points to, you'd need to alter it to know about the other anyway Jan 26 21:38:24 clearly they need sources and generated bits Jan 26 21:46:05 halstead: ping Jan 26 21:50:25 bluelightning: i know you mentioned that current image tests expect ssh connection Jan 26 21:51:16 bluelightning: but clearly support for serial connection is there. so it should be possible to modify or write new tests that work with over serial Jan 26 21:56:01 How do I write a bbappend file for linux-yocto_3.14 if I want to build for three different machine types being genericX86, genericX86_64 and arm? I have a defconfig for each architecture, which gets ignored. Instead it creates .config from running make menuconfig Jan 26 22:03:01 This is what it looks like right now. http://pastebin.com/kFmmmC0H Jan 26 22:03:57 darkhorse: the command running is reasonably abstracted, in theory it should be possible Jan 26 22:05:13 hrrm. Trying to get coreutils (target) to depend on coreutils-native is harder than I would have guessed... Jan 26 22:05:18 DEPENDS_class-target = "coreutils-native" Jan 26 22:05:30 ...fails, since it doesn't guarantee the sysroot is populated. Jan 26 22:05:48 do_compile[depends] += "coreutils-native:do_populate_sysroot" Jan 26 22:06:07 ...fails since the native pkg build rightfully complains about the circular dependency. Jan 26 22:06:23 do_compile_class-target[depends] += "coreutils-native:do_populate_sysroot" Jan 26 22:06:42 ...fails silently to enforce the dependency even though it parses ok. Jan 26 22:09:12 bluelightning: as I only today started looking at the code, my concern is that there might be more code in the bb module apart from the testimage class and other stuff under meta/lib/oeqa... Jan 26 22:10:37 bluelightning: in other words, my naive understanding is that things start with testimage class and build from there with code in oeqa directory Jan 26 22:20:17 darkhorse: I think that is pretty much all of the code that relates to that Jan 26 22:21:30 paulg: DEPENDS translates to do_configure depending on do_populate_sysroot of the named items, so if that does not work, there is something else going wrong Jan 26 23:51:45 bluelightning: one more thing - with dizzy if I specify KERNEL_IMAGETYPE = "uImage" then do_bundle_initramfs task fails. this was working with dylan. I have to specify uImage.gz instead but then it compress the kernel image which i don't want Jan 26 23:52:17 fails how? Jan 26 23:53:53 bluelightning: cannot stat arch/mips/boot/uImage .... Jan 26 23:54:21 bluelightning: basically it tries to mv file in the above location but it doesn't exist there Jan 26 23:54:52 sounds like a bug to me... is the file perhaps in a different location? Jan 26 23:56:26 bluelightning: i think the problem occurs in the last three lines of kernel.bbclass:do_compile() as follows: Jan 26 23:56:30 if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}" fi Jan 26 23:56:41 bluelightning: if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}" fi Jan 26 23:59:12 bluelightning: it copies the image to KERNEL_OUTPUT (arch/boot/ ) only if compressed (.gz) image is specified. otherwise it doesn't. I think it should copy uncompressed if KERNEL_IMAGETYP is uImage instead of uImage.gz which is what the test is trying to do Jan 27 00:00:55 bluelightning: that is why for KERNEL_IMAGETYPE = "uImage" the later run do_bundle_initramfs finds the image under arch//boot (that is where it looks) Jan 27 00:01:31 bluelightning: sorry i meant KERNEL_IMAGETYPE = "uImage.gz" in the last message Jan 27 00:02:48 bluelightning: so when do_bundle_initramfs() runs it looks for arch//boot/${KERNEL_IMAGETYPE} which is available for "uImage.gz" but not for "uImage" Jan 27 00:50:41 bluelightning: i guess i didn't make much sense. did I? Jan 27 00:51:23 darkhorse: I think it does make sense, I'm just not that familiar with uimage as a format Jan 27 00:52:05 darkhorse: I'd suggest filing a bug for this and then we'll sort it out (or, if you can figure out what needs changing, send a patch) Jan 27 00:53:04 bluelightning: i will be creating a local fix tomorrow. and send over the patch. thanks Jan 27 00:53:13 cool, thanks Jan 27 00:53:24 time for sleep... goodnight Jan 27 00:53:49 bluelightning: same here - sleep tight :) Jan 27 01:49:16 zeddii: linux/types.h is not exported into STAGING_KERNEL_BUILDDIR Jan 27 01:49:36 how do we decide what to export into the BUILDDIR Jan 27 01:50:08 some kmods reference to this header raw Jan 27 01:50:17 so we can not use one from standard includes Jan 27 01:50:52 so then are we supposed to pass -I flags into both sources **** ENDING LOGGING AT Tue Jan 27 02:59:58 2015