**** BEGIN LOGGING AT Fri Apr 01 02:59:58 2016 Apr 01 10:38:36 1st april jokes should not be spoiled so early. Apr 01 11:45:02 RP: ping Apr 01 12:27:54 Net147: pong Apr 01 12:31:46 RP: any comments on the latest gdb cross patches? Apr 01 12:36:07 RP: from the previous version, only the gdb-cross patch was applied out of the 2 patches. it now conflicts with the latest patch. Apr 01 12:38:32 Net147: I need to revisit that... Apr 01 12:44:10 RP: ideally would like the previous gdb-cross patch reverted so that both of the latest patches can be tested and integrated. Apr 01 12:44:37 RP: if you agree with the approach Apr 01 12:52:46 Net147: to be honest I preferred the original patches, I think the newer ones just confuse things more Apr 01 13:00:16 Net147: I have a suspicion the problem which the autobuilder ran into may be fixed by http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip&id=02c2d3c58fd4dd79a01be4c0b9e7900018a90671 Apr 01 13:11:12 RP: okay. let me know if you need anything else. Apr 01 13:14:56 Net147: well, I really need someone to test/confirm the above and check I haven't missed some corner cases. I can and will try to do it myself but no promises on when as I've a ton of other people's patches to try and make work :( Apr 01 13:22:09 RP: well checking against gdb-cross-canadian recipe, it doesn't look like that change will affect it Apr 01 13:22:25 RP: gdb-cross-canadian PN doesn't start with nativesdk- or end with -native Apr 01 13:31:36 Net147: hmm, you're right. It is nativesdk but doesn't match those checks. The problem is coming from that code though :/ Apr 01 13:37:13 Net147: perhaps more like http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip&id=51ded0383631157649702d3906a7842234ef46a7 Apr 01 13:40:06 RP: maybe... Apr 01 13:41:06 Net147: it doesn't appear to change the stamps for my existing build which is a good sign Apr 01 13:42:32 Net147: it appears packageconfig in cross-canadian recipes has never worked properly... Apr 01 13:43:36 RP: what's the command to check for stamp changes? Apr 01 13:46:59 Net147: existing build, apply patch, "bitbake something" and it didn't rebuild is the easiest Apr 01 13:47:46 RP: isn't there some command to diff the stamps or something... Apr 01 13:48:04 Net147: there is bitbake -S none too Apr 01 13:48:06 or printdiff Apr 01 17:46:02 if I get an error during fetch, how do i locate the file which specifies the particular version to fetch? Apr 01 17:59:27 davis: not sure what you mean. when a task fails, it gives you the path to the recipe Apr 01 17:59:31 so it's already there, in the log Apr 01 18:03:53 yes, i'm looking many thanks Apr 01 19:56:28 jfk, where does linux-yocto-custom hide the source it build in work???? Apr 01 20:27:44 I am digging into the various recipes to try and learn the structure of what builds an image. I noticed that in core-image-minimal.bb, "packagegroup-core-boot" is installed in the image. I don't understand why this is necessary since the image inherits core-image and core-image has Apr 01 20:28:05 "CORE_IMAGE_INSTALL = packagegroup-core-boot" Apr 01 20:28:17 Isn't that repetitive? Apr 01 20:33:50 What version of OE are you using? I only see 'packagegroup-core-boot' being added to CORE_IMAGE_BASE_INSTALL, which IIRC is just a variable that other images can choose to reference in their IMAGE_INSTALLs (and the default if they don't provide an IMAGE_INSTALL). Apr 01 20:34:29 jethro Apr 01 20:35:41 Oh, so CORE_IMAGE_BASE_INSTALL doesnt automatically include it? Apr 01 20:36:44 Well, in that case then I still don't understand why it is added to core-image-minimal since it will default it Apr 01 20:36:53 right-- that's just so other recipes can convenienently grab those packages all at once Apr 01 20:36:57 see e.g. https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-extended/images/core-image-lsb.bb Apr 01 20:37:43 core-image-minimal provides its own IMAGE_INSTALL, so the default from core-image.bbclass isn't used Apr 01 20:38:47 Right, so in essence all it is doing is getting rid of the default "packagegroup-base-extended" in core-image.bbclass Apr 01 20:38:50 ? Apr 01 20:47:45 Looks like it. It also adds in ${ROOTFS_PKGMANAGE_BOOTSTRAP} which IIRC is support for running any post-install scripts provided by your packages. Apr 01 20:51:06 (I'm not fully sure what the story is behind that-- normally those are pulled in by the image class in response to the package-management IMAGE_FEATURE-- but I'd guess it wants to pull in that piece of support without enabling other things that key off of 'package-management'.) Apr 01 20:55:11 anyone using fitimage kernels with master Apr 01 20:55:21 kernel-fitimage seems to be drunk Apr 01 20:57:57 OK cool. Thanks Apr 01 20:58:23 Marex, where you drunk when you did fit-image support? Apr 01 21:06:33 Crofton: yes ? Apr 01 21:06:38 Crofton: what ? Apr 01 21:06:38 hey Apr 01 21:06:44 working on fitimage for Xilinx Apr 01 21:06:51 * Marex tries to understand what is going on Apr 01 21:06:56 you did fitimage bbclass? Apr 01 21:07:03 Crofton: yes Apr 01 21:07:43 https://github.com/openembedded/openembedded-core/blob/master/meta/classes/kernel-fitimage.bbclass#L170 Apr 01 21:07:46 seems drunk Apr 01 21:07:55 linux.bin hardcoded Apr 01 21:08:21 I need arch/arm/boot/zImage Apr 01 21:08:31 hacking now to shutup morat Apr 01 21:08:40 we can talk freely here Apr 01 21:08:42 :) Apr 01 21:08:45 Crofton: iirc linux.bin is generated from zImage by kernel-image.bbclass Apr 01 21:08:53 hmmm Apr 01 21:09:03 ok, I read there Apr 01 21:09:06 Crofton: freely , you mean without fisherm interference ? ;-) Apr 01 21:09:11 yeah Apr 01 21:09:15 lol Apr 01 21:09:25 Crofton: it's been a while since I looked at the kernel bbclass, so I might be wrong Apr 01 21:09:35 Crofton: but that was the logic Apr 01 21:09:46 well, I hacked in the fuill path Apr 01 21:09:58 see what happens and read there Apr 01 21:10:11 Crofton: there is a bit of legacy crap in those kernel image classes and I had to go through some nasty hoops just to make it NOT break some BSPs Apr 01 21:10:28 this is what I FEAR Apr 01 21:10:55 I also saw someone made a xlinx fitimage class and sent to meta-xilinx Apr 01 21:10:59 Crofton: meta/classes/kernel-uimage.bbclass look here Apr 01 21:11:10 it is friday, we should be drunk Apr 01 21:11:22 Crofton: Friday's trigger ? ;-) Apr 01 21:11:29 Crofton: xilinx discussion is for #u-boot , not here Apr 01 21:11:45 yeah, just commenting on fit getting done in two places Apr 01 21:11:50 which makes me angry Apr 01 21:12:00 Crofton: there should only ever be this one fit imageclass Apr 01 21:12:03 one class to rule them all Apr 01 21:12:13 Crofton: it can be extended if needed be , or overriden, but please dont duplicate it Apr 01 21:12:25 of course Apr 01 21:12:37 this is we we are talking :) Apr 01 21:13:10 :) Apr 01 21:13:17 why we are Apr 01 21:13:25 Crofton: drunk already ? :) Apr 01 21:13:30 I wsh Apr 01 21:13:37 Crofton: anyway, see that kernel-uimage.bb , that's where linux.bin comes from Apr 01 21:13:38 1413 here Apr 01 21:13:42 k Apr 01 21:14:40 23.14 here , I'm trying to decide whether I want to try debugging ultra-nasty bug on certain SoC (no comment) or implement support for altera epxa10 into linux, or hack on mips Apr 01 21:15:06 go to sleep is not an option? Apr 01 21:15:07 :) Apr 01 21:15:35 too early Apr 01 21:25:32 hmm, what do I set KERNEL_IMAGETYPE to? Apr 01 21:26:31 fitImage Apr 01 21:28:43 JaMa, after some time compiling my project in Yocto 1.7 I get this error in qtquick1: | Project ERROR: Unknown module(s) in QT: script-private Apr 01 21:29:04 ERROR: Task 123 (/home/icchw/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtquick1_git.bb, do_compile) failed with exit code '1' Apr 01 21:31:04 Marex, I'm not seeing how zImage gets to linux.bin Apr 01 21:31:12 what is more strange, I'm already using this project for months and did not change anything Qt Apr 01 21:36:38 Crofton: I have this in my machine.conf: Apr 01 21:36:39 KERNEL_IMAGETYPE = "fitImage" Apr 01 21:36:39 KERNEL_CLASSES += " kernel-fitimage " Apr 01 21:36:48 Crofton: the later is important iirc Apr 01 21:38:06 Crofton: which kernel image gets packed into your fitImage instead of zImage ? vmlinux ? Apr 01 21:42:31 linux.bin Apr 01 21:42:37 hacking to test Apr 01 21:43:14 morats and I need to test some shit, will likely fix in a week when I get home Apr 01 21:43:27 shhh, he is looking at the screen Apr 01 21:45:49 Crofton: I should've distracted him ;-) Apr 01 21:46:17 Crofton: linux.bin is interim file, it gets generated from something Apr 01 21:51:23 yeah, just not clear what Apr 01 21:53:46 Crofton: look at that uboot_prep_kimage function in kernel-uboot.bbclass , should give you an idea what image is processed into the linux.bin Apr 01 21:54:56 it 3 PM, at 4 or so we drink beer Apr 01 21:55:06 then I go to ELC for a week and forget what I am doing Apr 01 21:58:37 so my kernel-uboot class is going tp take vmlinux and onjcopy into linux.bin Apr 01 22:04:57 Crofton: that seems correct Apr 01 22:06:02 so I am putting uImage in fit.itb> Apr 01 22:06:05 not zImage Apr 01 22:06:32 Crofton: you are doing vmlinux(elf)->objcopy(linux.bin)->fitImage Apr 01 22:07:00 that is what i think is happening Apr 01 22:07:09 I bet my loadaddr is bad Apr 01 22:07:42 Crofton: set it to ram base + 0x8000 Apr 01 22:07:57 yeah Apr 01 22:08:04 I think Xilnx base is 0 Apr 01 22:15:42 crap Apr 01 22:15:58 did anyone run into issues with systemd-networkd requiring a user 'systemd-network' that's not created? Apr 01 22:16:02 so fitimage bbclass is tryuing to package uImage? Apr 01 22:17:08 systemd commit that introduced this was: d3cf48f4 Apr 01 22:17:45 Crofton: it is not, the kernel-uimage.bbclass is for packaging uimages Apr 01 22:17:54 Crofton: run 'bdinfo' in uboot, that will tell you the rambase **** ENDING LOGGING AT Sat Apr 02 02:59:58 2016