**** BEGIN LOGGING AT Wed Oct 18 03:00:01 2017 Oct 18 07:26:32 Hi, I have strange problem using rocko Oct 18 07:26:37 my app is uaing bluez5 Oct 18 07:27:00 I've used preferred version in conf to 5.45 (I don't want to bump to 5.46 which is present in rocko) Oct 18 07:27:13 I have in DISTRO_FEATURES bluetooth + bluez5 Oct 18 07:27:30 then during do_rootfs I get: - nothing provides bluez5 >= 5.45 needed by myapp Oct 18 07:27:43 + also - nothing provides bluez5 needed by packagegroup-base-bluetooth-1.0-r83 Oct 18 07:34:42 anything missing in my config? **** BEGIN LOGGING AT Wed Oct 18 07:36:32 2017 Oct 18 09:01:49 hey all, if I have multiple versions of a recipe, is it possible for an IMAGE to select a specific version (i.e have yocto build the right one on demand) ? AFAICT stuff like PREFERRED_VERSION is global, it can't be specified per-image Oct 18 09:02:05 i.e is there a way to specify a software version in IMAGE_INSTALL ? Oct 18 09:16:36 boucman_work: yes that is possible. Oct 18 09:16:51 nice, how ? :) Oct 18 09:17:14 boucman_work: i must say i'm not shure how to do it but i guess it can be done whit PREFERRED_VERSION Oct 18 09:17:57 hmwel: preffered_version can be defined in an image ? that would work ? Oct 18 09:17:58 I'm using PREFERRED_VERSION_linux_MyKernel = "4.4" to select the kernel from my .conf Oct 18 09:18:07 the onlything that comes to my mind is doing some DISTRO magic. Oct 18 09:18:32 boucman_work: no, it certainly will not work in a .bb file Oct 18 09:18:36 yeah, but DISTRO level stuff will affect all images, I want image A to have version A and image B to have version B Oct 18 09:19:27 i'm not even sure the dependency logic can handle a recipe depending on a specific version of another recipe... can it ? Oct 18 09:19:31 boucman_work: split the recipe into an .inc, a WHATEVERA.bb and a WHATEVERB.dd Oct 18 09:19:49 that's ugly, but that would work... Oct 18 09:20:14 abusing the name as disciminator, as that is something you can set through the image Oct 18 09:20:44 boucman_work: hum, maybe you can use this? https://lists.yoctoproject.org/pipermail/yocto/2013-August/015500.html Oct 18 09:22:14 ok, thx, I understand Oct 18 09:27:05 Has anyone run into problems with archiver.bbclass lately? I'm now seeing "quilt: not found" on many recipes. Oct 18 09:27:21 Not every recipe that uses patches need to depend on quilt-native, does it? In any case, build is fine without archiver so it doesn't make sense. Oct 18 10:53:27 <_ppp> hi all, i am looking for a wifi PCIE dongle that can work as AP and Client and compatible with yocto on a embedded device, any recommendation? Oct 18 10:55:15 _ppp: probably anything atheros Oct 18 10:59:21 easily available as mini pcie, rest is just mechanics Oct 18 11:01:36 denix: sorry; it was a warning ... Oct 18 11:01:54 denix: btw ... we need a pyro branch of meta-ti Oct 18 11:02:59 denix: the linux-dtb.inc removal on rocko and master breaks pyro use. So please branch for pyro before this change. Oct 18 11:17:32 rburton: I did rebase the patches I have pending here and resent Oct 18 12:02:35 nrossi: My u-boot doesn't work! :( Oct 18 12:03:02 nrossi: :P Oct 18 12:03:41 JoiF: thats a common issue, google "my u-boot doesn't work", ~6M results :) Oct 18 12:03:50 nrossi: Hahaha Oct 18 12:05:30 nrossi: So. I basically scrapped my old layer, which was basically a fork from meta-xilinx. Oct 18 12:06:38 nrossi: (my layer is called "meta-foss") In my new layer, instead of forking meta-xilinx, I'm doing a LAYERDEPENDS_foss = "xilinx" Oct 18 12:06:50 JoiF: makes sense Oct 18 12:07:00 nrossi: And then I'm mostly doing bbappends Oct 18 12:08:07 nrossi: And I got it building and it all seems good, it's compiling what seems to be the appropriate version of u-boot and linux-xlnx, etc.. Oct 18 12:10:21 JoiF: so whats the error? failure state? Oct 18 12:10:22 nrossi: But when I JTAG u-boot-spl.bin it nothing works. The processor seems to go in some mode where I can't do anything else. It even fails to JTAG u-boot.elf, which is the next step, saying "Cannot halt processor core, timeout" Oct 18 12:10:41 nrossi: Have you come across a similar scenario? Oct 18 12:10:56 nrossi: Just wanted to ask in case there's something obvious I'm missing Oct 18 12:10:59 JoiF: does u-boot-spl.bin have your ps7_init setup in it? if not then the DDR is likely uninitialized caused bus timeouts Oct 18 12:11:33 nrossi: How can I verify that? Oct 18 12:11:50 JoiF: the size of the .bin should be in the 60KB + range if the ps7_init is in it Oct 18 12:12:07 JoiF: but you can also check the elf map for the special symbols Oct 18 12:13:07 du -sh u-boot-spl.bin60K u-boot-spl.binls -l u-boot-spl.bin-rwxr-xr-x 1 jofr jofr 60948 Oct 17 16:37 u-boot-spl.bin Oct 18 12:15:32 So in my layer, I duplicated recipes-bsb/platform-init and there I have platform-init.bb which I coped over from meta-xilinx but replaced the picozed with my own board-name Oct 18 12:15:44 JoiF: double check the u-boot-spl.map in the work dir, make sure it has .text.ps7_* symbols Oct 18 12:16:13 JoiF: doing that with platfor-init.bb should work Oct 18 12:17:30 and then I of course douplicated the second platform-init folder (i.e. recipes-bsp/platform-init/platform-init//) and put my ps7_init_gpl.* in there. Oct 18 12:17:57 They do seem to be picked up, because if I put rubbish in either of them, the build crashes.. Oct 18 12:19:13 JoiF: ok, then it looks like its building correctly. Might be a jtag/device issue? have you tested with a known working .bin file? Oct 18 12:19:29 nrossi: Yes. Works fine. Oct 18 12:19:57 JoiF: are the versions of u-boot the same for each? Oct 18 12:20:08 nrossi: Nope. Oct 18 12:20:35 JoiF: also if this is a custom board, have your made the associated setup for dts/kconfig in u-boot? Oct 18 12:21:42 nrossi: My old fork-thing was based on morty, but now u-boot seems to have changed. Can you tell me a bit about that? There is both u-boot-xlnx and also u-boot_2017.1 or something like that Oct 18 12:22:24 nrossi: Yes. It's a custom board. I believe I've been able to put my configuration in u-boot .. but that's probably where I'm failing. Oct 18 12:22:32 JoiF: for your purposes u-boot-xlnx == u-boot Oct 18 12:22:44 they are pretty much equal source now Oct 18 12:22:46 (for zynq) Oct 18 12:23:12 JoiF: So you will need a .dts which goes in arch/arm/dts/ .... look at the existing for samples Oct 18 12:24:13 JoiF: and you will need a _defconfig, use an existing zynq_* one and update it with your parameters. You will at least need to change the DEFAULT_DEVICETREE value Oct 18 12:24:25 s/use/copy/ Oct 18 12:24:59 nrossi: So I should be using PREFERRED_PROVIDER_virtual/bootloader = "u-boot-xlnx" in my machine config? Because some of most of the ones that come with meta-xilinx use "u-boot" Oct 18 12:25:15 (but not all of them) Oct 18 12:25:55 I mostly look at what's being done for either picozed or zybo when I'm constructing my own config, and both of them prefer on "u-boot" Oct 18 12:26:42 JoiF: You can use normal u-boot, there was a large discussion here: https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-April/002728.html Oct 18 12:27:19 JoiF: essentially Xilinx wanted to have there eval boards default to their tree, for the small set of uncommon features that are not upstream Oct 18 12:28:03 I see Oct 18 12:30:46 I've asked in the morning but seems no reply so trying to ask again :) Oct 18 12:30:49 Hi, I have strange problem using rocko Oct 18 12:30:49 my app is uaing bluez5 Oct 18 12:30:49 I've used preferred version in conf to 5.45 (I don't want to bump to 5.46 which is present in rocko) Oct 18 12:30:49 I have in DISTRO_FEATURES bluetooth + bluez5 Oct 18 12:30:49 then during do_rootfs I get: - nothing provides bluez5 >= 5.45 needed by myapp Oct 18 12:30:50 + also - nothing provides bluez5 needed by packagegroup-base-bluetooth-1.0-r83 Oct 18 12:31:45 nrossi: Would you be willing to see if I'm doing someting moronic in my u-boot configuration? https://github.com/johannfr/meta-foss/tree/master/recipes-bsp/u-boot Oct 18 12:32:27 (those two bbappends are the same, just append to those two different u-boots) Oct 18 12:33:05 JoiF: You probably want do_configure_prepend() to make it happen before the make config step Oct 18 12:33:32 Ok Oct 18 12:35:12 open-nandra: I assume you have a recipe which is versioned 5.45? Oct 18 12:35:29 nrossi: yes andI can see it's build Oct 18 12:35:37 I can see ipk is created Oct 18 12:35:52 I tried to remove 5.45 recipe and use one from rocko (5.46) same issue Oct 18 12:35:55 open-nandra: whats the actual PV? set by the recipe and by the package Oct 18 12:36:14 nrossi: Fo bluez? Oct 18 12:36:16 nrossi: Foe bluez? Oct 18 12:36:19 nrossi: For bluez? Oct 18 12:36:24 open-nandra: bluez5 specifically Oct 18 12:36:28 ok sec Oct 18 12:37:06 nrossi: 5.45-r0 Oct 18 12:37:30 open-nandra: This is with IPK yer? Oct 18 12:38:04 nrossi: bluez5_5.46-r0_cortexa8hf-neon.ipk Oct 18 12:38:10 sorry rebuild now 5.46 vesion Oct 18 12:38:17 so ipk is there Oct 18 12:38:30 nrossi: I have recipe which have DEPENDS on bluez5 Oct 18 12:38:59 open-nandra: but your recipe is not specifically depending on "bluez5 >= 5.45" its just "bluez5" in DEPENDS? Oct 18 12:39:14 nrossi: exactly Oct 18 12:39:27 but I've set PREFERRED_VERSION to 5.45 Oct 18 12:39:32 to aoid building 5.46 Oct 18 12:39:40 in previous test Oct 18 12:40:19 open-nandra: hmmmm sounds like ipk might have a bug, have you tried building the rootfs with rpm instead? Oct 18 12:40:35 nrossi: nope we stick to ipk Oct 18 12:40:40 I can do clean build Oct 18 12:40:42 to check Oct 18 12:41:03 open-nandra: thats an easy way to narrow it down to a package manager resolution issue Oct 18 12:41:33 nrossi: ok I'll try to change to RPM and rebuild Oct 18 12:42:46 nrossi: if it will work in rpm then I probably should fill a bug :) Oct 18 12:43:34 open-nandra: yep :) Oct 18 12:43:42 nrossi: ok Oct 18 12:43:56 nrossi: but if it won't work in rpm also Oct 18 12:44:35 open-nandra: then further debugging is in order :) Oct 18 12:45:12 nrossi: that will be hard Oct 18 13:02:40 nrossi: ok finished Oct 18 13:02:47 but new error: - nothing provides libQtNetworkE.so.4 needed by myapp Oct 18 13:03:13 and same with bluez5: nothing provides bluez5 needed by packagegroup-base-bluetooth-1.0-r83 Oct 18 13:03:48 open-nandra: just to clarify, you built with only "package-rpm"? Oct 18 13:04:00 nrossi: exactly Oct 18 13:04:14 just change my local.conf and rebuild Oct 18 13:04:27 open-nandra: pastebin the full log, might be something hiding in there :) Oct 18 13:05:36 nrossi: I wish but I cannot share, sorry about that Oct 18 13:05:43 nrossi: so I'm on my own :) Oct 18 13:06:27 open-nandra: ahhh, that really limits how much i can help Oct 18 13:06:39 nrossi: I know Oct 18 13:06:52 hi.. anyone has ipv4options for iptables built? Oct 18 13:07:32 nrossi: maybe just an small idea what else to check? Oct 18 13:07:41 why packagemanager cannot see those packages Oct 18 13:08:35 open-nandra: If you build without the PREFERRED_VERSION set does it work? Oct 18 13:09:04 nrossi: not because then it build rocko 5.46 and I have same issue but with different version Oct 18 13:16:04 Oh, archiver bug is here https://bugzilla.yoctoproject.org/show_bug.cgi?id=11420 Oct 18 13:16:05 Bug 11420: normal, Medium+, 2.3.3, ross.burton, IN PROGRESS REVIEW , archiver's do_unpack_and_patch task is failing for busybox target Oct 18 13:18:41 Earlier I searched the commit history but didn't find the patches. Maybe just not looking for the right words. rburton? Oct 18 13:26:47 "patches sent to list" ... hmm, sorry I don't find them. Yocto list? Oct 18 13:28:17 good afternoon Oct 18 13:49:04 mckoan: hey Oct 18 14:56:26 halstead: patchtest cron stopped. New version of patchtest coming, now using tinfoil to parse patch metadata! Oct 18 14:56:40 halstead: I will enable asap Oct 18 14:59:35 :q Oct 18 15:28:04 lsandov, excellent. Please let me know if any issues arise. Oct 18 16:48:29 rburton, ping Oct 18 18:09:32 armpit: yo Oct 18 18:10:53 rburton, our mut builds, you want me to open bugs? Oct 18 18:11:29 your "fire in the hole" statement.. mean swat take cover? Oct 18 18:11:35 armpit: i'd be happy with a summary email. i've been quite horrendously ill today so haven't really looked at the failures. Oct 18 18:11:36 and yes Oct 18 18:11:50 hehe Oct 18 18:12:15 a mail with one line per issue and a link to a sample errors.yp page would be so useful Oct 18 18:12:20 ok. take care.. I will look at the logs later Oct 18 18:12:22 the buildlog *should* almost be that Oct 18 18:12:29 k Oct 18 19:04:53 good day all Oct 18 19:05:29 how does one get zImage and dtb in the rootfs boot folder Oct 18 21:13:37 Hello all - does anyone have a few minutes to discuss the external-linaro-toolchain recipe inside meta-linaro? Oct 18 23:51:15 hey guys, I'm working on a project that involves building multiple pieces of firmware (e.g. coreboot) and stitching final image as a result. Currently we have bunch of hand-made bash scripts. I'm trying to figure out if some neat and clean solution can be applied on top of that to take care of the build process. Bitbake might be an overkill but what about emerge or make? Do you have any suggestions? Oct 19 00:15:14 you are trying it otherway around IMO, you should be first building a distro and then doing post processing for images Oct 19 00:16:01 I would suggest to use distro's packaging as much as you can for your customizations Oct 19 00:16:57 scripts and makefiles easily tend to become hairy over time if not maintained, if I were you I would just try to keep as little customization as possible Oct 19 00:21:56 khem: we don't build OS itself. We build everything that happens before OS (for some parts we just take binary blobs) and we take OS from another team as an image Oct 19 00:37:33 xz: I see, you can use something like cmake or good old make Oct 19 00:38:35 I would even look into gradle or bazel Oct 19 00:40:08 khem: we have around 12 different boards and we need multiple flavors for them. That could be 20+ builds. Majority of stuff between them is shared, but not everything. Oct 19 00:40:52 khem: never heard of gradle or bazel, let me do some research Oct 19 00:41:07 it seems all you are looking for is a packaging help Oct 19 00:41:14 I think they can help Oct 19 00:50:28 khem: I like gradle, that might work Oct 19 00:50:40 khem: seems little similar to bitbake, but much simpler **** ENDING LOGGING AT Thu Oct 19 03:00:01 2017