**** BEGIN LOGGING AT Thu Jun 04 02:59:59 2015 Jun 04 05:07:30 what's the env variable that holds the location of file:// in a recipe? Jun 04 05:47:12 hi Jun 04 05:47:22 recently I had added few things to the rootfs Jun 04 05:47:49 and now at the time of linux boot up I am getting Jun 04 05:47:51 Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. Jun 04 05:47:55 any help Jun 04 05:48:04 does it something to do with the rootfs size ? Jun 04 05:48:21 which is been modified after I have packaged extra things Jun 04 06:05:01 niteshnarayanlal, normally not, though if you're using initramfs there might be an issue. Jun 04 06:05:18 niteshnarayanlal, it's more likely that something else has screwed up. Jun 04 06:05:41 Do you have any init in you're rootfs? Jun 04 06:24:38 how do I specify git cloning https repo in my recipe? Jun 04 06:51:00 good morning Jun 04 07:18:38 good morning guys Jun 04 08:06:39 morning all Jun 04 08:59:29 morning Jun 04 09:00:57 I have a major problem, which perhaps some of you know how to deal with. Im trying to build my own custom image based on the arago distro, but as I compile some QT5 packages I get a linker error: x86_64-arago-linux-g++: error: unrecognized command line option '-fuse-ld=gold' . Anyone know how I can resolve this Jun 04 09:12:26 arago for an x86 platform ? Jun 04 09:12:32 what a weird choice :) Jun 04 09:22:23 araldit: I'd assume the toolchain has been built without support for the gold linker Jun 04 09:23:20 I honestly dont know - im digging into that right now Jun 04 09:23:27 araldit: depending on what you want to do, you could either enable it, or find how that -fuse-ld=gold is getting into the compiler command line and stop it Jun 04 09:24:33 or... hmm, could it be that the version of gcc being used simply doesn't support -fuse-ld ? Jun 04 09:24:48 bluelightning: It could be that. Jun 04 09:25:01 bluelightning: Im using 4.7 Jun 04 09:25:02 https://bugreports.qt.io/browse/QTBUG-28598 Jun 04 09:25:20 granted that was qt4, but still Jun 04 09:27:56 bluelightning: Im currently trying to remove the gold linker through in my image.bb file by adding LDGOLD = "" and DISTRO_FEATURES_remove = " ld-is-gold" Jun 04 09:28:16 araldit: that's not going to work Jun 04 09:28:29 bluelightning: why is that? Jun 04 09:29:05 I mean im bulding the sdk by usiing bitbake image -c populate_sdk Jun 04 09:29:06 araldit: the first problem is that you cannot set a variable read in one recipe or read at the global level from within another recipe Jun 04 09:30:10 if you want to remove ld-is-gold from DISTRO_FEATURES you will need to do so at the configuration level Jun 04 09:30:21 bluelightning: I did this because i found this line in binutils: oe-core/meta/recipes-devtools/binutils/binutils.inc:LDGOLD ?= "${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default --enable-threads', '', d)}" Jun 04 09:30:36 right, I get that Jun 04 09:30:57 bluelightning: Ok, what do you mean by at the configuration level Jun 04 09:31:00 but then there's the question of whether that will actually result in -fuse-ld=gold not being passed to the compiler in the qt build, I can't immediately tell if this will actually influence that Jun 04 09:31:32 I can - It didn't work :-) Jun 04 09:32:00 araldit: effectively I mean in local.conf, although when you are changing things like this you should consider whether it would be better to create your own distro config Jun 04 09:32:10 araldit: ok, well I guess it's an academic point then Jun 04 09:33:08 araldit: I think you'd need to patch the Qt source as hinted by that Qt bug I linked above Jun 04 09:33:41 assuming that -fuse-ld=gold is coming in from the Qt build process itself as it appears to be there Jun 04 09:33:42 bluelightning: K, thanks for the advise. I will try to do that. Jun 04 09:53:12 How can I expand upon a .bbappend defined in one layer X from another layer Y? Jun 04 10:24:58 skfax: all bbappends should get applied, in layer priority order. Does that answer the question? Jun 04 10:26:12 jku: yes. i guess i've just made some mistake when naming the new bbappend files or something Jun 04 10:27:10 skfax: bitbake -e is your friend in this situation Jun 04 10:27:39 rburton: i tried it for the image i'm building now; but the file is massive Jun 04 10:28:41 doing some searching now to see if i can figure it out :) Jun 04 10:29:02 skfax: you can also try bitbake-layers show-appends Jun 04 10:30:10 well the "-e" gave me 21k lines. this option gave me 71. easier :D Jun 04 10:30:25 if your bbappend isn't listed there, either it's not matched by BBFILES in your layer's layer.conf (in wrong location or BBFILES isn't set up to match .bbappend files); or the layer itself isn't actually enabled Jun 04 10:31:38 it is listed, but there is a warning showing which might be relevant: "WARNING: linux-xlnx_3.14.bb: missing append for preferred version" Jun 04 10:32:22 ah right, yes Jun 04 10:33:41 does the "show-appends" command show all bbappend files found within the active layers? or does it show all bbappend files which successfully match an available recipe? Jun 04 10:35:36 sorry, i misread the file. yes it does the latter Jun 04 10:51:58 JaMa: thanks for updating meta-qt5 to match 4.5.x. Did you test this against a certain platform? Jun 04 10:52:54 likewise: qemux86(-64) and couple ARM devices Jun 04 10:54:38 JaMa: Did you test the QtWebEngine? I have trouble getting it to work on i.MX6. Jun 04 10:55:08 not much, we haven't integrated it fully yet Jun 04 10:56:23 JaMa: There is this bugfix, that is now in the 5.5 branch, but I'm not sure if it applied to the 5.4.x branch: https://bugreports.qt.io/browse/QTBUG-45122 Jun 04 10:58:02 JaMa: Also, in the qtbase.inc I had to add "-qpa eglfs" to the PACKAGECONFIG[gles2] entry in order to use the new QPA EGLFS. Otherwise it would fall back to xcb, which however I didn't have. (removed x11 and wayland DISTRO_FEATURES). Jun 04 10:59:29 tru I should probably revisit qpa in PACKAGECONFIGs, we're using: Jun 04 10:59:30 meta-luneui/recipes-qt/qt5/qtbase_git.bbappend:EXTRA_OECONF += "-qpa wayland-egl" Jun 04 10:59:52 hi Jun 04 11:00:19 what to do if I need an external toolchain to build packages for my platform? Jun 04 11:01:03 it consist of libc, gcc, binutils, gdb.. Jun 04 11:01:55 JaMa: are you testing on i.MX6 as well? Jun 04 11:02:43 ryoshu: Look for bitbake meta-toolchain and variants Jun 04 11:04:25 no Jun 04 11:05:04 likewise: thanks! Jun 04 11:07:20 JaMa: ok, thanks. I will build master first, see where that gets me, then also build against the 5.4.x update. Jun 04 11:27:28 ryoshu, also look at bitbake -c populate_sdk image-name Jun 04 11:27:52 hmm, but qt stuff has dedicated toolchain recipes also Jun 04 11:28:21 thank you, my task is to add new armv8 bsp and put it onto the website, I need your assistance Jun 04 11:28:37 today are holidays but I will go to my work and check your tips :) Jun 04 11:32:09 ryoshu: nice, what metal are you targeting? Jun 04 11:32:38 Cavium ThunderX Jun 04 11:34:07 I have my 3.10 kernel, my toolchain Jun 04 12:06:50 I'm trying to use a .bbappend file to add a .cfg file to FILESEXTRAPATHS. Using "bitbake-layers show-appends" I can see that my .bbappends file is found. However I'm not getting the end result I want. How can I know if the .cfg file is taken into account when building? Jun 04 12:07:07 Also; are .cfg files reserved for kernel configuration in yocto? Jun 04 12:55:39 skfax: .cfg files are interpreted as config fragments in the context of kernel recipes that use linux-yocto.inc, yes Jun 04 12:57:04 skfax: if the kernel recipe doesn't "require recipes-kernel/linux/linux-yocto.inc" (or perhaps indirectly via inherit kernel-yocto) then I'm fairly sure .cfg files won't be acted upon Jun 04 12:59:57 bluelightning: when i use "bitbake -s" both linux-netmodule-zx3, linux-xlnx and linux-yocto are listed. I'm not really understanding how they are connected Jun 04 13:00:22 bluelightning: But I've been appending to the linux-xlnx recipe: maybe I need to try to append to linux-yocto instead Jun 04 13:00:58 skfax: in almost all instances, the one that will actually be used to provide the system kernel will be the one selected as PREFERRED_PROVIDER_virtual/kernel Jun 04 13:01:38 it is not unusual to have multiple available kernel recipes in the metadata, but only one should actually end up being built for a given machine Jun 04 13:02:21 bluelightning: In what cases it won't be PREFERRED_PROVIDER_virtual/kernel? Jun 04 13:02:48 bluelightning: When I use "bitbake -e " I can find: PREFERRED_PROVIDER_virtual/kernel="linux-xlnx" Jun 04 13:04:07 joseppc: well, our metadata is flexible, if you removed references to virtual/kernel everywhere then it wouldn't be used... Jun 04 13:04:38 skfax: right, so linux-xlnx would be the kernel recipe being used in your current configuration Jun 04 13:05:12 bluelightning: I'm not sure if linux-xlnx is based on linux-yocto though. So if using linux-yocto is needed to use configuration fragments then that might explain why it is not working Jun 04 13:05:40 skfax: it doesn't have to be the actual linux-yocto recipe, it just has to make use of linux-yocto.inc Jun 04 13:06:41 I'm looking at linux-xlnx.inc now, and it has "inherit kernel", "require linux-machine-common.inc" and "require linux-machine-kconfig.inc". No direct mention of "linux-yocto.inc" Jun 04 13:07:18 (the linux-xlnx_3.14.bb file only includes the linux-xlnx.inc file + adds some version info) Jun 04 13:08:09 I guess I can go for a "defconfig" approach instead and just keep the entire configuration in one file in my layer Jun 04 13:09:00 bluelightning: ok, I asked because a friend recently had a problem where _virtual/kernel did not work, but using _yocto-kernel did. I never quire understood what was caused that Jun 04 13:11:10 joseppc: I'd probably need more contextual information to give a proper answer; it could simply be that the desired setting of PREFERRED_PROVIDER_virtual/kernel was being overridden Jun 04 13:11:55 skfax: right, the other option would be to add the require of linux-yocto.inc Jun 04 13:12:12 you can do that from your bbappend FYI Jun 04 13:14:24 bluelightning: And that will likely not break something? Jun 04 13:15:08 it should be OK as long as the kernel recipe and the other inc files aren't doing anything that would conflict with it Jun 04 13:15:18 ok cool will try it Jun 04 13:17:36 bluelightning: yeah, I did not have the time to investigate it further either. He set PREFERRED_PROVIDER_virtual/kernel in his local.conf, iirc Jun 04 13:19:17 joseppc: right, then it's possible that PREFERRED_PROVIDER_virtual/kernel was being set to some other value either later on (e.g in a machine or distro config file) or with an override, the result being that the local.conf value wasn't taking effect Jun 04 13:19:43 joseppc: FYI you can always see when that kind of thing is happening by looking at the output of bitbake -e - you get a full history of how each variable has been set Jun 04 13:24:18 bluelightning: I rechecked, I did not remember it correctly. It seems the problem was with PREFERRED_VERSION_virtual/kernel. The provider and version looked correct with bitbake -e. Jun 04 13:24:22 bluelightning: Anyway, I think it must have been a configuration problem from his part Jun 04 13:27:58 joseppc: well, let's deal with it when it next comes up :) Jun 04 13:29:43 bluelightning: When I do "bitbake -s " I find "linux-xlnx" listed. When I do "bitbake-layers show-appends" I find that both "linux-xlnx_3.14.bb" and "linux-xlnx_3.10.bb" is being appended to. However I cannot seem to find any of the assignments done in these bbappend files when using "bitbake -e ". Is the full history shown with -e ? Jun 04 14:33:44 I need to build u-boot and kernel for beagle board..version C3. May I know any yocto env porting guide? Jun 04 14:33:48 also, I need to have QT 4.8 Jun 04 14:50:13 kanupatar: there's a beagleboard BSP Jun 04 14:50:36 rburton: i need to build the bsp using yocto env Jun 04 14:50:50 rburton: git://git.yoctoproject.org/meta-yocto -b daisy ? Jun 04 14:51:08 that's a basic BSP, meta-ti has a better one Jun 04 14:51:18 well, different. Jun 04 14:51:37 beaglebone-daisy-11.0.0.tar.bz2 ? Jun 04 14:51:45 I have bb C3 Jun 04 14:51:47 kanupatar: and probably branch 'dizzy' would be better option Jun 04 14:52:10 git://git.yoctoproject.org/meta-yocto -b dizzy? Jun 04 14:52:14 mckoan: ? Jun 04 14:53:43 kanupatar: yes Jun 04 14:53:45 mckoan: rburton then how can I start building it? any build procedures? Jun 04 14:54:03 I have beagle board C3 Jun 04 14:54:11 Also, I need QT 4.8 Jun 04 14:54:16 kanupatar: this may be a good starting point http://www.embarcados.com.br/beaglebone-black-yocto-dizzy-versao-1-7/ Jun 04 14:55:39 mckoan: not english? Jun 04 14:56:25 kanupatar: the important parts are the commands :-D Jun 04 14:56:47 mckoan: okay.. what are all commands I need to follow for baegle? Jun 04 14:56:59 mckoan: it is generic isn't it Jun 04 14:57:21 I want to upload my 3.10 kernel to your repositories Jun 04 14:57:38 mckoan: sorry, yes it is beagle board specific Jun 04 14:57:52 kanupatar: http://android.serverbox.ch/?p=1273 Jun 04 14:57:55 and have there a branch for my hardware Jun 04 14:58:00 what's the proper procedure Jun 04 14:58:54 mckoan: thanks...shoudld it include QT package also? Jun 04 14:59:07 I need to build QT 4.8 for beagle c3 Jun 04 14:59:12 kanupatar: no, but start with a minimal image Jun 04 14:59:22 mckoan: OK ok Jun 04 14:59:34 mckoan: so for QT, just add it in script? Jun 04 14:59:57 ryoshu: the typical way to do this is to create a BSP layer for your hardware and push that as a git repository somewhere Jun 04 15:00:36 bluelightning: aha Jun 04 15:00:53 and ask for merge? Jun 04 15:01:02 kanupatar: Qt4.8 should be traightforward: bitbake qt4e-demo-image Jun 04 15:01:33 s/traightforward/straightforward Jun 04 15:01:38 mckoan: thanks Jun 04 15:01:40 its okay Jun 04 15:01:46 can I open hob and build? Jun 04 15:02:00 ryoshu: for additional machines, the idea is that you (or at least someone with interest in support for the machine) maintains the BSP layer rather than it being part of a central repository of support for multiple machines Jun 04 15:02:17 kanupatar: gosh! I don't like HOB, use command line Jun 04 15:03:39 mckoan: okay okay. Jun 04 15:04:09 mckoan: I need to learn git thoroughly, means it is building flow, customisation for different build etc Jun 04 15:04:16 sorry, yocto Jun 04 15:04:59 bitbake qt4e-demo-image --> what is the exact meaning ? mckoan ? Jun 04 15:05:09 also, I would like to have wayland Jun 04 15:05:45 qt4e-demo-image --> is the qt lib build or for entire kernel build? Jun 04 15:06:19 kanupatar: Qt4 don't support wayland Jun 04 15:06:38 kanupatar: I'd suggest you to study a bit how Yocto works Jun 04 15:06:45 mckoan: yes yes Jun 04 15:06:49 mckoan: from scratch Jun 04 15:07:04 mckoan:so I can learn from the beagle board exercise Jun 04 15:07:04 http://www.yoctoproject.org/docs/1.7.2/dev-manual/dev-manual.html Jun 04 15:07:46 mckoan: then QT5 wayland build? Jun 04 15:08:02 mckoan: thanks, I will go through the link completely Jun 04 15:08:22 * kanupatar interested to become a contributor for ycoto project..can start as a tester Jun 04 15:08:33 * kanupatar would like to become an intern under mckoan :) Jun 04 15:09:07 bluelightning: I see Jun 04 15:09:18 bluelightning: thanks Jun 04 15:10:31 ryoshu: it may be worth noting, once you have created your layer, we can provide hosting for it on git.yoctoproject.org in its own repository, or alternatively you can set up a repo on github or similar Jun 04 15:10:59 ryoshu: once it's publicly available it can be added to the openembedded layer index at http://layers.openembedded.org Jun 04 15:11:09 which will make it easy for others to find Jun 04 15:11:44 I will try to see how is done for Cavium Octeon Jun 04 15:12:28 bluelightning: I will resume it today and be at IRC, today are holidays in .pl :) Jun 04 15:12:41 I mean resume it tomorrow! :) Jun 04 15:12:45 ryoshu: ok, enjoy your holiday :) Jun 04 15:24:12 mckoan: how can I build QT 5.3. with wayland for bb C3? Jun 04 17:59:29 is there some docs on how to use BUILD_IMAGES_FROM_FEEDS Jun 04 19:12:18 layer-a/conf/machine/x.conf is being picked instead of layer-b/conf/machine/x.conf even when layer-b has a higher priority than layer-a Jun 04 19:12:31 if i remove x.conf from layer-a; x.conf from layer-b is found Jun 04 19:30:10 When a variable is being "set?" from two different configuration files; why is the configuration file from the layer with the lower priority chosen? Jun 04 21:20:23 hi Jun 04 21:20:56 little question, when i try to bitbake, i get some "Could not include ***-extraconf.inc Jun 04 21:22:18 i don't see any difference with other recipes where the last line is require ***-extraconf.inc Jun 04 21:23:17 what do i have to do to correct these errors? Jun 04 21:44:07 can't they be ignored or created at bake time? Jun 04 21:53:43 cazze: I'm not sure what you're asking, but if you use "require ..." , the file must exist Jun 04 22:30:10 bluelightning: ok, i did a touch and it was ok. File was not in the git tree :-( Jun 04 22:51:50 Is it possible to distribute the generated SDK using something like Debian packages instead of a single shell script installed? Specifically I'd like a better way of distributing minor updates to a specific library in a cleaner way then shipping out a new .sh file or sending out replacement files. **** ENDING LOGGING AT Fri Jun 05 02:59:59 2015