**** BEGIN LOGGING AT Tue Sep 26 03:00:03 2017 Sep 26 07:15:52 hello all. Is it possible for a native recipe to disable a task? do_compile_class-native[noexec] = "1" does not seem to work Sep 26 07:19:55 Tamis: have you checked how this gets evaluated with bitbake -e? from my understanding, it might be necessary to extract the native part into a seperate recipe Sep 26 07:20:22 Tamis: e.g. have one inc that does all the core stuff, and have that included by the standard and the -native recipe Sep 26 07:25:53 LetoThe2nd: bitbake -e show that the evaluation is correct. do_compile_class-native but even that it is executed. Sep 26 07:26:11 LetoThe2nd: Thanks for the hint. I might do that. Sep 26 07:26:49 LetoThe2nd: On the net I read also that it might it better to just compile everything for target and host and on install just take what I want. Sep 26 07:27:42 Tamis: that sounds strange, to say the least. Sep 26 07:29:07 hi guys... I need an advice on how to create a rootfs file "/etc/sw-versions", which will include rootfs image version which is dynamic - eg. changes with every build... any ideas? Sep 26 07:29:48 wooosaiiii: for inspiration i'd say to look at the buildstats stuff Sep 26 07:30:23 LetoThe2nd: OK... lets see :D Sep 26 07:30:38 wooosaiiii: other than that, you can always to some rootfs postprocessing stage Sep 26 08:29:17 wooosaiiii: working on swupdate ? :) Sep 26 08:38:05 nayfe: yes :D u too? :D Sep 26 08:39:27 maxin: Hi, I submitted a patch for meta-oracle-java, is there any else thing to do ? I see very few activity on this layer, noone use it anymore ? I also have another problem, that patch https://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/commit/?h=pyro&id=429699eac8f269d72f5baed1e59123f73ebf382f changes DEST to jre, so now java is here /usr/lib/jvm/java-8-oracle/jre/bin/java and /usr/bin/java points to /usr/lib/jvm/java-8-orac Sep 26 08:40:34 wooosaiiii: i'm trying, very slow process for me :( i try to follow https://github.com/sbabic/meta-swupdate-boards but some pieces are left to do Sep 26 08:41:01 wooosaiiii: I get inspired by https://github.com/balister/meta-sdr/blob/master/recipes-images/images/version-image.inc to get hwrevision, postprocessing stuff Sep 26 08:41:16 nayfe: well I am using double-copy scheme... and it works pretty well for me :D Sep 26 08:41:35 on which type of board ? Sep 26 08:42:11 nayfe: can you share the link ? seems to miss some of yocto patches in my mailbox lately . Sep 26 08:42:12 nayfe: my current script :D Sep 26 08:42:13 rootfs_img_ver_fcn() { echo "rootfs-1 ${IMAGE_NAME}" >> ${IMAGE_ROOTFS}/etc/sw-versions echo "rootfs-2 ${IMAGE_NAME}" >> ${IMAGE_ROOTFS}/etc/sw-versions } ROOTFS_POSTPROCESS_COMMAND += "rootfs_img_ver_fcn; " Sep 26 08:42:16 :D Sep 26 08:42:28 ammm nayfe: AM57xx based Sep 26 08:43:27 wooosaiiii: imx6 for me ;) Sep 26 08:43:58 wooosaiiii: hello, I am also a swupdate user... using update variant with initrd on NXP i.MX6 Sep 26 08:44:08 wooosaiiii: do you use wic for final image? Sep 26 08:44:56 eduardas_m: no... i use custom images_types class Sep 26 08:45:11 maxin: https://lists.yoctoproject.org/pipermail/yocto/2017-September/thread.html there are two threads https://lists.yoctoproject.org/pipermail/yocto/2017-September/037956.html https://lists.yoctoproject.org/pipermail/yocto/2017-September/037976.html Sep 26 08:46:54 eduardas_m: hey, have any public meta repo ? Sep 26 08:47:51 nayfe: sadly, no Sep 26 08:48:17 nayfe: these pyro updates are already available in the repo Sep 26 08:48:19 nayfe: but I can share snippets directly if you want Sep 26 08:49:12 nayfe: currently have a wic-based final image recipe Sep 26 08:49:22 but there is one problem Sep 26 08:49:32 I want to have 4 total partitions Sep 26 08:49:41 and the last one is created as extended Sep 26 08:49:45 not primary Sep 26 08:50:12 still trying to figure out how to do that via wic Sep 26 08:50:49 problem is I can not really read Pyrhon code and this behaviour is not documented Sep 26 08:51:10 sorry, "Python code" Sep 26 08:52:50 perhaps a custom images_types class would indeed be better, not sure actually Sep 26 08:55:42 maxin: which git repo ? ;) Sep 26 08:56:26 eduardas_m: yes I went with custom images_types class due to flexibility.... despite it being considered deprecated etc... Sep 26 08:57:10 wooosaiiii: where does it say the method is deprecated? Sep 26 08:57:14 I believe NXP has quite good images_types class... since I took a lot of example code from there... Sep 26 08:58:26 eduardas_m: it doesn't say exactly... but I got feeling that wic is the new preferred way of doing images... but it lacks documentation/examples Sep 26 08:59:24 and for any customization you need to bake your own python code... Sep 26 08:59:44 wooosaiiii: there is wic-image-minimal that is the closest to an example Sep 26 08:59:47 eduardas_m: it seems to be automatic ? https://patchwork.openembedded.org/patch/86479/ Sep 26 09:02:29 nayfe: I am working with Morty release of Freescale community BSP... this may be not exactly the same issue Sep 26 09:02:59 if you create just 2 or 3 partitions, those get to be primary Sep 26 09:06:42 nayfe: just out of curiosity, you are using SoMs or custom hardware? if SoMs, what vendor? I am using the i.MX6 DART from Variscite Sep 26 09:13:47 hello Sep 26 09:14:05 does anybody know what should I put in my local.conf to keep only the last built image ? I'm using krogoth; thanks Sep 26 09:14:48 indeed, for wic in poky it can be found here: https://git.yoctoproject.org/cgit.cgi/poky/tree/scripts/lib/wic/plugins/imager/direct.py there is a part l478 for extended partitions Sep 26 09:16:42 eduardas_m: but it does not seems to be in morty nor pyro Sep 26 09:17:23 its on pyro Sep 26 09:19:52 nayfe: thanks... somehow missed that Sep 26 09:20:10 actually trying to get my things to build on pyro right now Sep 26 09:20:28 have to fix lots of dependencies :( Sep 26 09:21:13 top22: maybe INHERIT += "rm_work" ? Sep 26 09:21:54 nayfe: I think that does not influence the deploy folder Sep 26 09:21:55 eduardas_m: btw custom hardware Sep 26 09:23:02 nayfe: very cool, but I expect that to be lots more work Sep 26 09:26:26 eduardas_m: indeed, but it is only on porting an existing old bsp to more recent Sep 26 09:31:24 nayfe: but that will erase all built packages and a subsequent build will take a lot Sep 26 09:33:44 top22: indeed, i missread you :/ i'm not sure it exists, maybe with toaster it can be feasable, or otherwise, a wrapper bash script to clean and build Sep 26 09:36:14 nayfe: found it; it's RM_OLD_IMAGE=1 Sep 26 09:36:36 nice :) Sep 26 09:59:59 nayfe: sorry for the delay. http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/log/?h=pyro Sep 26 10:03:01 maxin: No problem. That patches moves RDEPENDS https://lists.yoctoproject.org/pipermail/yocto/2017-September/037976.html and it does not seems to be applied regarding http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/tree/recipes-devtools/oracle-java/oracle-jse.inc?h=pyro Sep 26 10:04:50 nayfe: ok, will take care of it.. thanks :) Sep 26 10:05:52 maxin: thank you Sep 26 10:07:10 maxin: there is still the incorrect java link, i'll try to send a patch this afternoon, keep in touch Sep 26 10:47:14 RP: so, er - the pastebin with your tweaks to the binutils/gcc for flatpak SDK has expired - I was about to test them today :) Sep 26 10:48:45 ah I have the GCC one but not the binutils one Sep 26 10:49:41 how do I make a python () section only act on a certain machine type? Sep 26 10:58:24 ramcq: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip5&id=b0c39d3e72fc12a5c8cbdd9769c1baf1b6a5b23f Sep 26 10:59:34 ramcq: you can do an if d.getVar("MACHINE") == "foo": ? Sep 26 11:03:41 RP: awesome, thanks Sep 26 11:21:06 hi , is there a way to make two variable (like distro_features) to be conflicts with each of them , can not enable both of at the same time ? thanks Sep 26 11:21:47 is there a way to make two variable (like distro_features) to be conflicts with each other , can not enable both of them at the same time ? thanks Sep 26 11:30:34 rheagar: see distro_features_check class Sep 26 11:30:40 (and use of in oe-core) Sep 26 12:17:59 Hi everyone ! Newbie question: I have an SVN URL on my SCR_URI recipe. There is a space character on this url. How can i escape it ? I tried "svn://repo;module=foo\ bar" without sucess :/ Sep 26 12:20:59 %20 Sep 26 12:21:21 https://en.wikipedia.org/wiki/Percent-encoding Sep 26 12:21:23 how can I add my custom variable into myimage.bb and make it visible in other recipes ? Sep 26 12:22:43 Great, thank you phako[m] ! Sep 26 12:23:39 Dvorkin_: maybe with a new image_features ? Sep 26 12:31:30 nayfe, how can I add my own custom image_feature? Sep 26 12:38:42 Dvorkin_: you can't. variables in images are specific to the image recipe and nothing else. set it at the distro level Sep 26 12:44:02 Hi all, in a multilib build, how can I tell within a recipe when the package is being built for 32-bit or for 64-bit assuming both versions need to be built? I am trying to customise libdir and tried including ${baselib} and ${base_libdir} but they seem to always say lib64 even when building the 32-bit version. Sep 26 12:45:56 your recipe won't need to customise those as the multilib code will have done it already. if libdir is lib64 in a 32-bit build then you're either not actually doing a 32-bit build, or you configured multilib wrong. Sep 26 12:49:00 No, libdir is right, but I want to put my libs in a different location, /opt/test/lib or /opt/test/lib64 so I can have normal and test builds of the library available on the target Sep 26 12:49:51 The normal libs will be in /usr/lib or /usr/lib64 as usual and this is working fine Sep 26 12:50:31 just change the configure paths then Sep 26 12:51:40 not so simple, this is boost :) Sep 26 12:52:25 assuming the recipe pays attention to the system setings, you can try (in your local.conf) Sep 26 12:53:02 prefix_pn-boost = "/opt/test" Sep 26 12:53:14 (replace 'boost' with other name of recipe if trying this with something else) Sep 26 12:53:37 things that pay attention to the system settings willw ork, but there are a lot of recipes that 'assume' they know where to install everything Sep 26 12:54:14 ok, thanks Sep 26 12:54:32 and if you want the original and new boost at the same time, your 'new' one needs a different name.. Sep 26 12:54:53 so a simple 'mv boost_ver.bb boost-test_ver.bb' would do.. then the 'pn-boost' becomes 'pn-boost-test' Sep 26 12:55:01 yes, the new one has a new name, it is all working except in the multilib case Sep 26 12:55:23 changing the prefix should be all that is needed, unless the recipe ignores it Sep 26 12:55:35 (libdir and others are all set based on the value of prefix) Sep 26 12:55:49 only one way to find out... Sep 26 12:56:56 maxin: I don't understand that patch http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/commit/recipes-devtools?h=master-next&id=4eb10648f31539f95110852496b987db6f74df55 , do you have any idea of what the problem was ? Sep 26 12:57:29 Dvorkin_: what is your use case ? Sep 26 13:02:32 nayfe, I'm creating two images based on the same machine and same distro. they differ only in couple of configuration files for running programs Sep 26 13:04:13 nayfe, it's so pity that everything is done automatically in Yocto, but I just can't replace one or two files depending on image I'm building Sep 26 13:04:30 for that i use image_overlay.bbclass here http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134118.html Sep 26 13:07:36 or here it's clearer https://patchwork.openembedded.org/patch/138100/ Sep 26 13:07:39 nayfe, it's not obvious howto use this feature. could you point me out on example? Sep 26 13:09:27 nayfe, ah! it's done after packages are created and installed... Sep 26 13:11:12 for example make meta-X/recipes-images/images/image-one/rootfs/etc/profile then in image-one.bb add FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" inherit ... image_overlay OVERLAY_SRC_URI = "file://rootfs" OVERLAY_ROOT_DIRS = "rootfs" Sep 26 13:12:43 nayfe: or put the configuration files into a dedicate package (using bbappends to remove them from the packages they should be in) Sep 26 13:14:32 sure, but when you have a lot of different configuration files, having multiple dedicated bbappend files could be hard to maintain, don't you think ? Sep 26 13:16:47 rburton, but if I have the "default" files, adding the others with the same names into .bbappend recipe... I'll always have files from .bbappend. or do I have the way to add some specific .bbappend file into one image and not do it for another? Sep 26 13:17:58 so if you want to replace say /etc/cups.conf and /etc/bash.bashrc. use a bash bbappend to delete /etc/bash.bashrc and cups bbappend to delete /etc/cups.conf. then write a new recipe configuration-foo that ships those two files customised for 'foo'. Sep 26 13:18:32 you can make many configuration packages that are subtly different as required. Sep 26 13:18:35 or just use the overlay class Sep 26 13:18:42 note overlay class won't work if you want a package feed to work Sep 26 13:19:07 rburton, I need package feeds. Sep 26 13:19:31 so then you *need* to do it in a way that preserves packages as meaningful things. so you need to do what i suggested... Sep 26 13:20:16 rburton, but I don't understand how can I not to use that .bbappend file _by default_ and use it in some specific image Sep 26 13:20:22 you can't Sep 26 13:20:26 how can I switch it on/off? Sep 26 13:20:42 you'll always need a package that contains the configuration files Sep 26 13:20:52 have many, one for each variation Sep 26 13:20:58 I have that package. Sep 26 13:21:17 it provides virtual/xxx Sep 26 13:21:45 rburton, and it has different variants Sep 26 13:21:45 problem is that overlay files will fail QA if you dont remove them by bbappend, right ? Sep 26 13:21:58 nayfe, correct Sep 26 13:22:07 not QA, image generation as there will be many packages providing the same files Sep 26 13:22:33 ok Sep 26 13:22:57 rburton, but I can't switch between this several recipes that provides the same virtual package on image level Sep 26 13:23:23 you need more than one image Sep 26 13:23:40 I have at least two images Sep 26 13:23:41 image-foo.bb has IMAGE_INSTALL=configuration-foo Sep 26 13:23:50 image-bar has IMAGE_INSTALL=configuration-bar Sep 26 13:24:36 rburton, I have several images. they differ by it's packets. but that "configuration files" packet is the package, that provides functionality to others. And I can't easily switch Sep 26 13:25:11 there are several packets, that depending on the "configuration files" packet Sep 26 13:25:39 so they can all rprovide a common name so everything else, and the image can specify what precise one to install Sep 26 13:26:32 rburton, "configuration file" package provides and rprovides "virtual/xxx". Sep 26 13:27:04 other recipes require virtual/xxx Sep 26 13:27:31 but I can't select what exactly provides "virtual/xxx" on the image level Sep 26 13:27:53 what/who Sep 26 13:28:02 pretty sure just doing IMAGE_INSTALL+= the-real-package-name-you-want will work Sep 26 13:28:12 hmmm... Sep 26 13:28:40 let me try again. I made a lot of unsuccessfull attempts Sep 26 13:28:59 btw you don't need the PROVIDES, just RPROVIDES Sep 26 13:44:12 - nothing provides virtual/xxx Sep 26 13:44:25 (try to add '--allowerasing' to command line to replace conflicting packages) Sep 26 13:44:38 at the rootfs state Sep 26 13:45:15 Hey all... Am I missing a trick or is there a simple way to change the hashing algoritm used for passwd under Yocto? Sep 26 13:45:47 rburton, It can't find the other package if I did not set default name at distro Sep 26 13:59:25 can I remove a MACHINE_EXTRA_RDEPENDS dependency in my local.conf (Yocto Pyro)? Sep 26 14:28:37 maxin: I added following patch: https://lists.yoctoproject.org/pipermail/yocto/2017-September/038127.html if you want to have a look Sep 26 14:43:02 nayfe: in master-next now. thanks Sep 26 14:44:23 maxin: great! Sep 26 15:47:21 RP: I think there's a typo in your commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=592c3449697ce39bf07864fafd7f0a61ca230561 Sep 26 15:47:27 RP: "rockor" Sep 26 15:54:42 lucaceresoli: yes, thanks :( Sep 26 15:54:46 rburton: ^^^ Sep 26 15:56:28 lucaceresoli: rburton: I've push a fix Sep 26 15:57:47 whoops! Sep 26 16:14:26 are touchscreen controllers/drivers built as kernel modules from out-of-tree sources? Sep 26 16:15:29 i'm trying to find the driver producing "[3134822.816] (**) evdev: iMX6UL TouchScreen Controller: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200" and cannot find it anywhere in the src/linux of a "devtool modify -x my-kernel src/linux" Sep 26 16:24:59 is there a "devtool modify" option to extra the xorg code from a project? Sep 26 16:26:45 s/extra/extract/ Sep 26 17:45:53 Hi, Im looking into Ptest framework and was wondering how this chart got populated https://wiki.yoctoproject.org/wiki/Ptest_6964efddd31c479386d1643c1025bc102710392f If there was already script for this? Sep 26 17:49:20 rburton: alright now you got me thinking if we should enable ipv6 on DISTRO_FEATURES_NATIVE or simply enable it on python-native without looking at DISTRO_FEATURES_NATIVE at all Sep 26 18:06:54 Anyone know what this error is caused by or can point me in a direction. TRying to build yocto for an rpi. https://imgur.com/a/KWm3M Sep 26 18:15:53 i tested with morty and are building as i write Sep 26 18:50:03 macbug: you need meta-python from meta-openembedded repoi Sep 26 18:50:36 macbug: you can git clone git://github.com/openembedded/meta-openembedded -b morty Sep 26 18:51:13 then source your env script Sep 26 18:51:36 and then use bitbake-addlayers /meta-python Sep 26 19:33:41 rburton: hello Sep 26 19:34:11 rburton: i just checked and I was testing with the upgraded packages Sep 26 19:50:43 denix: I sent a patch to meta-ti to fix the linux-dtb.inc deprecation warning Sep 26 20:35:43 is there a list of "packages" i can build into my distribution? namely i'm looking for the editor named "zile" Sep 26 20:36:28 yates: the layer index. layers.openembedded.org Sep 26 20:36:44 anyone seen do_rootfs hang and become completely unresponsive? ps shows no child processes of bitbake-worker, just the worker itself sitting there doing nothing Sep 26 20:36:54 I have not Sep 26 20:37:03 RP, bluelightning? i'm sure richard is out by now, but for later Sep 26 20:37:06 hmm Sep 26 20:37:20 only started happening after i updated our layers to current upstream, quite odd Sep 26 20:37:30 * kergoth tries a different image Sep 26 20:38:15 We updated today to lastest oe-core/bitbake/meta-* (previously were were about 2 weeks old).. I havn't run many images on todays Sep 26 20:38:41 kergoth: can't recall seeing that here Sep 26 20:38:57 any clues in the log as to where it got up to? Sep 26 20:39:22 kergoth: not seen that... Sep 26 20:40:12 kergoth: master did have a completely green build for 2.4 rc1 Sep 26 21:10:29 RP: hey, so i got these warnings - I think maybe I need to add some replacements for ${TARGET_PREFIX} in to the binutils .bbappend, or I've messed up something - getVar needed a 2nd argument so I said False - did I want True in fact? Sep 26 21:10:40 https://pastebin.com/hHs74fPk Sep 26 21:11:00 * kergoth starts removing layers to isolate Sep 26 21:11:52 (oh, huh - gcov is a bug of our own addition ;)) Sep 26 21:43:16 ramcq: put a bb.warn("foo") into that if statement in the python() block and check its executing? Sep 26 21:43:52 ramcq: I tested against master and I don't see those issues :/ Sep 26 21:45:26 ramcq: ignore me, that block is only for gcc :/ Sep 26 21:46:24 ramcq: ah, note that mine is working on arm-linux, not your arm-unknown-linux Sep 26 21:46:43 ramcq: try a s/arm-linux/arm-unknown-linux/ on the bbappends Sep 26 21:53:35 * RP -> Zzzz Sep 27 02:55:05 2 weeks ago at the Open Source Summit I was wandering around the showcase floor and came across the WSL (was Bash-for-Windows) exhibit at the MS booth Sep 27 02:55:47 For fun I asked if I could try to build poky (to see if it would work since it was claiming to be Ubuntu 16.04 it might work!) Sep 27 02:56:03 It got a really long way with "bitbake -k core-image-minimal" Sep 27 02:56:23 Sadly it died on 2 systemcalls (one in m4 and another forking patch later on) Sep 27 02:57:06 Seems like it uncovered 2 likely kernel bugs in their Linux compatibility systemcall implementation. ;) Sep 27 02:57:57 Pity though. I was wondering whether runqemu was going to work... **** ENDING LOGGING AT Wed Sep 27 03:00:00 2017