**** BEGIN LOGGING AT Thu Sep 14 03:00:00 2017 Sep 14 03:04:54 Between framebuffer and x11 build, which do I need or choose, or how do I choose? Sep 14 04:41:24 Hi guys, does anyone know how to configure fpu support for arm v8 64-bit processor? Sep 14 04:42:03 I'm looking at arch-arm64.inc, and I see that TARGET_FPU_64 is simply set to "" Sep 14 04:52:45 I cannot find: refs/heads/imx-4.1.15-krogoth Sep 14 07:28:18 hello, how can I tell wic to use a specific rootfs from the deploy directory when creating an image? Sep 14 07:29:06 i.e. I have different rootfs'es that I got building different images there, and I want to use both of them in the same sdcard image on different partitions Sep 14 08:18:53 ed21: hello, how can I tell wic to use a specific rootfs from the deploy directory when creating an image? i.e. I have two different rootfs'es that I got building different images there, and I want to use both of them in the same sdcard image on different partitions Sep 14 08:22:51 eduardas_m: you can use rootfs plugin to do this. you can see multi-rootfs example in scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks Sep 14 08:23:28 ed21: thank you Sep 14 08:24:13 eduardas_m: note, that there are 2 ways of specifying rootfs. both are explained in the comments of directdisk-multi-rootfs.wks Sep 14 09:07:53 boucman_work: Hi, i'm trying to integrate image_overlay class, and use it in a recipe, but i'm not sure how to use OVERLAY_ROOT_DIRS. Let say we need to change /etc/avahi/services/ssh.service for example? Sep 14 09:11:07 the idea is that you create a file $OVERLAY_ROOT_DIR/etc/avahi/services/ssh.service Sep 14 09:11:23 now, for the details, i'll have to check the code :) Sep 14 09:12:04 brb Sep 14 09:14:50 boucman_work: back Sep 14 09:16:14 I didn't get your answer Sep 14 09:17:22 ok Sep 14 09:17:29 boucman_work: the idea is that you create a file $OVERLAY_ROOT_DIR/etc/avahi/services/ssh.service Sep 14 09:17:36 boucman_work: now, for the details, i'll have to check the code :) Sep 14 09:18:50 so OVERLAY_ROOT_DIR is usually a sub-directory of your WORKDIR where the files to overlay have been pulled in by do_fetch (I'm not sure if SRC_URI works for image tasks... I think it's reactivated by our patch but i'm not sure... gimmme a sec to check) Sep 14 09:20:04 ok, my bad, that's not exactly how the patch works Sep 14 09:20:24 you devine OVERLAY_SRC_URI with a file/directory/archive to fetch Sep 14 09:20:43 the archive is unpacked, and create a subdir under WORKDIR Sep 14 09:20:58 you give the name of that subdir un OVERLAY_ROOT_DIR Sep 14 09:21:37 the content of that subdir is written as-is on the target rootfs (so the archive needs to have a rootfs-like directory structure) Sep 14 09:24:11 I understand for an archive, but for a file ? Sep 14 09:28:17 honestly, i'm not sure if/how it works for a file, you probably want to do it with an archive, it's the simplest way to do it... Sep 14 09:29:00 no, it wouldn't work with a simple file. Sep 14 09:51:41 ed21: can I use the part command in wks file without specifying the mount point? I do not want my fstab to be modified Sep 14 09:54:40 eduardas_m: yes, you can. Sep 14 09:56:12 ed21: I simply omit the mountpoint part in part [mntpoint]? Sep 14 09:57:03 eduardas_m: you can also use name there without leading slash, e.g. "part second_root". It's more informative and also doesn't cause fstab update. Sep 14 09:57:26 eduardas_m: yes, you can simply omit it. it's optional. Sep 14 09:58:36 eduardas_m: "wic help kickstart" may help you :) Sep 14 09:59:59 ed21: thank you... one more thing... I have added an initrd to a partition using the bootimg-partition approach you told me about yesterday... but can I also tell wic to create a folder "boot" in a partition and add the initrd inside of it? Sep 14 10:02:09 the initrd is added to IMAGE_BOOT_FILES in my machine .conf file Sep 14 10:02:58 i.e. I want the partition to have /boot/initrd and not just /initrd inside Sep 14 10:03:52 eduardas_m: yes, you can specify path I guess. Try this IMAGE_BOOT_FILES ?= "initrd;boot/initrd" Sep 14 10:04:47 eduardas_m: i've never tried it, but it should work I guess. Sep 14 10:05:01 eduardas_m: if it doesn't - file a bug. I'll try to fix it. Sep 14 10:05:37 ed21: thanks again... this is very useful to know Sep 14 10:09:32 ed21: the wic series that you were debating for ages over, is that to be merged and cleaned up further, or rejected and wait for v2? Sep 14 10:10:49 I havn't been following the partitionning stuff in yocto recently, is there a mainlined way to have /usr on a separate partition ? I had customer ask me to do that multiple times, and I have some hacky ways to do it... Sep 14 10:11:19 (/usr or other... the generic problem is read-only rootfs with read-write partitions mounted in strategic places) Sep 14 10:13:09 rburton: I don't know. We haven't come up with solution yet. you can merge 2 first patches I think. Sep 14 10:13:16 ok thanks Sep 14 10:27:17 boucman_work: It can be done using —exclude option in wks. Here is what 'wic help kickstart' says about it: Sep 14 10:27:18 --exclude-path: This option is specific to wic. It excludes the given Sep 14 10:27:18 relative path from the resulting image. If the path Sep 14 10:27:18 ends with a slash, only the content of the directory Sep 14 10:27:18 is omitted, not the directory itself. This option only Sep 14 10:27:18 has an effect with the rootfs source plugin. Sep 14 10:27:35 ed21: I can confirm that the approach of adding a folder into the partition that you just described works for me Sep 14 10:27:50 eduardas_m: great, thanks! Sep 14 10:28:33 this is using freescale community bsp morty release Sep 14 10:41:54 If I may pose a question :) Sep 14 10:42:10 are FOO and FOO_mymachine separate variables? Sep 14 10:42:38 I suppose that FOO_mymachine overrides FOO when MACHINE=mymachine Sep 14 10:43:15 and all operations (+=, _append, etc) must be done for FOO and for FOO_mymachine separately? Sep 14 10:53:03 lukma: += etc, yes - _append/_prepend no (since the latter are deferred, they will conditionally apply depending on whether the override applies) Sep 14 10:53:36 generally I wouldn't mix overrides and += as the results aren't as immediately obvious Sep 14 11:05:50 bluelightning: So it probably would be better to: Sep 14 11:05:50 FOO = (set of defaults) Sep 14 11:05:50 FOO += "${@bb.utils.contains("MACHINE", "mymachine", " extras_for_FOO", "" ,d)}" Sep 14 11:06:42 lukma: no, I'd do that using FOO_append_mymachine = " extras_for_FOO" Sep 14 11:33:55 ed21: thx, i'll look into that, sounds interesting.... Sep 14 11:43:39 bluelightning: But with your approach other "images" (like rootfs initramfs) would get corrupted because extras_for_FOO could be big Sep 14 11:54:21 lukma: not sure I follow... ? Sep 14 11:57:39 I have a few recipes where BB_GENERATE_MIRROR_TARBALLS=1 does not generate tarballs but checks them out into downloads/git2, does anyone have an idea what I might be doing wrong? Sep 14 12:00:55 CoLa|work: it always needs to clone them to downloads/git2, the tarball is created after that just packing the downloads/git2/repository Sep 14 12:01:01 bluelightning: I do experience issues when I had IMAGE_INSTALL_append in one image recie Sep 14 12:01:14 and those IMAGE_INSTALL_append images were large Sep 14 12:01:41 and other image (initramfs) was also using IMAGE_INSTALL = to specify only required images Sep 14 12:02:03 I was very surprised when the initramfs grown considerably Sep 14 12:02:20 because the IMAGE_INSTALL packages were appended to initramfs IMAGE_INSTALL Sep 14 12:06:53 lukma: IMAGE_INSTALL set in one recipe can't affect another unless that recipe requires/includes that recipe Sep 14 12:07:36 lukma: on the other hand if you were to do that IMAGE_INSTALL_append at the configuration level, it'll affect all image recipes Sep 14 12:26:17 lukma: if you put IMAGE_INSTALL_append in a local.conf or something for testing, then you can use the pn-imagename override to restrict it to just that iage Sep 14 12:29:22 JaMa: OK understood, but when there is already a tarball, how can I enforce bitbake then to take it and not trying to access the (possibly access protected) git repository? Sep 14 12:46:21 bluelightning: OK, I see Sep 14 12:46:33 Is this approach acceptable: FOO += "${@bb.utils.contains("MACHINE", "mymachine", " extras_for_FOO", "" ,d)}" Sep 14 12:46:39 (it works on my setup) Sep 14 12:48:08 lukma: that'll work, but I don't see how it relates to the issue you mentioned Sep 14 12:49:20 Just by mistake I did: Sep 14 12:49:34 FOO = packagegroup-core ...... and some one Sep 14 12:49:40 and this was the "default" Sep 14 12:49:54 and then for one machine (baz) Sep 14 12:50:02 FOO_baz = special packages Sep 14 12:50:16 and for baz only special packages were available Sep 14 12:50:22 so FOO was overriden Sep 14 12:51:22 Hello everybody im newbie and i need some information about yocto linux project Sep 14 12:52:00 im trying to use Hob i need to compile it for sma-imx6 Sep 14 12:52:17 any help will be appreciated... Sep 14 12:59:20 Hello everybody im newbie and i need some information about yocto linux project im trying to use Hob i need to compile it for sma-imx6 any help woul be appreciated... Sep 14 12:59:51 are there any human? Sep 14 13:00:54 yes, why hob? Sep 14 13:01:12 because im newbie on embedded systems Sep 14 13:01:29 i couldnt compile yocto via ubuntu yet.. Sep 14 13:01:46 You should read the manual, the documentation is really good and if you have specific question you can ask them here Sep 14 13:02:36 Canu please send me the documentation link? Sep 14 13:03:03 yoctoproject.org -> Documentation Sep 14 13:03:21 you can also use this docker image on ubuntu https://github.com/RobertBerger/yocto-autobuilder Sep 14 13:03:39 Thank u FabKna ur the man.. Sep 14 13:03:41 ;) Sep 14 13:35:02 CoNFiDeNT: In your case, you should probably also look at the relevant Freescale documentation: http://freescale.github.io Sep 14 13:35:36 CoNFiDeNT: Some of it probably assumes you're using some of the c Sep 14 13:36:09 CoNFiDeNT: Some of it probably assumes you're using some of the most common dev-boards, but since it's the same processor, it should help you get started. Sep 14 14:40:27 seebs: is there a part 3 to this? https://www.ibm.com/developerworks/library/os-aapseudo2/os-aapseudo2-pdf.pdf Sep 14 14:54:18 there was once long ago? Sep 14 14:54:27 i don't know if it's still up, dW seems to be a bit vulnerable to bitrot Sep 14 15:43:24 rburton, May I close https://bugzilla.yoctoproject.org/show_bug.cgi?id=12078? Sep 14 15:43:25 Bug 12078: normal, Medium+, Q3, ross.burton, IN PROGRESS REVIEW , Change default Owner Sep 14 15:43:50 * rburton looks Sep 14 18:21:40 Who we can contact to cherry-pick a couple of fixes on meta-oracle-java? Sep 14 18:21:53 two fixes from master to pyro Sep 14 18:33:31 Yocto noob here. I've tweaked conf/local.conf using IMAGE_INSTALL_append to customize the specific packages for my target system. What's the best practice for sharing that config? Seems to me creating a new layer w/a .bbappend for the related image name. Sep 14 18:33:54 What's not clear to me is when I should define a completely new distro. Sep 14 18:34:13 create different images with different packagegroups Sep 14 18:34:42 mostly found in recipes-images Sep 14 18:35:00 clevernickname: Sounds like you should add a new layer in which you define a new disto which comes with a new image, which contains packagegroups, which pulls in the content you want Sep 14 18:35:12 (That may or may not be overkill depending on the size of your project) Sep 14 18:39:59 If I define a new distro, with a new image recipe, then that is *only* viewable if conf/local.conf references that distro. Is that correct? I thought my core-image-minimal.bbappend in the new layer would only be picked up if a distro defined by that layer was selected, but it's being used regardless from what I can see. Sep 14 18:41:16 IIRC you can ship a template for the local.conf with your source code, so you can more or less define what the contents of your local.conf should be by default Sep 14 18:41:38 Plus you can ship a local.conf template that includes a file under your control, where you set up your disto Sep 14 18:41:41 distro** Sep 14 18:46:00 neverpanic: Thanks. Looking up Custom Template configurations right now. Sep 14 19:09:15 neverpanic: Ok. Looks like I can use TEMPLATECONF to create default bblayers.conf and local.conf files -- thanks for the tip! Sep 14 19:10:07 neverpanic: Now I'm wondering -- what's the benefit of defining a whole new distro? If I don't need to change DISTRO_FEATURES or anything else, is there any advantage to doing that? Sep 14 19:14:13 clevernickname: Extensibility, separation, flexibility. You might need it in the future, you might want to switch the distro to a different set of layers later, etc. Sep 14 19:19:11 neverpanic: Maybe I'm being dense here, but isn't switching layers a function of modifying bblayers.conf? I have to admit, I don't fully understand what is intended by the 'distro' concept. I thought it was a defined permutation of the various packages on a system, but I can jack with layers / image contents until the cows come home without having to update the DISTRO variable. Sep 14 19:20:49 DISTRO is a configuration.. a configuration the affects the whole of the recipes you are building to produce your 'custom' distribution Sep 14 19:21:20 'project' settings go in local.conf... this can reference other settings such as MACHINE (BSP/hardware), DISTRO (confgiurations for the overall system), etc. Sep 14 19:23:05 clevernickname: you can also provide a template for bblayers.conf and put an include in it. Sep 14 19:23:51 fray: thanks. I'm currently reading https://lists.yoctoproject.org/pipermail/yocto/2011-December/003813.html to see if I can wrap my head around this. Sep 14 19:34:13 fray: Boiled down, the distro is the "how" and the image is the "what". One distro might define using uclibc, while another one defines using glibc. An image might include an app or might not (regardless of distro selected.) How the app is specifically built (using uclibc or glibc) is determined by the distro. Sep 14 19:34:20 Am I close or off the mark? Sep 14 19:35:25 distro sets configurations, recipes say 'how' to build (using the configuration info) Sep 14 19:35:44 the image is 'just a recipe', but instead of outputting a package -- it outputs an image.. Sep 14 19:35:59 so the 'what' is the output of a recipe.. either a package or an image.. (usually) Sep 14 19:36:21 your 'how the ... is built..' is generally correct Sep 14 19:56:29 fray: thanks for the clarifications. Sep 14 19:57:17 I'm coming at things from a buildroot perspective if that helps. Sep 14 20:03:23 while using externalsrc for recipes, i have found two issues Sep 14 20:04:05 1. debug packages doesnt contain sources at /usr/src/debug Sep 14 20:04:35 2. sstate is not working for externalsrc packages Sep 14 20:06:19 i have fixed the debug packages issue by patching package.bbclass Sep 14 20:09:59 for sstate issue in externalsrc recipes, is it possible to enable setscene tasks if srctree_hash_files reports nothing changed Sep 14 22:41:06 kanavin, turns out I need python-mako Sep 14 22:41:31 What is the suggested fix for this? **** ENDING LOGGING AT Fri Sep 15 03:00:01 2017