**** BEGIN LOGGING AT Thu Dec 22 03:00:00 2016 Dec 22 04:29:48 * kergoth kicks qemu Dec 22 04:31:26 qemu64 scoffs at kergoth and his failed attempt at assault. Dec 22 04:31:33 indeed. Dec 22 04:31:54 it's only a flesh wound Dec 22 04:32:11 "I'm not dead yet" Dec 22 04:33:10 go north. pick up axe. chop qemu. Dec 22 04:37:27 * paulg pauses to wonder if north means Kanuckistan. Dec 22 05:35:08 * moto-timo thinks north is Newcastle Dec 22 08:19:15 Good morning Dec 22 08:20:01 Do you know where could I find a more extensive list of this: https://www.yoctoproject.org/ecosystem/iot ? Dec 22 08:20:37 *examples of devices implemented with yocto project Dec 22 08:47:27 aV_V: basically wherever you can imagine and also where you can't :-D Dec 22 08:47:50 aV_V: Yocto is ubuquitous Dec 22 09:01:41 aV_V: I did this for example http://witekio.com/case-studies/nw-coffee-vending-machine/ Dec 22 09:03:45 Where did the poky/meta/recipes-qt go? Dec 22 09:03:53 mckoan: aha! That could be helpfull. I'm doing my final degree project, and I searching for related-work Dec 22 09:04:21 Googling isn't very helpful because it keeps referencing articles that point to the no-longer-existing location Dec 22 09:06:47 meta-qt4 Dec 22 09:07:44 deva: use git log before google, the commit which removed said where Dec 22 09:08:00 JaMa, The repo description says "Qt4 layer for supporting LSB Testing and Compliance" so I thought it was something to add on of qt Dec 22 09:08:22 hmm Dec 22 09:08:24 *on top of Dec 22 09:09:13 ... and there doesn't seem to be a meta-qt5 Dec 22 09:09:35 (Not that I specifically need that version I just find it a bit odd...) Dec 22 09:10:21 JaMa, Ther packages appear to be there Dec 22 09:10:30 in meta-qt4 that is Dec 22 09:10:45 So I guess it's just the repo description that is a bit misleading Dec 22 09:11:21 mckoan: hmm it's running on windows? Dec 22 09:11:25 this image http://witekio.com/wp-content/uploads/2016/05/NW-IHM-9100.png Dec 22 09:13:55 aV_V: Qt5 is a cross-platform library, that means that you can develop it on Windows but run on the final target board using Poky Linux Dec 22 09:14:29 haha I thought Dec 22 09:14:31 aV_V: you can develop the aplpication Dec 22 09:14:53 aV_V: the main problem with your research project is that nobody is required to tell you he's using poky/OE. Dec 22 09:15:22 LetoThe2nd: and may customers what to hide that Dec 22 09:15:30 s/may/many Dec 22 09:15:40 s/what/want Dec 22 09:15:41 aV_V: and to be academically correct, nothing is running "yocto", as yocto is just the umbrella project. Dec 22 09:15:45 mckoan: exactly. Dec 22 09:16:56 LetoThe2nd: customers are proud to say they are using WindowsCE but shy to say they are using Linux Dec 22 09:17:35 mckoan: it depends on the business area, but there are some where that certainly applies, yes. Dec 22 09:33:26 is there a way to include a 'inherit class' in the image types definition file when defining a new image file? Dec 22 09:33:35 so that the functionality of the class is used for the image generation? Dec 22 14:28:30 hi ... I tried to update doxygen to some later version and switched to github and cmake instead of the "old" way of working so basically the recipe is simple as http://pastebin.com/uGfDxp0X Dec 22 14:29:18 the recipe "works" if I just build an SDK including nativesdk-doxygen ... but I get an error if i do bitbake doxygen-native Dec 22 14:45:37 ... seems like bitbake mess up a bit with host tools ... strange I can build it on my host with plain cmake? Dec 22 15:38:56 hello guys, could somebody advice me how to enable mysqlclient in the qtbase package? Dec 22 15:41:19 Hi, I'm having a weird issue during the do_configure step of a recipe. The command in configure.ac is $PKG_CONFIG --variable=includedir Qt5Core. I've verified that $PKG_CONFIG is correct, ie: ../build/tmp/sysroots/x86_64-linux/usr/bin/pkg-config, however it returns /usr/include/qt5/QtGui/5.7.0/QtGui instead of ../build/tmp/sysroots/x86_64-linux/usr/include/qt5 Dec 22 15:42:10 Howver, when I run the command myself, it returns the correct value... and I've checked that the Qt5Core.pc file is correct as well Dec 22 15:57:08 Hi all, newbie to Yocto here. I've succesfully managed to create a rootfs using a custom image type (which is now currently the same as a standard tar archive). What I would like to do now is to create a tar archive by copying the rootfs into a folder with some flashing tools, and then TARring everything. However, I don't know where to put these files so that I can copy the rootfs there. Does any of you know how to do that? Dec 22 16:13:57 Croj, hello, not sure why you are trying to do that... did you make the custom image for some board? if so why doing an sdcard image write to sd card does not work for you? Dec 22 16:15:58 I'm not writing on an SD card but rather flashing a device in recovery mode, only thing is that I'm building the rootfs on a server, then I have another folder on my PC where i copy the rootfs and then using a script I flash the board Dec 22 16:16:38 I just wanted to bundle the flashing tools together, so that when I download the archive I don't have to have a specific folder where to unpack it Dec 22 16:17:05 I.e. I build the rootfs, bundle it with the flashing tools and then download it to my pc Dec 22 16:19:48 Croj, just out of curiosity: would you mind sharing what kind of board and flashing tool you are using? Dec 22 16:21:15 the only one I have worked with is mfgtool for imx chips Dec 22 16:22:34 I suspect your script or tool allows to write NAND or eMMC on board directly, no? Dec 22 16:22:45 yup Dec 22 16:22:52 I'm working on an NVIDIA Jetson TK1 Dec 22 16:23:12 so I have the flash tools provided by nvidia, where I have a flash.sh script and a rootfs subfolder Dec 22 16:23:32 the flash script basically writes whatever is in the rootfs subfolder to the eMMC Dec 22 16:24:07 Now I'm manually copying the generated tar rootfs to that subfolder, which works, I just wanted to see if I could automate this step as well Dec 22 16:28:08 Croj, and your point is that you no longer want to copy the rootfs.tar.bz from deploy/images to some other folder manually? Dec 22 16:28:33 do you have to extract before you can use the flash script? Dec 22 16:28:53 Yeah, it's mostly an experiment I wanted to make with Yocto, to learn something new. Yes I would need to extract Dec 22 16:30:07 What I saw from the standard tar command is that there is a ${IMAGE_ROOTFS} variable which points to the unpacked rootfs, I would just need to create an archive where its contents are inside another folder with the flash script Dec 22 16:30:13 Croj, so I guess you want to have the whole process to be tied into some bitbake command, no? so that you can deploy as soon as your new rootfs is done, no? Dec 22 16:30:18 yeah Dec 22 16:30:25 What I did was to create a new bbclass Dec 22 16:30:46 nvidia_flash.bbclass, inherit from image_types, and add that to IMAGE_FSTYPES Dec 22 16:30:55 this makes bitbake pick it up, which is good Dec 22 16:31:22 not sure i'd bother making it an image type, just add a new task after deploy that unpacks in the right place Dec 22 16:31:56 Ok, makes sense, I didn't know where to start so I thought that the image type was an option Dec 22 16:32:08 How would I add this new task? Dec 22 16:32:35 addtask unpackthedeploy after do_deploy Dec 22 16:32:53 then make that find the right tarball in deploydir, and unpack it in the right place Dec 22 16:33:03 then bitbake myimage -c unpackthedeploy Dec 22 16:33:10 to build and unpack Dec 22 16:34:06 Ok, my issue (also with the previous step) is: how do i find the "right" place? Dec 22 16:34:34 I mean: I have a meta-deploy dir where I have this nvidia_flash.bbclass Dec 22 16:34:47 I was thinking of adding another folder with the flashing tools Dec 22 16:34:54 but these would be in the sources directory, not in the build tree Dec 22 16:37:17 I'm trying now to make the task Dec 22 19:41:04 I'm having trouble getting a config fragment from my bbappend to override a config item in defconfig from the original recipe in another layer. Dec 22 19:41:23 most kernel recipes don't support fragments at all, so keep that in mind Dec 22 19:43:01 i see, what is the best method for disabling 1 kernel config item. I could copy the whole defconfig, make my change and then prepend FILESEXTRAPATHS to use my defconfig Dec 22 19:43:15 but is there another way? Dec 22 19:44:30 only if the kernel supports fragments or you want to fix the recipe to support fragments Dec 22 19:45:04 I have to admit I thought config fragments were available in every recipe inheriting kernel.bbclass ... ? Dec 22 19:46:57 Ok, how can i fix the recipe? Or should I refer to the manual? Dec 22 19:50:14 bluelightning: nope. it's a linux-yocto specific feature that only certain kernel recipes have adopted. also, there's no standard mechanism by which the defconfig is written to .config. some recipes use the fallback ${WORKDIR}/defconfig -> ${B}/.config which is done by do_configure, but only some Dec 22 19:50:22 bluelightning: there's an open yocto bug to improve the situation Dec 22 19:50:34 s/it's a/it was a/ Dec 22 19:51:21 mentor bbappends the kernel of each bsp we support to make it support fragments, but it's case-by-case. in at least one of them i had to modify one or more functions with setVar() in anonymous python to inject it in the right spot Dec 22 19:52:58 I stand corrected Dec 22 19:53:36 it's a bit of a mess, but i'm sure it'll be improved Dec 22 19:53:54 I hope so Dec 22 19:58:29 Could you point me to an example of a bbappends that makes a kernel recipe support fragments. please and thank you Dec 22 20:01:29 as i said, the details vary depending on the recipe, but basically you depend on kern-tools-native and, at an appropriate point (after defconfig is written to .config) run merge-configs.sh against the fragment files in WORKDIR. merge_config.sh -m .config ${@' '.join(s for s in src_patches(d, True) if s.endswith('.cfg'))} Dec 22 20:02:24 the most common case would be doing a do_configure_prepend() which does a cp -a ${WORKDIR}/defconfig .config, then the merge_config.sh Dec 22 20:02:50 you'll want to examine the kernel recipe you're appending and verify the merge worked, of course Dec 22 20:03:43 so the bare minimum: DEPENDS += "kern-tools-native"; do_configure_prepend () { cp -a ${WORKDIR}/defconfig .config; merge_config.sh -m .config ${@' '.join(s for s in src_patches(d, True) if s.endswith('.cfg'))}; }; Dec 22 20:03:48 untested, but that's the idea Dec 22 20:07:53 wouldn't it be easier to use linux-yocto.inc ? Dec 22 20:12:35 does that even work if you're using an upstream kernel? kernel-yocto is full of yocto-specific cruft, as far as i can see Dec 22 20:13:52 not for a looong time. Dec 22 20:14:02 it just works everywhere. Dec 22 20:14:07 * zeddii_home goes back into vacation mode Dec 22 20:14:10 despite adding like 5 useless tasks to the build? Dec 22 20:14:33 ok. clearly I’m not going to debate with you on this Dec 22 20:14:41 nice phrasing Dec 22 20:14:44 useless. Dec 22 20:14:45 heh Dec 22 20:14:50 useless to anyone without a yocto kernel setup, yes Dec 22 20:15:03 like bitbake Dec 22 20:15:04 :D Dec 22 20:15:25 it gathers meta data, and then concats them, and then audits. Dec 22 20:16:45 which is a whole lot of nothing but overhead for anyone but linux-yocto Dec 22 20:16:59 * zeddii_home shrugs Dec 22 20:17:01 i'm glad if it actually works now, that's a plus Dec 22 20:17:54 might have to try it again, in that case. at the very least i can ascertain how much we could add a flag to disable Dec 22 21:20:22 kergoth: you definitely can use linux-yocto-custom from meta-skeleton with any kernel tree, that's been true for many releases now - and that uses linux-yocto.inc Dec 22 21:57:36 how does one untar a rootfs.tar.gz so that the perms are correct for "wic create" with -r flag? Dec 22 21:58:45 I started with fakeroot. Now I am using pseudo from the native sysroot. Dec 22 21:59:30 running inside pseudo so tar can think it is setting perms that wic can then read seems sensible Dec 22 21:59:32 The fs won't mount unless I sudo chown root:root on the SD card Dec 22 22:02:10 maybe the root directory itself has wrong perms. I don't use pseudo for mkdir before un-tar Dec 22 22:04:59 you should be able to chown under sudo if you need to Dec 22 22:05:09 er Dec 22 22:05:10 pseudo Dec 22 22:05:12 gah Dec 22 22:24:21 kergoth: thanks for the help. what you suggested worked Dec 22 22:24:39 bluelightning: good to know, thanks for hte info Dec 22 22:24:44 Nerbrun: cool, glad to hear it. no problem Dec 22 22:44:23 my only complaint is that it seem necessary to clean the kernel to realize a change in the config fragments.. but not a bit deal Dec 22 22:45:40 i guess if I include the files in the recipe, bitbake should detect this? Dec 23 00:43:47 Nerbrun: that shouldn't be necessary, if they are referred to in SRC_URI that sounds like a bug - it should notice the changes and rebuild the next time Dec 23 00:44:12 oh, you're not including those? yeah, you really do want to be pulling them in via SRC_URI **** ENDING LOGGING AT Fri Dec 23 03:00:00 2016