**** BEGIN LOGGING AT Mon Mar 27 03:00:03 2017 Mar 27 11:24:49 I have trouble adding a new recipe and doing devtool-modify on the same. Getting the "compiling from external source tree [correct path]" message, but compiling is still done down in tmp/work/{machine}/... Mar 27 11:26:16 Looking in run.do_compile I see `cd '/the/tmp/work/machine/pkg-path'; do_compile` Mar 27 13:15:32 Is there any valid reason for a recipe for the target to depend on bison (not bison-native)? Mar 27 13:20:15 mario-goulart: only if the recipe requires the target bison to build Mar 27 13:21:05 mario-goulart: (assuming you're not talking about RDEPENDS) Mar 27 13:21:27 mago1: I'm actually talking about DEPENDS. Mar 27 13:22:38 doubt it then Mar 27 13:23:01 bison itself build depends on bison-native, so it would solve the "i need bison to build" problem Mar 27 13:23:05 albeit wrongly Mar 27 13:23:12 and only if building from scratch Mar 27 13:23:18 indeed Mar 27 13:23:53 I'd say the same for flex, but I think flex actually ships a library. Mar 27 14:00:00 rburton: hello Mar 27 14:00:12 rburton: did you put u-boot in MUT for test? Mar 27 14:00:41 rburton: I would also try to fit mesa upgrade for release; it is just bug fixes and would be good to have in Mar 27 14:02:11 yeah they're in next for testing Mar 27 14:04:14 Marex, ^^^ Mar 27 14:08:39 Marex: 2017.03 release, it is Mar 27 14:13:19 what ? Mar 27 14:14:36 Crofton|work: what is otavio talking about ? Mar 27 14:15:16 he sent in patches for 2017.03 Mar 27 14:16:33 well gee, thanks for CCing me Mar 27 14:16:35 link ? Mar 27 14:17:14 Crofton|work: that's for poky 2.3 or next one ? Mar 27 14:18:34 I'm not sure, just wanted to make sure you knew there were patches around Mar 27 14:21:15 Crofton|work: I might as well submit my patch too finally ^_^' Mar 27 14:21:23 should've done that a while ago Mar 27 14:27:17 :-) Mar 27 14:27:56 Well, you brok eth elast release as I recall Mar 27 14:28:23 so timing and making sure what is in release really works is up to u-boot user community Mar 27 14:28:47 Crofton|work: who, me? Mar 27 14:29:31 and the other people using u-boot in OE :) Mar 27 14:29:49 and making your don't break autobuilder and tests Mar 27 14:30:26 personally, I think I will be OK with the update :) Mar 27 14:32:55 Crofton|work: I am not following you Mar 27 14:33:40 Crofton|work: Updating U-Boot is a problem if the BSP uses the OE-Core recipe and applies patches on it. If it does, I think it is wrong twice. It should send those patches upstream or use a fork Mar 27 14:33:49 otavio, we had a conversation with marex a while back about whether the next release would have 2017.01 or 2017.03 Mar 27 14:34:28 Crofton|work: as being one of most active people on u-boot recipe I would have been included on this conversation I believe Mar 27 14:34:33 since .03 was fairly late in the release cycle, Marex sent in .01 Mar 27 14:35:50 Well it is not fairly late being used by few reference bsp only Mar 27 14:36:31 I think braoder use than that Mar 27 14:37:06 I use it in many boards and as I apply patches I keep a fork Mar 27 14:37:24 but the original recipe, I don't think so Mar 27 14:38:32 and the fork depends on the abysmal state of u-boot bbclass ... we've been there Mar 27 14:38:43 * Marex is kinda getting annoyed, bbl Mar 27 16:17:48 RP: do you remember who was last week reporting an opkg solver issue? I still believe opkg is behaving correctly, but I am somewhat on the lookout for issues because libsolv does make opkg more strictly adhere to debian guidelines (some recipes may rely on opkg not following debian that strictly) Mar 27 16:18:06 I want to make sure I follow up, just in case Mar 27 16:21:33 adelcast: I'd have to look through the logs, I don't remember offhand Mar 27 16:21:42 adelcast: thanks for looking into it though! Mar 27 16:22:48 otavio: meta-raspberrypi uses the u-boot recipe from oe-core. We don't currently apply any patches but I'll need to do some re-testing if we upgrade u-boot this late in the cycle. Mar 27 16:23:05 the last few upstream u-boot releases have changed things for rpi quite a bit Mar 27 16:23:17 and this is why i'm always cautious about u-boot upgrades Mar 27 16:23:24 RP: no worries, I'll dig in the logs....do ping me if you hear of anyone else having issues with the switch Mar 27 16:23:24 especially weeks away from the release Mar 27 16:26:09 paulbarker: that is a good data point thanks. That kind of thing is hard to test too Mar 27 16:26:45 using oe-core recipes and applying patches in a bbappend is pretty much my way of working when I need to tweak something for a BSP Mar 27 16:28:48 RP: Thankfully with rpi, u-boot is on an SD card so it's easy to take out and re-flash if I break it. It does need a bit of manual testing though Mar 27 16:29:43 I'm not looking forward to the meta-arduino u-boot upgrade I have planned. In that case it's a soldered down flash with no recovery mechanism if you break u-boot Mar 27 16:36:01 paulbarker: ouch, definitely one you need to get right :/ Mar 27 16:52:06 paulbarker: if you believe it would be breaking anything might be better to have a specific recipe with the validated branch pinned. Mar 27 16:52:19 paulbarker: but of course using the recipe if possible, is nice Mar 27 16:54:09 otavio: on the master branch, I want to find out if the new release is broken. I want it to explode in my face so I can fix it. I just maybe don't want that to happen in the last few weeks before a release Mar 27 17:00:17 personally I'd say let's update u-boot at the start of the yocto 2.4 cycle Mar 27 17:06:00 (my only concern is meta-raspberrypi here. for meta-arduino I just use whatever is already flashed into the board at this stage and I'm not taking on that scary upgrade for a while yet) Mar 27 22:52:03 otavio_, paulbarker: FWIW I'm thinking of not upgrading uboot at this point, its too late **** ENDING LOGGING AT Tue Mar 28 03:00:03 2017