**** BEGIN LOGGING AT Mon Feb 06 03:00:01 2017 Feb 06 05:27:21 whee. arm build just died with this... Feb 06 05:27:24 ------------------- Feb 06 05:27:28 | checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. Feb 06 05:27:28 | WARNING: exit code 1 from a shell command. Feb 06 05:27:28 | ERROR: Function failed: do_configure (log file is located at /home/paul/poky/build-arm/tmp/work/cortexa8hf-neon-overc-linux-gnueabi/gcc-runtime/6.3.0-r0/temp/log.do_configure.27625) Feb 06 05:27:28 ERROR: Task (/home/paul/poky/meta/recipes-devtools/gcc/gcc-runtime_6.3.bb:do_configure) failed with exit code '1' Feb 06 05:27:32 ------------------- Feb 06 05:27:59 just updated ; everything on master. Will try cleansstate since this is a re-used build dir. Feb 06 05:30:00 nope, still fails. FWIW, I just completed an arm64 build right before this w/o issue. Feb 06 06:23:07 bluelightning: ping Feb 06 06:35:25 Hello, I sucessfully built a qemu image. How I convert the "qemu.bin" and "rootfs.ext4" to a single .vmdk file ? Thanks! Feb 06 06:46:36 jakek_: why not directly try to create a full image for some virtualization? Feb 06 06:48:47 jakek_: FWIW, vmdk, vdi and qcow2 should be directly available as image types. Feb 06 07:17:16 LetoThe2nd: thanks a lot mate ! I missed the thing. I just modify local.conf IMAGE_FSTYPES += "vmdk" Feb 06 07:17:34 jakek_: :-) Feb 06 08:22:25 Hi, I'm adding new layer for x86_64 machine and I build core-image-minimal. I burn iso file to usb key and canb see grub options. I can see kernel is booted and init script from initrd is started but I see only : Waiting for removable media and thats it (I have CONFIG_DEVTMPFS=y and also CONFIG_DEVTMPFS_MOUNT=y). Any ideas what to check and why it's not proceeding. I looked to initscrip and it looks for /run/media (maybe run folder doesn't ex Feb 06 08:22:26 ists?) Using jethro release Feb 06 09:10:07 good morning Feb 06 09:18:20 Hello everyone Feb 06 09:19:46 I am really busy right now working on a project with quite a lot of pressure. I would like to contribute a small thing to the Yocto Documentation, but right now I don't have the time needed to do the contrubution Feb 06 09:19:57 so I thought that maybe I could release the idea over here Feb 06 09:20:25 and someone here could do it for me and for the community, if you think that it is good enought to be incorporated to the documentation Feb 06 09:21:57 I have found that in cases where you inherit from systemd, you cannot really use the pkg_postinst_${PN} function in your recipes if you want to run code on first boot Feb 06 09:22:14 that's because the postinst actions of systemd return 0 Feb 06 09:22:30 an easy fix is to change the documentation of the mega-manual Feb 06 09:22:37 where you say this: Feb 06 09:22:45 pkg_postinst_PACKAGENAME() { if [ x"$D" = "x" ]; then # Actions to carry out on the device go here else exit 1 fi } Feb 06 09:22:56 you could say this: Feb 06 09:23:08 pkg_postinst_PACKAGENAME() { if [ x"$D" = "x" ]; then # Actions to carry out on the device go here else trap "exit 1" EXIT fi } Feb 06 09:23:23 by using Feb 06 09:23:28 trap "exit 1" EXIT Feb 06 09:23:35 instead of using Feb 06 09:23:37 exit 1 Feb 06 09:23:48 you ensure that the code needed to run on first boot will get run Feb 06 09:39:47 maxin: what's your opinion about the inconsistent /etc files when removing users (https://bugzilla.yoctoproject.org/show_bug.cgi?id=11007#c13)? Feb 06 09:39:48 Bug 11007: normal, Medium+, 2.3 M3, patrick.ohly, ACCEPTED , build fails after user add/delete commands Feb 06 09:40:09 Should we simply remove the *- backup files at rootfs construction time? Feb 06 09:42:46 pohly: those files are added by the shadow package (as a dependency in the extrausers class) and required by the shadow tools Feb 06 09:43:35 What breaks if they are missing, i.e. what exactly is their purpose? Feb 06 09:43:36 pohly: haven't found the reason for the inconsistencies in the files yet Feb 06 09:45:46 When you said "those files are added by the shadow package", do you mean "packaged" or "created at runtime"? Feb 06 09:46:11 Probably the latter. Feb 06 09:46:19 To me they look like redundant backup files. Feb 06 09:47:37 "man shadow" (on Debian) confirms that /etc/shadow- is "Backup file for /etc/shadow." and adds "Note that this file is used by the tools of the shadow toolsuite, but not by all user and password management tools." Feb 06 09:48:44 pohly: passwd man page says - used by the tools of the shadow toolsuite, but not by all user and password management tools. Feb 06 09:49:22 pohly: it makes sense to not to ship some backup files.. Feb 06 09:50:11 pohly: oh, I missed your previous comment Feb 06 09:51:47 maxin: okay, so we agree about https://bugzilla.yoctoproject.org/show_bug.cgi?id=11007 - it would still be useful to know why the backup files became inconsistent, but we can treat that as a separate bug. Feb 06 09:51:48 Bug 11007: normal, Medium+, 2.3 M3, patrick.ohly, ACCEPTED , build fails after user add/delete commands Feb 06 09:55:53 pohly: that looks fine to me. Feb 06 10:05:44 Hi! How to skip step in do_package_qa with INSANE_SKIP_${PN} for error type "QA issue: Endiannes did not match .. " ? Feb 06 10:14:21 what is the proper way to clean a recipe, e.g. when switching repository cloning from git:// to gitsm:// ? Feb 06 10:23:05 CoLa|work: bitbake recipe:do_cleanall / bitbake -c cleanall recipe Feb 06 10:34:31 thanks Feb 06 10:49:47 I have finally decided to post a bugzilla report Feb 06 10:49:49 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11016 Feb 06 10:49:51 Bug 11016: normal, Undecided, ---, srifenbark, NEW , First boot postinst actions Feb 06 11:11:07 reibax: I don't understand why exit 1 doesn't work Feb 06 11:11:23 reibax: what happens, and what is expected to happen? Feb 06 11:13:19 it seems that when you inherit from systemd, the inherited class adds some postinst code that forces exit 0, when running exit 0 code on postinst, opkg assumes that postinst actions have successfully completed even if you have code ready to be run on the target system on first boot Feb 06 11:13:44 that's why the manual suggests to put exit 1 at the end of the postinst code to be run at compile time Feb 06 11:14:38 reibax: where does the manual suggest that? Feb 06 11:15:08 development manual, 5.3.18 Post-Installation Scripts Feb 06 11:15:24 I have looked at both Krogoth (2.1) and 2.2 manuals Feb 06 11:15:33 and both of them use the same sample code Feb 06 11:17:22 reibax: yeah, so you want to have additional actions that can only be run on target? Feb 06 11:17:27 reibax: or what is the issue? Feb 06 11:18:13 yes, that is correct Feb 06 11:18:29 whenever you want to have aditional actions run at first boot on target Feb 06 11:18:52 reibax: then why doesnt this work? Feb 06 11:18:52 pkg_postinist_prepend() { Feb 06 11:18:52 if $D is defined: Feb 06 11:18:52 exit 1 Feb 06 11:18:52 actions Feb 06 11:18:53 .... Feb 06 11:18:53 } Feb 06 11:20:50 morning Feb 06 11:20:59 well... if you put that you will not be doing stuff such as enabling systemd processes at compile time Feb 06 11:21:09 *processes=services Feb 06 11:23:21 reibax: is it a problem to have them postponed to first boot as well? Feb 06 11:26:26 reibax: also, where in the systemd class is exit 0 forced? I'm not seeing it Feb 06 11:34:00 kanavin: I will do some tests, and will get back to you later, I have to go to a meeting now Feb 06 11:34:51 reibax: yeah, I'll write a comment to the bug, I do not think there is anything to fix or improve Feb 06 11:35:07 kanavin: that's fine Feb 06 13:00:56 hello, I'm trying to build an image with a 64 bit kernel and a 32 bit rootfs for an Intel Atom board. Is it required to use multilib in order to do that ? Feb 06 13:01:26 has someone here already done this ? Feb 06 13:15:55 lemagoup: x32 should work to some extent (I've never tried though), see http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#x32 Feb 06 13:21:17 jku: I don't think they mean x32. Feb 06 13:21:47 lemagoup: yes, you'd need multilib to do that the easiest way. Feb 06 13:22:15 ok, then I'm mistaken too, how else do you do 32 bit rootfs? Feb 06 13:23:25 hmm sure, multilib gives you specific 32 bit libraries and binaries Feb 06 13:25:26 jku: RP: x32 does not seem to suit my needs, I would like a x86_64 kernel with i686 rootfs Feb 06 13:25:51 I'll have a look at multilib then. Feb 06 13:28:02 RP, jku: I thought tweaking the PACKAGE_ARCH variable in kernel recipe could work Feb 06 13:29:35 Q: how do I match multiple lines in a file against a regular expression, from command line? Feb 06 13:29:44 standard grep only works line by line Feb 06 13:30:19 the use case is that I need to find a function definition that does something specific in the function body Feb 06 13:35:28 kanavin: sounds like an awk/ed problem Feb 06 13:36:15 ipuustin: apparently grep can be convinced as well: http://stackoverflow.com/a/25180652 Feb 06 13:36:41 (insert joke here) Feb 06 13:38:11 kanavin: you can almost certainly do that with some unintelligible line of sed as well Feb 06 13:45:54 lemagoup: you probably could do it the other way, build a 32 bit rootfs/image and tweak the kernel config/compiler options. I suspect multilib would turn out slightly easier thugh Feb 06 13:48:08 kanavin: I have vague recollections egrep can help with that too Feb 06 13:49:04 RP: ok, thanks Feb 06 14:42:06 hello Feb 06 15:00:42 hey all. For a specific hardware, i need to built a new image type that will depends on .ext4 generated by regular yocto process. So i tried to 1/ in my my-meta/conf/machine/my_machine.conf, i added IMAGES_CLASSES += "image_types_myimg" then 2/ i create a my-meta/classes/image_type_myimg.bbclass and 3/ in the newly created a function IMG_CMD_myimg Feb 06 15:00:48 until here, everything seems ok Feb 06 15:00:49 but Feb 06 15:01:01 when my IMG_CMD_myimg is called, the .ext4 file hasn't been generated yet Feb 06 15:01:06 so my function fail Feb 06 15:01:56 i tried to add ${PN}:do_img_ext4 into IMAGE_DEPENDS_myimg Feb 06 15:02:11 but yocto complains about a circular dependency Feb 06 15:02:35 im no expert, but if you make a gist on github with your file changes I'll take a look and try to help you. Feb 06 15:24:04 What simple shell command line tool can do signing and verification using public key cryptography? Any alternatives to gpg? Feb 06 15:24:07 binarym: I think you want IMAGE_TYPEDEP_myimg = "ext4" Feb 06 15:34:20 hmm, trying to use meta-xilinx gives me an error about "file://" not being a valid url Feb 06 15:35:44 RP building with master and noticed a missing substitution -- staging.bbclass line 467 Feb 06 15:35:54 msgbuf.append("Skipping setscene dependency %s for installation into the sysroot") Feb 06 15:36:04 fray: suggested this might have been fixed Feb 06 15:36:18 so decided to ping you before flinging a patch out on the list Feb 06 15:37:41 peacememories: what is the error? Feb 06 15:37:56 nrossi: "ERROR: Failed to parse recipe: /vagrant/meta-xilinx/recipes-bsp/device-tree/device-tree.bb" Feb 06 15:38:01 oh wait Feb 06 15:38:07 "Exception: bb.fetch2.MalformedUrl: The URL: 'file://' is invalid and cannot be interpreted" Feb 06 15:38:14 that's the actual "error" part^^ Feb 06 15:38:38 peacememories: which machine are you trying to use? and which version of meta-xilinx/etc? Feb 06 15:39:13 using the morty branch of meta-xilinx, and i'm using it as a dependency of meta-elphel393 Feb 06 15:40:33 peacememories: and which machine of the elphel393 layer are you using? Feb 06 15:40:47 elphel393^^ Feb 06 15:41:50 i know, the elphel project has a git repo which automatically sets up the build environment (currently testing if that works for me), but since i'm planning to write some layers for the elphel board i though i'd try to set it up manually Feb 06 15:44:27 peacememories: which branch of the meta-elphel393 are you using, i don't see a morty branch for it... Feb 06 15:44:45 marka: I'll fix it, thanks Feb 06 15:44:54 currently master, because i couldn't find a morty branch, just master, master-next, etc. Feb 06 15:44:57 marka: I have a patch set which will conflict :) Feb 06 15:45:12 cool Feb 06 15:45:14 thanks Feb 06 15:45:21 glad I pinged you then Feb 06 15:47:29 peacememories: hmmm i'd suggest trying their git repo that sets things up... it looks like it might depend on its magic... e.g. in the bbappend it relies on external files not in the layer: FILESEXTRAPATHS_append := "${TOPDIR}/../../linux-elphel/src/arch/arm/boot/dts:" Feb 06 15:48:37 ed2: when an image recipe uses wic to create an image, with a .wks file that specifies a custom source plugin for one partition, and that plugin has some dependencies on certain native tools, where do I specify those dependencies? Feb 06 15:48:45 marka: I'd actually noticed and been meaning to fix but not quite gotten there... Feb 06 15:49:16 we all have our all too long TODO lists Feb 06 15:49:30 they only ever get longer Feb 06 15:49:31 nrossi okay, thanks Feb 06 15:49:37 pohly: in the image recipe I guess. Feb 06 15:49:41 My expectation was that I add them to DEPENDS of the image recipe (knowing that this is not quite right, because the image might not end up using wic as IMAGE_FSTYPE), but that doesn't work. Feb 06 15:50:05 RP, I just happen to be in there looking as GO is causing me some pains in the /recipe sysroots Feb 06 15:50:43 pohly: nowadays all wic delpendencies have to be wic-tools dependencies, so you can just add them there. This is not ideal solution, but this is what we've done to support recipe-specific sysroots. Feb 06 15:51:11 ed2: I thought so, too, but that doesn't work. exec_native_cmd() takes a native_sysroot. When I pass the value given to my do_prepare_partition(), I end up passing wic-tools/1.0-r0/recipe-sysroot-native and that's not where the dependencies of the image are installed. Feb 06 15:52:46 But wic-tools is built only once for the entire distro. How can an image recipe influence the building of wic-tools? Feb 06 15:52:58 That completely breaks encapsulation. Feb 06 15:54:35 Where is the dependency on wic-tools specified? Feb 06 15:55:17 One could define a "my-image-tools.bb" that DEPENDS on wic-tools plus the additional tools. Feb 06 15:56:05 pohly: the dependency is specified in image_types_wic.bbclass Feb 06 15:56:29 pohly: do_image_wic[depends] += "wic-tools:do_build" Feb 06 15:57:26 Yes. So it's hard-coded, although that could probably be turned into an image variable. Feb 06 15:59:14 pohly: yes, it can be, but I'm not sure it's a good way to go. Probably better would be to make wic to look at the image recipe sysroot first and then to wic-tools sysroot when it looks for the native tools. Feb 06 16:00:34 pohly: the main issue I'm struggling with is support of 2 wic modes - one is when its run from bitbake and another one - when its run as a stand-alone tool Feb 06 16:01:42 pohly: putting all required tools into one recipe sysroot was the solution we came up with that can work for both usage scenarios Feb 06 16:02:29 ed2: I agree, for one-off images it is easier to use their own native sysroot. If those tools end up being needed by multiple image recipes, then a custom my-wic-tools recipe would be more efficient. Feb 06 16:02:48 pohly: as when wic is run as a stand-alone tool it may not have any info about image recipe. it can just have a bunch of directories provided as parameters. Feb 06 16:06:13 pohly: yep, that's another point. wic can use multiple image recipes in .wks file. When some tool is needed it would probably be not so easy to understand which image recipe to look at. This can slow wic down I think. Feb 06 16:06:57 I don't think that checking multiple path entries would slow down wic. Feb 06 16:07:15 pohly: currently wic would just use wic-tools sysroot to get those tools. Feb 06 16:07:49 A stat() call is cheap compared to the actual work triggered when building images, Feb 06 16:07:58 hi, is there a way to buld a older yocto system on a new workstation with gcc6.3 ? i get a lot of warnings as errors notifications... Feb 06 16:08:13 pohly: it will slow it down, I'm afraid. Sometimes wic will have to run bitbake to get variable values. Feb 06 16:09:19 pohly: for now I think looking at the image sysroot first can solve 99% of the issues, so I'll probably implement that. Feb 06 16:09:50 pohly: would it work for you? Feb 06 16:09:57 That's probably a reasonable approach. Yes, would work for me. Feb 06 16:10:33 pohly: ok. how urgent is it? Feb 06 16:11:07 pohly: anyway, please create a bug if you don't mind. Feb 06 16:11:37 I can hack around it in my experimental source plugin, so not urgent. But having it in 2.3 and perhaps by the time I present at OpenIoT Summit (two weeks from now) would be nice. Feb 06 16:12:02 pohly: as a work around you can add your dependencies to wic-tools. Feb 06 16:12:10 True. Feb 06 16:19:16 Has anyone else seen an issue where apr-native hangs during do_configure (or any other hang?) I can get it consitently on one machine, but it works fine on another Feb 06 16:21:38 pohly: thank you for creating a bug! Feb 06 16:21:52 sgw_: missing DEPENDS which exists on the non-hanging host? I think I saw someone say they saw something similar on a container without which on the host? Feb 06 16:21:53 Is thre a good way to add comments to (R)DEPENDS lists? Can I do something like RDEPENDS_${PN} = "\\n ... "\n # These are added because of...\n RDEPENDS_${PN} += "\\n ... Or would it be better to use _append here? Feb 06 16:22:41 pohly: regarding WKS_FILE_DEPENDS. This would complicate the recipe I guess. Anyway wic image type is usually added to the IMAGE_FSTYPES in the image recipe. Feb 06 16:23:28 pohly: it shouldn't be hard to add wic-specific dependencies to DEPENDS and remove them when wic is removed from IMAGE_FSTYPES. Feb 06 16:23:46 joshuagl: yeah, definitely a possibility, wonder what the missing depends actually is though, I would think that configure would fail instead of just hang. Feb 06 16:24:03 sgw_: time to break out strace? Feb 06 16:24:07 ed2: no, IMAGE_FSTYPES is usually *not* set by image recipes. Feb 06 16:24:12 sgw_: never seen that, definitely time to strace to find out what is hanging Feb 06 16:24:14 joshuagl: yeah, working towards that Feb 06 16:24:53 Wanted to check here before diving too deep Feb 06 16:25:03 It's more common to let the machine definition set the IMAGE_FSTYPES, and the image recipes remain completely oblivious about it. Feb 06 16:25:41 ed2: +1 for what pohly just said Feb 06 16:26:20 One could argue that an image recipe which sets its own special WKS file is an exception, but even then the same image recipe might still work when using different IMAGE_FSTYPES. Feb 06 16:26:30 pohly: sgw_: true. agreed. Feb 06 16:27:21 And in that case IMHO it makes sense to have the "set dependencies based on actual IMAGE_FSTYPES" logic in the common base classes, even though it could also be in the image recipe. Feb 06 16:29:02 sgw_: , joshuagl: rpm builds without 'which' will infinite loop Feb 06 16:29:35 throwing a -x into the configure script will let you figure out if its a bit of bash gone bad Feb 06 16:29:55 rburton: yes, getting there! Feb 06 16:35:36 ed2: what exactly is Partition.size supposed to contain at the end of a do_prepare_partition call? Feb 06 16:36:04 pohly: I have my custom .wks file, but I could possibly do without it. Is there another IMAGE_FSTYPE for something like this?: "part / --source rootfs --ondisk sda --label image_install --align 4096 --fstype=ext4" Feb 06 16:36:10 scripts/lib/wic/plugins/source/bootimg-efi.py uses a rather complicated "du" invocation: du -Lbks Feb 06 16:38:34 ed2: if I read that right, it's the apparent size in 1K blocks. Feb 06 16:39:38 Why so complicated? os.stat().st_size / 1024 should do fine, unless I miss something. Feb 06 16:39:41 pohly: looks like that. there were some changes implementing size restrictions, so I'm not 100% sure. Need to look at the code again. Feb 06 16:40:46 pohly: there are a lot of unnecessary complicated code in wic codebase. I'm in the middle of refactoring it right now. Feb 06 16:41:32 sveinse: I'm not sure. What's wrong with the default IMAGE_FSTYPE and not setting your own wks file? Feb 06 16:43:07 pohly: it's lack of knowledge :) I don't what to set it to. I need a file containing a full partitioned image containing one partition. Feb 06 16:43:57 sveinse: with whatever is necessary to boot into that image, I suppose? That should be already the default. Feb 06 16:43:58 (we're packing the image further into a custom so-called VSI image, which is a kind of sparse dd image for improved deployment) Feb 06 16:48:56 I have problem with encapsulating images/recipes and the use of do_rootfs[depends]: https://bpaste.net/show/1280ffaeef86. I'm seeing that a-initrd-image fails and is not generated when putting it into c-image.bb for some reason. Does anyone have a clue about why? Feb 06 16:50:55 Darn, typo in cut-and-paste. Use this one: https://bpaste.net/show/d4300772b150 Feb 06 16:53:45 Is gpg perhaps already assumed to be provided when using OE? Feb 06 16:53:53 Provided by the host, I mean? Feb 06 16:55:29 There is meta/lib/oe/gpg_sign.py, which seems to use gpg without trying to build gnupg-native (and the latter doesn't build out of the box either). Feb 06 16:56:35 sounds like yes, assumed on the host Feb 06 17:00:47 I wonder what task puts an initrd-image into the tmp/deploy/ directory. Apparently not do_rootfs nor do_image Feb 06 17:15:21 I see that do_image_cpio generates the cpio.gz file from deply which I need in my image. Should I rather depend on "initrd-image:do_image" rather than do_rootfs? Feb 06 17:16:43 yes, do_rootfs only popualtes the rootfs, doesn't build an image file Feb 06 17:17:05 I basically need somewhere to pick up a file/image/tarball to deploy into my image. It does not need to be deploy, but it seems the binaries/images are not stored in the build dir Feb 06 17:18:08 deploy is your option. files written beforeo they go to deploy are done in internal recipe-specific dirs Feb 06 17:18:24 dep on do_image_complete or do_image_cpio and grab it from deploy Feb 06 17:23:43 I am trying to build poky to include the docker engine. Does anyone here know how to achieve that? Feb 06 17:26:56 kergoth: thanks Feb 06 17:40:36 How do I run bitbake interactively, and let it list the tasks as it goes along. Disable the terminal thing. -v is too verbose and I don't know what to ask of google. I'm getting old... Feb 06 17:46:12 note to self: TERM=foobar bitbake ... , -u does not seem to have any option to set no UI. Feb 06 18:13:32 ERROR: vsi-image-1.0-r0 do_rootfs_wicenv: Taskhash mismatch ... <-- what does this mean? Feb 06 18:19:51 and rerun bitbake straight after and it is happy. :o We all love races, don't we? Feb 06 18:30:25 If I have a vsi_compress() function that is used from IMAGE_POSTPROCESS_COMMAND_append = " vsi_compress;", what is the IMAGE_**[vardepsexclude] = "DATETIME" statement I need to use? What is **? Feb 06 18:31:41 IMAGE_POSTPROCESS_COMMAND[vardepsexclude] = "DATETIME" ? Feb 06 19:05:54 maxin: around? Feb 06 19:09:41 Noob question: I deleted tmp/deploy (although there was a file telling me not to), how to rebuild without redoing all the work Feb 06 19:11:32 karulont: I usually delete tmp/ often, but make sure sstate-cache/ is intact. This way rebuilding everything will take minutes, not hours. Feb 06 19:12:04 If you have enabled sstate-cache that is. I don't remember if you need to specifically enable it to get it Feb 06 19:12:16 Okay, I try deleting not just tmp/deploy, but whole of tmp. Feb 06 19:12:33 yes. Do you have a sstate-cache dir? Feb 06 19:12:59 I have one Feb 06 19:13:27 so, it should be able to fetch most of the recipes from there and save you a lot of time Feb 06 19:22:39 whole tmp seems too large, I will try other things first. Feb 06 19:24:08 It seems that "rm -rf tmp/sysroots tmp/deploy" makes the system recreate packages that I deleted in the tmp/deploy directory. Feb 06 19:27:22 nah did not quite work. Feb 06 19:27:39 I will read on the sstate-cache a bit, before deleting all tmp Feb 06 19:31:44 Now I understand what sstate-cache does, so deleting whole tmp was actually the correct thing to do. Feb 06 19:32:24 Thank you sveinse! Feb 06 20:09:22 hi all Feb 06 20:09:59 I tried to build intel-x86_64 machine for core-image-minimal but mounting rootfs doesn't work (tested on jethro) Feb 06 20:10:03 any ideas? Feb 06 20:10:15 init script from initrd is runnig Feb 06 20:10:31 but cannot find rootfs.img on usb (testing live image) Feb 06 20:48:54 which image did you build and flash Feb 06 20:54:19 I'm looking for information about building docker for yocto. I have added all the necessary layers and a IMAGE_INSTALL_append = " docker" entry to my bbclass. Any help would be appreciated. Feb 06 20:55:44 spierepf: that provided almost no useful information. which layers? what was the behavior when you tried to build? if you have a problem, spit it out already :) Feb 06 20:56:38 I've added meta-oe meta-python meta-networking meta-filesystems and meta-virtualization. Feb 06 20:57:20 if I have downloaded some files/repots with the conf settings to place the repots used to build, what should I specify for the SRCREV to use these repots? Previously I had SRCREV=${AUTOREV} and that pulled the latest. I have the additional problem of my recipe pulling two repots in the recipe. Here is a copy/paste of what I have tried and my current situation. Feb 06 20:57:33 https://gist.github.com/netskink/38803bae369f9599ce885b3ecef420a5 Feb 06 20:57:41 Here is the error message: http://pastebin.com/jbRz9iHX Feb 06 20:58:09 SRCREV only sets the version to be checked out, that's all. it doesn't control what repository is used, that's what MIRRORS and PREMIRRORS are for, as well as externalsrc Feb 06 20:58:48 spierepf: sounds like you should report the bug in the docker recipe to the maintainer of the layer that provides it, via whatever appropriate means. see the README in the layer. Feb 06 20:59:14 yes that gist shows i've got the two git repots pulled Feb 06 20:59:42 and i have the repots show relative to my mirror/premirror ls Feb 06 21:00:15 davis: notice, name=v16. you need to set SRCREV_v16, just as the error message tells you Feb 06 21:00:20 Please set a valid SRCREV for url ['SRCREV_v16_pn-pcmx', 'SRCREV_v16', 'SRCREV_pn-pcmx', 'SRCREV'] Feb 06 21:01:20 let me try that, SRCREV_v16 Feb 06 21:01:38 hmm maybe I need a setting for all those items in the [] Feb 06 21:01:44 no, you don't Feb 06 21:02:59 hmm Feb 06 21:03:23 i have this error, Please set a valid SRCREV for url ['SRCREV_pcmx_pn-pcmx', 'SRCREV_pcmx', 'SRCREV_pn-pcmx', 'SRCREV'] (possible key names are git://ssh@devsupport:22/tfs/pcm5/_git/pcmx;protocol=ssh;destsuffix=git/pcmx;branch=master;name=pcmx, or use a ;rev=X URL parameter) Feb 06 21:03:59 is it saying I need to set the value for all of the itmes in the [brackets] or just the first one? Feb 06 21:04:48 i just told you, you don't need to set them all Feb 06 21:05:07 'SRCREV' will only work if there are no other named urls, otherwise it needs to be specific to the name (v16) Feb 06 21:05:16 _pn- is only needed if you're setting it in local.conf rather than the recipe or an append Feb 06 21:06:56 hmm. i do not understand. i have added, SRCREV_v16 ?= "a2d1f0225692c7c054014ec4dfc4dd13a35245ee" Feb 06 21:07:05 and that is the error Feb 06 21:07:16 the d3v16 gets pulled as v16 Feb 06 21:07:27 added it where? Feb 06 21:07:38 further down in the file Feb 06 21:07:40 SRC_URI = " \ Feb 06 21:07:40 git://ssh@devsupport:22/tfs/pcm5/pcmx/_git/d3v16;protocol=ssh;destsuffix=git/d3v16;branch=master;name=v16 \ Feb 06 21:07:41 what file? Feb 06 21:07:44 git://ssh@devsupport:22/tfs/pcm5/_git/pcmx;protocol=ssh;destsuffix=git/pcmx;branch=master;name=pcmx \ Feb 06 21:07:44 the recipe? Feb 06 21:07:47 " Feb 06 21:07:47 the .bb file Feb 06 21:07:51 it's really not that hard to be explicit Feb 06 21:07:57 referencing things iwthout any context is not useful Feb 06 21:08:05 all of this in the same .bb file Feb 06 21:08:35 the bit I put in the gist is just the diff between what works with network and what I'm trying to change to get it to work without network Feb 06 21:09:23 as i said, the srcrev has to be based on the name= in the url, d3v16 will not do anything, it has to be v16 Feb 06 21:09:35 i'd also be absolutely certain that srcrev is valid for that repo Feb 06 21:10:39 lol, i'm trying to say ive added what you suggested, i have a setting for SRCREV_v16 ?= "some hash" Feb 06 21:11:55 the only thing is that in premirrors, its not specified as v16 despite what i have specifed in the SRC_URI i've show above where it says name=v16 Feb 06 21:12:07 in the mirrors dir it looks like this: Feb 06 21:12:16 git2/devsupport.22.tfs.pcm5.pcmx._git.d3v16/ Feb 06 21:12:26 so i also have Feb 06 21:12:31 SRCREV_d3v16 ?= "a2d1f0225692c7c054014ec4dfc4dd13a35245ee" Feb 06 21:12:50 so if it uses d3v16 or v16 i have the same hash Feb 06 21:13:41 the error says Please set a a valid SRCREV for url ['SRCREV_pcmx_pn-pcmx', 'SRCREV_pcmx', 'SRCREV_pn-pcmx', 'SRCREV'] it looks like it has an error with a bunch of variables. Feb 06 21:15:40 hmm this fix appears to be working. i'll paste what ive done Feb 06 21:16:47 https://gist.github.com/netskink/38803bae369f9599ce885b3ecef420a5 Feb 06 21:16:55 look at the file, "what seems to work" Feb 06 21:17:09 that shows the entire stuff relative to the problem Feb 06 21:27:36 i've made a new mylayer/recipes-core/core-image-rt-initramfs.bb, in it i set IMAGE_FSTYPES and "require recipes-rt/images/core-image-rt.bb" Feb 06 21:27:54 i also have a mylayer/recipes-core/images/core-image-rt.bbappend Feb 06 21:28:11 how do make sure that my initramfs version includes all the appends from core-image-rt.bbapend? Feb 06 21:29:09 khem: core-image-minimal Feb 06 21:30:47 khem core-image-minimal Feb 06 21:56:11 miceopede: I don't think you can... but really image recipes ought to be fairly straightforward, I usually recommend copy-and-modify anyway Feb 06 21:56:53 miceopede: if you're doing advanced stuff in the image recipe and you want to do that in multiple image recipes, you may wish to consider breaking that out into a class instead Feb 06 21:59:57 @bluelightning i made a new image recipe that just requires core-image-rt instead of appending to it Feb 06 22:00:07 and then the initram-fs version requires that Feb 06 22:00:10 i think this will work..? Feb 06 22:02:25 miceopede: that will work yes... if you change something in the chain without considering that inheritance structure it'll potentially cause issues, but otherwise it's fine Feb 06 23:14:31 good news everyone: i can independently verify that the meson recipe on the list a while back will happily cross-compile for all architectures (tested using libepoxy) Feb 06 23:20:38 \o/ Feb 06 23:22:20 hmm, we have to find a good home for https://wiki.yoctoproject.org/wiki/Technical_FAQ Feb 06 23:22:32 assuming it doesn't just live on the wiki (or get moved to the OE wiki?) Feb 07 00:02:43 No, my image keeps failing on taskhash mismatch. What do I need to set IMAGE_*[vardepsexclude] = "DATETIME" to? IMAGE_POSTPROCESS_COMMAND? Since I have a function using date (indirectly) from this function. Or is it IMAGE_${PN} ? Feb 07 01:21:12 sveinse: it'll be on the function that actually refers to the variable Feb 07 01:25:25 sveinse: try to isolate your use of DATETIME Feb 07 01:25:36 sveinse: mostly its in some post image functions etc. **** ENDING LOGGING AT Tue Feb 07 03:00:01 2017