**** BEGIN LOGGING AT Wed Jun 04 02:59:58 2014 Jun 04 08:54:00 morning all Jun 04 08:56:13 hi bluelightning Jun 04 09:08:24 morning and yay for first commit accepted \o/ Jun 04 09:08:37 hi afournier and gratz Jun 04 09:08:47 thanks woglinde Jun 04 09:09:17 * woglinde needs to push the perf packaging patches, but no time for testing Jun 04 09:52:21 syslinux was skipped: incompatible with host arm-angstrom-linux-gnueabi (not in COMPATIBLE_HOST) Jun 04 09:52:26 any idea how I can get past that? Jun 04 09:52:40 build for an x86 machine Jun 04 09:52:45 the previous guys hacked image.bbclass to make an vmdk Jun 04 09:52:46 this broke Jun 04 09:52:47 syslinux is an x86 bootloader Jun 04 09:52:52 lol syslinux on arm Jun 04 09:52:55 how doess one make an image that you can dd to a sdcard? Jun 04 09:52:57 thats funny Jun 04 09:53:07 take it slow bob Jun 04 09:53:22 :P Jun 04 09:53:30 pompomJuice overriding the stuff which initramfs does Jun 04 09:53:39 aeh image Jun 04 09:53:53 basically I said inherit boot-directdisk instead of inherit image Jun 04 09:53:59 yes Jun 04 09:54:05 bad move Jun 04 09:54:16 get familiar with bbappend Jun 04 09:54:26 uugh Jun 04 09:54:33 I did, il have to read them again Jun 04 09:54:37 include Jun 04 09:54:38 and do your own recpie Jun 04 09:54:39 inherit Jun 04 09:54:45 ok so is that the way Jun 04 09:54:59 bbappend image.bbclass Jun 04 09:55:04 then add something that makes an image Jun 04 09:55:07 custom built... Jun 04 09:55:13 that is the way to do it? Jun 04 09:55:46 I would have thought this is a problem that has been encountered before... surely I could just press a button and it must work? Jun 04 09:55:54 no? Jun 04 09:56:13 or oe does 99.99999% insane crazy work... leaves the last little easy peasy hurdle? Jun 04 09:56:13 people using uboots nand write stuff or so Jun 04 09:56:22 aah ok Jun 04 09:56:38 so it is inteded for the spesific device & storage implementation Jun 04 09:57:03 intel/yocto guys did for x86 Jun 04 09:57:10 aah I see Jun 04 09:57:14 but patches for other systems are welcome Jun 04 09:57:36 at least now I know there is no automagic make image button somehwere that I should press Jun 04 10:00:23 btw. you could look at the beagle bone black images which have autoinstall magic Jun 04 10:10:12 just as a general FYI? if I run the same build on my dev machine in two locations... will the PR manager clash somehow? I am getting strang builds... Jun 04 10:10:24 I migrated to 1.6 Jun 04 10:10:28 took me 2 days Jun 04 10:10:31 got an image out Jun 04 10:10:37 it had a coruppted root partition Jun 04 10:10:41 messed around some more Jun 04 10:10:45 days go by Jun 04 10:11:00 now everything (oe/angstrom) is being rebuilt Jun 04 10:11:20 things that should be built already since I had an image... Jun 04 10:12:35 almost while i was transitioning from 1.5 to 1.6 1.5's PR thing was still hosting and maybe I rand 2 builds side by side by mistake Jun 04 10:26:12 pompomJuice: you should not share PR servers between those two builds, no Jun 04 10:26:22 or rather, those two configurations Jun 04 10:26:28 they have the default Jun 04 10:26:33 127.0.0.1 Jun 04 10:26:41 so do they clash? Jun 04 10:27:04 since my first image was corrupted Jun 04 10:27:13 maybe cause it was sucking in packages or not at all from another build Jun 04 10:27:21 maybe I should just go read how that thing works Jun 04 10:28:22 sharing the PR server would not cause corruption unless you were additionally sharing the package feeds, but that is very unlikely Jun 04 10:29:01 ok Jun 04 10:29:15 unlikely since I don't know how to do it unlikely Jun 04 10:29:46 let met just see what happens... build is taking ages Jun 04 10:30:05 this time my image wight contain mono 3.6 with llvm back end Jun 04 10:30:08 I hope it works Jun 04 10:30:12 might* Jun 04 10:30:29 and yocto 1.6 Jun 04 10:30:34 bleeding edge Jun 04 10:30:38 just how I like it Jun 04 12:14:44 where should I expect to find the final kernel .config in my build tree? If I go into the workdir of my kernel, and into the "git" subfolder, the .config in there seems to be my defconfig, but not including any .cfg fragments I have applied. Where is the .config which actually goes into the kernel compilation? Jun 04 12:28:36 mago_: there should be a *-build directory under the workdir which contains the final .config Jun 04 12:30:39 anyone have any idea what the problem might be: Jun 04 12:30:40 satisfy_dependencies_for: Cannot satisfy the following dependencies for metergateway: Jun 04 12:30:40 * libllvm3.4-lto * Jun 04 12:31:02 what is that -lto? Jun 04 12:31:09 where does it come from? Jun 04 12:31:39 I have a package llvm-mono that provides llvm backend to mono... and then another program metergateway depends on mono... do_rootfs fails with that error Jun 04 12:35:23 bluelightning, hm, no. Seems to be no such directory. Although, I think actually the ${S}/.config file _is_ my final config. The problem seems to be the merging process. I debugged it a bit, and found that it runs ${S}/scripts/kconfig/merge_configs.sh -m .. the problem is that Xilinx also provides a "defconfig" as a .cfg, and unless it is specified FIRST in the list passed to merge_configs.sh, it is not treated as the "base". So Jun 04 12:35:24 what happens instead is that my smaller patches (that are suppose to override the defconfig.cfg) instead gets overridden by the defconfig Jun 04 12:36:38 so my problem is really with the code in the meta-xilinx layer, which uses a python function called src_patches() to get SRC_URI, and then extracts all files with an extension of .cfg. Is there anyway I can specify the order in which things shall appear in SRC_URI? Jun 04 12:36:39 mago_: that sounds like a bug to me Jun 04 12:37:09 well, the bug is perhaps that xilinx has put in their defconfig as a cfg. OR that i can't find a way to specify the order of SRC_URI reliably Jun 04 12:37:15 mago_: you can prepend instead of append to SRC_URI to add to the start instead of the end Jun 04 12:37:42 but logically the precedence order should be the other way around from what it appears to be Jun 04 12:37:57 is this definitely code in meta-xilinx as opposed to the core that is doing this? Jun 04 12:39:09 bluelightning, I just put my .cfg files into a variable called MACHINE_KCONFIG. The meta-xilinx layer then does SRC_URI_append. You can see this code here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-machine-config.inc (line 28) Jun 04 12:39:35 and then, the code that launches the "merge_config.sh" script is here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-machine-kconfig.inc (line 19) Jun 04 12:40:09 I'd take this up with them then; I'm not sure why all of this extra stuff is needed to be honest Jun 04 12:40:39 do you know if they are on IRC? Jun 04 12:41:18 i think it is needed because they don't use the Yocto kernel (yet).. perhaps this is a way to get support for cfg fragments without yocto kernel? Jun 04 12:42:29 if that's all that's needed, you can use the linux-yocto-custom example in meta-skeleton Jun 04 12:42:40 that supports config fragments without mandating the separate meta branch Jun 04 13:09:21 bluelightning, hm. weird. actually, it seems like the configs are sorted in reversed alphabetic order before passed to the "merge_config.sh" script. So if i name my cfg files anything that starts with a, b or c, it will come after "defconfig". This also explains why xilinx didn't notice, because in their own examples, they give it a file called 'common/rtc.cfg', which of course would be sorted after defconfig.cfg in this case. Another observation Jun 04 13:09:21 is this: it seems find_config_fragments() is invoked twice during the build, the first time it returns the configs in correct order, the next time, it is sorted. So perhaps some other recipe is sorting SRC_URI by mistake? Not sure if you are suppose to be able to count on SRC_URI being sorted in any particular way? Jun 04 13:13:57 mago_: you need an .scc to have full control Jun 04 13:14:09 .scc? Jun 04 13:14:46 see http://tinyurl.com/lshlagy Jun 04 13:16:27 ant_work: that's for linux-yocto though right? Jun 04 13:16:51 yes, config fragments are a yocto business Jun 04 13:17:15 perhaps i should try the xilinx yocto kernel instead. they seem to provide recipes for those aswell Jun 04 13:17:36 i wonder why they provide both a linux-xlnx and a linux-yocto Jun 04 13:18:00 that is a good question Jun 04 13:18:18 because linux-yocto is useless on zynq :) Jun 04 13:18:26 mago_, don't bother Jun 04 13:18:30 and they default to their own linux-xlnx, so i guess a lot of people will end up using it without knowing :) Jun 04 13:18:35 Crofton|work: why have it at all then? Jun 04 13:18:43 dunno Jun 04 13:18:49 politics Jun 04 13:18:53 Crofton|work, you xilinx guy? Jun 04 13:18:54 ask zediii Jun 04 13:18:56 no Jun 04 13:18:58 customer Jun 04 13:19:00 k Jun 04 13:19:14 I use linux-xlnx fine Jun 04 13:19:22 i think this sorting of MACHINE_KCONFIG is a bug, i should probably send an email to meta-xilinx list Jun 04 13:19:30 with a bbappend to add my kconfig and stuff Jun 04 13:19:50 they do some goofy things Jun 04 13:19:52 Crofton|work, so you don't use MACHINE_KCONFIG and xilinx "own" version of config fragments? Jun 04 13:20:48 I just append cfg and scc files to SRC_URI Jun 04 13:20:52 bluelightning: the recipe has its own .cfg merging Jun 04 13:21:05 ant_work: that was my point, yes Jun 04 13:21:17 insane duplicate work Jun 04 13:21:26 on the face of it I'd have to agree Jun 04 13:21:34 yep Jun 04 13:21:49 particularly in the face of linux-yocto-custom that doesn't force the separate meta branch on you Jun 04 13:22:20 their kernel isn;t close enough to mainline to make linux-yocto useful Jun 04 13:22:28 there were some really funnay attempts in the past Jun 04 13:22:40 Crofton|work: linux-yocto-custom doesn't force any of that - you just point it to your own source tree Jun 04 13:22:47 I now Jun 04 13:22:55 my original zynq bsp used that Jun 04 13:23:13 I am trying to avoid duping the manufacturer's work Jun 04 13:26:12 you get the cfg processing (and more) just by inheriting kernel-yocto Jun 04 13:26:54 but the preferred way is to include linux-yocto.inc Jun 04 13:28:36 the xilinx guys are in Oz, so it is hard to have semi-realtime talk with them Jun 04 18:08:25 Hello, anyone has ever seen a prserv.sqlite3 magically cleaned out? Jun 04 18:09:23 The bitbake-prserv was dead (nothing special in the log). I have restarted the process and now its database is empty Jun 04 18:09:25 :S **** ENDING LOGGING AT Thu Jun 05 02:59:58 2014