**** BEGIN LOGGING AT Wed Mar 21 03:00:03 2018 Mar 21 05:13:44 New news from stackoverflow: how to add full x11 support for imx6 board in yocto krogoth Mar 21 08:03:42 Hi. Would it be possible to have a do_install_append_PACKAGE-NAME, which will be appended only when the package is installed? i have made some tests and some searches but seems not. Just checking if I'm wrong Mar 21 08:04:02 Just to be clear do_install_append_PACKAGE_NAME Mar 21 08:04:15 ok seems that underlines are removed :) Mar 21 08:04:23 underscores :) Mar 21 09:03:32 good morning Mar 21 09:04:44 hanthings: define do_install_append into your PACKAGE-NAME.bb Mar 21 09:14:30 New news from stackoverflow: How can I add a task after do_deploy()? Mar 21 09:35:46 hanthings: the answer is no, because do_install has nothing to do with package installation in the image Mar 21 10:15:02 rburton, thanks. what would be the solution here? I have a binary file that I want install it only in some conditions Mar 21 10:15:26 hanthings: put the file in a package of its own, only install it in some conditions Mar 21 10:17:36 that's what I did. But also I did add a do-install-append() and there I install the file if the package is selected. I thought that there is a better option for this Mar 21 10:19:05 Hi folks! Mar 21 10:19:24 Could you help me to understand how i can add bbappend to my layer that patches recipe from another?Now, i get that my bbappend just is not used Mar 21 10:19:25 hanthings: what youre missing is that the recipe's do_install will be ran *once* to generate the packages to be used in *all* images Mar 21 10:19:43 hanthings: it doesn't get re-executed because the images contents change Mar 21 10:20:15 recipes build packages, packages are used to build images. if the contents of the image change, then the recipe doesn't rebuild new packages. Mar 21 10:20:22 i have this in layer.conf BBFILES += "${LAYERDIR}/recipes*/*/*.bbappend" Mar 21 10:21:00 i used bitbake-layers show-appends and got that my bbappend isn't used Mar 21 10:21:25 Hello i'm getting the following errors: The following packages could not be configured offline and rootfs is read-only: ['libgdk-pixbuf-2.0-loader-gif', 'libgdk-pixbuf-2.0-loader-xpm', 'librsvg-2-gtk', 'libgdk-pixbuf-2.0-loader-jpeg', 'libgdk-pixbuf-2.0-loader-png'] Mar 21 10:21:27 rburton, yes I agree with that Mar 21 10:25:15 rburton, but in case I add/remove a package from PACKAGES, shouldn't this basically change the image as well since the package changed? Mar 21 10:31:11 how can i enable my bbappend? Mar 21 10:32:44 acrap, do you have your layer added in bblayers.conf? Mar 21 10:33:24 hanthings: the recipe has no idea what the image wants so can't control PACKAGES Mar 21 10:34:10 say you have image-with-thing and image-without-thing. you can build both at the same time in the same bitbake call. Mar 21 10:35:12 rburton, I'm talking about this https://www.yoctoproject.org/docs/2.4.2/mega-manual/mega-manual.html#splitting-an-application-into-multiple-packages Mar 21 10:35:37 hanthings: sure almost every recipe splits into multiple packages Mar 21 10:35:51 the binary, the debug info, the development headers, the static libraries, the documentation, the locales, ... Mar 21 10:36:11 if you have a binary that you want in some images but not others, but it in a package of its own and install it in some images and not others Mar 21 10:38:44 hanthings is: i have. This layer includes some recipes that work fine Mar 21 10:39:15 hanthings is: but bbappend doesn't Mar 21 10:40:44 acrap: maybe some naming/versioning mismatch? Mar 21 10:41:59 acrap: can you share the layer? Mar 21 10:44:18 rburton: i can share names. original file is named "packagegroup-wr-core-cgl.bb" my file is "packagegroup-wr-core-cgl.bbappend". There are no versions at all. Mar 21 10:47:08 LetoThe2nd: i don't think so. There are no versions at all. Names are right, i checked it multiple times Mar 21 10:49:32 rburton: bbappend inside this dir "layers/meta-cera/recipes-base/packagegroups" Mar 21 10:49:36 acrap: is the original recipe maybe already appended once? Mar 21 10:50:18 you can append many times Mar 21 10:50:34 LetoThe2nd: Does it make difference? I will check Mar 21 10:50:53 acrap: put syntax error in the append to verify that it isn't being parsed at all Mar 21 10:52:01 rburton: "bitbake-layers show-appends" not enough? I checked. There is no another bbappend for this recipe Mar 21 10:52:19 acrap: does anything else from that layer work? :-D Mar 21 10:53:00 LetoThe2nd: yep. it includes some recipes, machines, all work fine Mar 21 10:55:32 rburton: i tried to put error to bbappend. It makes no difference at all... Mar 21 10:56:17 acrap: what is the full path in the layer to the append? Mar 21 10:56:47 recipes-base/packagegroups/packagegroup-wr-core-cgl.bbappend Mar 21 10:57:31 hm Mar 21 10:57:54 i have this in layer.conf Mar 21 10:58:00 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \\ Mar 21 10:58:01 ${LAYERDIR}/recipes-*/*/*.bbappend" Mar 21 10:59:24 the double backslash is irritating Mar 21 11:01:04 but i'd think that it doesn't make a differenct. Mar 21 11:07:59 heya people, I'm trying to make a simple recipe for a systemd service that should start on boot. I basically think everything works EXCEPT the fact the service just doesn't start on its own. It can be manually started through systemctl just fine, bitbakes alright, boots as usual, but it seems that I can't do the systemctl enable through the yocto recipe. Can anyone take a look over this in case I'm just missing something out? Mar 21 11:08:16 https://pastebin.com/raw/1EkGG9vb Mar 21 11:12:22 TLDR: can't make the recipe systemctl enable a service Mar 21 11:15:34 LetoThe2nd: it was a double backslash Mar 21 11:15:48 i created layer with bitbake command Mar 21 11:16:18 and i didn't touch this layer.conf at all Mar 21 11:17:19 oh... by the way, it works! Thank you all, guys. It was a good hunt Mar 21 11:17:54 kergoth: afaiu if I add `myoverride` to `OVERRIDES`, `do_install_append_myoverride` will be evaluated automatically too, right? Mar 21 11:17:56 LetoThe2nd, rburton thank you! Mar 21 11:18:37 acrap: and what did you change now, so we can give advice once the next similar problem arises? Mar 21 11:18:56 hi, in my rocko setup the qemu-native package is always built. who pulls it in, and how do I disable it? Mar 21 11:19:49 according to taskexp, nobody depends on qemu-native:do_build (nor qemu-native:) Mar 21 11:20:08 LetoThe2nd i just removed double backslash and use backslash once. Mar 21 11:20:26 now it looks: Mar 21 11:20:37 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ Mar 21 11:20:39 ${LAYERDIR}/recipes-*/*/*.bbappend" Mar 21 11:21:43 acrap: then i'm wondering where that extra backslash came from. do you have a vcs history you can check for it? my layers are usually created with yocto-layer create, and they do not have it. Mar 21 11:27:39 LetoThe2nd: oh, it looks impossible, i created it so long ago... Mar 21 11:27:48 lucaceresoli: anything using glib, anything using fonts, anything using gtk+, Mar 21 11:28:05 lucaceresoli: and systemd, eudev Mar 21 11:28:30 lucaceresoli: why do you want to remove it? Mar 21 11:30:03 rburton: I wanted to remove it because I didn't know I needed it... Mar 21 11:30:44 lucaceresoli: its building it because you do :) Mar 21 11:30:46 Does anyone know how to solve this error? The following packages could not be configured offline and rootfs is read-only: ['libgdk-pixbuf-2.0-loader-gif', 'libgdk-pixbuf-2.0-loader-xpm', 'librsvg-2-gtk', 'libgdk-pixbuf-2.0-loader-jpeg', 'libgdk-pixbuf-2.0-loader-png'] Mar 21 11:30:57 itsfemme[m]: read the roots log and figure out why they're failing Mar 21 11:31:48 rburton: BTW why do these features need qemu-native? is this dependency documented? Mar 21 11:32:07 WARNING: The postinstall intercept hook 'update_pixbuf_cache' failed, details in log.do_rootfs Mar 21 11:32:07 NOTE: Exit code 1. Output: Mar 21 11:32:08 NOTE: The postinstalls for the following packages will be postponed for first boot: --snip-- Mar 21 11:32:19 lucaceresoli: because they need to run code for the target Mar 21 11:32:43 lucaceresoli: the dependency is in the recipes, taskdep should have shown it but frankly its not great. -g will probably list it. Mar 21 11:34:47 I have the whole log.do_rootfs here: https://share.riseup.net/#drw8beaC-sniRFsY5GaEBg Mar 21 11:36:13 rburton: yes, bitbake -g shows these deps, and there are several... Mar 21 11:37:42 rburton: ok, guess I'll accept that I need an emulator -- and the related build time :( Mar 21 11:39:12 lucaceresoli: its just a couple of minutes, once. speeds up every first boot as it doesn't need to spend an age generating caches/indexes/etc. Mar 21 11:39:44 oh that reminds me, i was going to look into a hack to make qemu-native faster Mar 21 11:39:49 * rburton tries Mar 21 11:54:56 hey again, is there any documentation on how to install a service via a .bb recipe and have it start automatically on the target boot? Mar 21 11:55:43 flying_sausages: maybe use the reverse approach: look for a service that is enabled and inspect its recipe :) Mar 21 11:58:07 flying_sausages: https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-classes-systemd Mar 21 11:58:19 > Services are set up to start on boot automatically unless you have set SYSTEMD_AUTO_ENABLE to "disable". Mar 21 11:58:34 hmmm that looks like some nice docu Mar 21 11:59:19 T_UNIX, this is what I have now fyi https://pastebin.com/raw/1EkGG9vb Mar 21 11:59:22 flying_sausages: maybe your service's [install]-section is faulty though? have you tried to manually `systemctl enable my.service`? Mar 21 12:00:05 T_UNIX, good call! I'm getting errors indeed Mar 21 12:02:19 Alright, I added an Install to the .service, let me do some testing now Mar 21 12:05:43 flying_sausages: IMHO using yocto is a bit like configuring/manipulating a machine that spits out machines. That's why I usually try things on the target first, before looking for the yocto ways to reproduce what I did in an automated/clean fashion. Mar 21 12:06:15 that'a s good point, I'm just starting with yocto so this advice is for sure helpful, thanks! Mar 21 12:15:16 lucaceresoli: if the compile time of qemu bothers you, set QEMU_TARGETS in your local.conf to the arches that you need. we build the lot so a single qemu-native works everywhere, but if you're only targetting arm you can just build that target Mar 21 12:15:22 see the qemu recipe for the list of targets Mar 21 12:15:53 changing it from all to just x86-64 dropped 70% off the build time here (processor time, not wall time) Mar 21 12:38:51 Hello Mar 21 12:41:23 Is there a way to get some recipes installed in a custom path? Basically change base_prefix, prefix and exec_prefix only for some recipes? I'm building a image where I want some packages to go their normal locations on the rootfs, e.g /bin, /usr, /etc but I want some recipes to install all their files under /apps/ or something similar Mar 21 12:42:21 StefanS19: set prefix in the recipe Mar 21 12:42:25 StefanS19: probably the best way is to create some myapp.bbclass that does what you want, and include it in the needed recipes Mar 21 12:43:11 hmm.. is there a way to hook this in without editing the recipes? there are quite a few and most of them are oe-core or meta-openembedded... I trying hard no to change upstream layers if I don't need to Mar 21 12:43:25 or for each of those add a bbappend in my layer? Mar 21 12:43:27 StefanS19: bbappends Mar 21 12:44:15 hmm, so I can't make a bbclass that I can somehow inject into a list of recipes without adding a bbappend for all of them? (not in the mood in adding 50 bbpappends) Mar 21 12:44:36 you should be able to just change prefix, so you can do that from your distro conf Mar 21 12:44:42 maybe one could also do it with some distro magic, but thats rather prone to break over time, IMHO Mar 21 12:44:42 prefix_pn-foo = "/apps" Mar 21 12:44:46 rburton_: hi5 Mar 21 12:45:26 rburton_: hmm that sounds good. wondering what will break.. Mar 21 12:47:41 depends how standalone the recipes you're building are really Mar 21 12:48:00 the reason I want this is that I'm trying to have a / partition as small as possible which has the packages from the "release" image... But during developement devs needs debug stuff installed so we have a dev image that adds a bunch of extra packages, but that means we are running with a rootfs different from the production one Mar 21 12:48:01 as by changing prefix you're basically removing the references to the system in /usr Mar 21 12:48:09 I know Mar 21 12:50:35 Hello, I'm trying to use a custom initramfs image, I've set INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE, so I have a bzImage-initramfs-genericx86-64.bin built. But what is used to create the wic image is still the bzImage without the initramfs (it seems to be hardcoded in bootims-efi plugin). Is there a way to use the bzImage with the embedded initramfs instead ? Mar 21 13:52:07 here's what I'm doing right now, is there a way that would not involve patching the base kernel class ? Mar 21 13:52:15 the patch: https://hastebin.com/eherenugon.bash Mar 21 13:53:10 rrerolle: Hi, I am not familiar with x86 (maybe there are some additional stuffs done that I do not know) but at least, if you want to change the images in the boot partition of your wic image, you should have a look at IMAGE_BOOT_FILES variable Mar 21 13:53:16 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-IMAGE_BOOT_FILES Mar 21 14:03:53 Is there a way to use 'bitbake --runall/--runonly' to force a task to rerun for all recipes in the taskgraph? e.g. bitbake -f --runall compile core-image-minimal Mar 21 14:04:47 rrerolle: hm, according to your patch, I guess that you are using "bootimg-efi" plugin Mar 21 14:09:16 Mylene: yes that's correct, it's what the core-image-base uses by default when building for x86_64 it seems Mar 21 14:09:44 in fact I don't especially need EFI so I probably could use another plugin Mar 21 14:10:13 Mylene: thanks I'll take a look at IMAGE_BOOT_FILES Mar 21 14:11:43 it seems to relate to the bootimg-partition wic plugin Mar 21 14:14:32 rrerolle: yep, this is the only plugin I used so far so I am more familiar with this one :) Mar 21 14:16:37 Mylene: ok, thanks...I have to say it's quite confusing how the INITRAMFS_IMAGE_BUNDLE allows you to create a bundled initramfs, but it never seems to be used Mar 21 14:17:38 and also in my local.conf I've set a custom INITRAMFS_IMAGE, but somehow core-image-minimal-initramfs still gets built Mar 21 14:20:01 itsfemme[m]: update_pixbuf_cache is located in scripts/postinst-intercepts. it runs some helper binary under qemu to populate gdk cache - you can probably add more debugging to that to see where it fails exactly Mar 21 14:27:33 rrerolle: wic is based on a .wks file which is "generic-86.wks" by default for x86 machines. This file uses the "bootimg-efi" plugin. If you do not need efi support, I guess you can choose another wks file or create your own (see WKS_FILE variable to set which file used) Mar 21 14:30:50 Mylene: I don't really care about the EFI part, but the bootimg-efi plugin seems to be the only one using grub as a bootloader, which is what I need...so I might end up using it or create my own plugin removing the EFI stuff, and installing the kernel with the bundled initramfs Mar 21 14:31:35 what I don't like is having to patch the base kernel class, so I would need a reliable way to get the name of the bzImage-initramfs file Mar 21 15:24:10 Hi, i would like to add a linux driver for printing device. I have the source of driver. How can i add this to my image using yocto? Mar 21 15:25:10 vladzouth: see: https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-out-of-tree-modules Mar 21 15:25:58 thanks stephano ! Mar 21 15:26:19 np Mar 21 15:50:17 kergoth: hello, man! I've finally built the regular SDK without fails Mar 21 15:50:19 but... Mar 21 15:50:35 It seems I don't get it fully populated Mar 21 15:50:42 Here is the error: Mar 21 15:50:42 Setting it up...find: ‘/opt/recovery-baikal-tpsdk/1.0-rc0/sysroots/x86_64-tpsdk-linux/lib’: No such file or directory Mar 21 15:51:12 It can't find lib dir in the native sysroots directory. Mar 21 15:51:59 it shouldn't actually. All the cross-canadian things got to root with prefix usr/* Mar 21 15:53:02 that error shows up if no nativesdk packages were installed. the scripts should really only search lib if lib exists Mar 21 15:53:16 occurs regardless of external toolchain usage, just depends on whether nativesdk-glibc was installed or not Mar 21 15:53:27 Hmmm, weird Mar 21 15:53:32 I've built them... Mar 21 15:54:12 It took nearly three hours to do it... Mar 21 16:53:12 rburton: let me check the QEMU_TARGETS thing Mar 21 17:04:26 rburton rburton_: with QEMU_TARGETS = "aarch64" it went from 3m58 to 1m48. Not bad Mar 21 17:05:05 kergoth: should all the tools be in the sdk manifest file then? I got plenty of nativesdk utils there. glibc is not one of them... Mar 21 17:05:39 rburton rburton_: it would be interesting to know how much time is spend in building its dependencies; but I guess there is not simple way to compute that given qemu-native cannot be disabled Mar 21 17:05:47 rburton rburton_: thanks for hte hint Mar 21 17:06:59 lucaceresoli: qemu's deps? turn off sdl and its a lot faster Mar 21 17:07:56 (your local.conf may be turning that on) Mar 21 17:09:37 rburton: i.e. comment the two "PACKAGECONFIG_append_pn-*sdl* lines, and leave the ASSUME_PROVIDED line commented, right? Trying... Mar 21 17:09:59 yeah comment out that entire block Mar 21 17:10:12 you dont get a graphical qemu anymore but that might not be a problem Mar 21 17:10:23 won't make qemu that much faster, but it removes a lot of build-deps Mar 21 17:20:49 rburton: disabling sdl seems to work ( bitbake -c cleansstate libsdl-native qemu-native ; time bitbake qemu-native ) but for real timing I'll have to wait the nightly CI job Mar 21 19:56:04 Folks. Small question. If I forcibly cancel the build process, like using double Ctrl+C, will it break anything? Mar 21 19:58:22 shouldn't Mar 21 20:00:18 fancer: i do it all the time. worse case you can delete tmp/ and it will carry on using sstate-cache. Mar 21 20:00:45 Then another reason of why my populate_sdk doesn't include nearly whole nativesdk sysroot (except cross-canadians though) isn't justified.( Mar 21 20:01:33 That's weird really. The SDK installation process just fails, since it can't find /lib directory. Mar 21 20:01:44 have you looked at -e output to verify that you're not just wiping out a varible by using += instead of _append Mar 21 20:02:28 do you mean the variable like TOOLCHAIN_HOST_TASK? Mar 21 20:02:55 what else could be the reason?... Mar 21 20:03:53 yeah that Mar 21 20:05:55 Alas I didn't check the environment, but I took a look at the manifest file of the SDK. It listed everything from: Mar 21 20:05:55 nativesdk-packagegroup-sdk-host and packagegroup-cross-canadian-mipsel Mar 21 20:06:49 I do know, that glibc had was built, but I can't imagine why it hasn't been installed to the SDK/ Mar 21 20:10:11 rburton, sorry to let you down. I manage to hit only 5 breweries in portland Mar 21 20:33:24 kergoth: could you take a look whether your SDK got these dirs and what was in your TOOLCHAIN_HOST_TASK? Mar 21 20:33:45 I mean the dirs like /lib, etc Mar 21 21:11:06 hmmm. What mailing list are documentation updates supposed to be sent to? Mar 21 21:13:18 Ah, I think I need [yocto] in the subject prefix instead of [OE-core] Mar 21 21:37:40 Folks, how to forcibly recreate SDK without full rebuild? Mar 21 21:38:59 fancer: bitbake -fc populate_sdk ? Mar 21 21:39:12 right Mar 21 22:30:08 Folks, are there any limitations and some inter dependencies on setting the TARGET_VENDOR and SDK_VENDOR? Mar 21 22:30:47 I just found, that I got !two! nativesdk-sysroots with SDK. Mar 21 22:33:02 One of them got cross-canadians installed under directory: /sdk/image//${DISTRO}-${TARGET_VENDOR}-${SDK_VENDOR}//sysroots/... Mar 21 22:33:34 Another one got the same path, but was instead of TARGET_VENDOR, it's SDK_VENDOR...( Mar 21 22:34:12 * or it might be HOST_VENDOR... Mar 21 22:40:44 Alright, I think my problem was in this: Mar 21 22:40:44 SDKPATH = "/opt/${DISTRO}${TARGET_VENDOR}${SDK_VENDOR}/${SDK_VERSION}" Mar 21 22:43:32 The path actually changes, depending on the crosssdk, nativesdk or cross-canadian classes usage... Mar 21 22:44:37 TARGET_VENDOR sometimes get to be SDK_VENDOR, but most of the time is set to my globally defined value Mar 21 22:47:20 New news from stackoverflow: One recipi setting path for the recipes that depend on it Mar 21 22:50:11 what a nice bug to find... **** ENDING LOGGING AT Thu Mar 22 03:00:02 2018