**** BEGIN LOGGING AT Tue Jan 13 02:59:59 2015 Jan 13 04:37:40 is there a straight forward way to print var flags? like do_clean[cleandirs] so I can be sure I setting it to what I expect? Jan 13 04:45:27 dvhart: bitbake -e, should be able to give you the value of do_clean[cleandirs] Jan 13 04:51:54 nrossi, I tried that first, greping for cleandirs lists the "cleandirs" string, but no variable data. Jan 13 05:04:06 dvhart: you could always try putting a anonymous python() { print(d.getVar("do_clean", "cleandirs")) } in your recipe Jan 13 05:04:21 dvhart: sorry d.getVarFlag* Jan 13 05:05:27 OK, thanks - I wasn't sure how to access the array via getVar Jan 13 05:05:33 appreciate that Jan 13 05:10:14 that works, much appreciated Jan 13 05:10:39 maybe time to add support in bitbake -e to print out the flags on tasks too ;) Jan 13 05:12:18 :-) Jan 13 08:49:12 good morning Jan 13 08:52:17 hi mckoan Jan 13 09:20:54 morning all Jan 13 09:21:11 hi Jan 13 09:22:53 hi bl Jan 13 09:30:22 hi bluelightning, mago_, woglinde Jan 13 10:53:36 a package RRECOMMENDS a kernel-module, which isn't getting included. I have no BAD_RECOMMENDATIONS, NO_RECOMMENDATIONS is not set and PACKAGE_EXCLUDE is empty. I suspect that this is because my kernel config doesn't set this module to =m (or =y). But shouldn't this emit a warning during build? Jan 13 10:54:26 (for reference, it's openvpn that RRECOMMENDS kernel-module-tun) Jan 13 10:54:36 mago sure Jan 13 10:54:45 otherwise openvpn will not work Jan 13 10:54:49 hm Jan 13 10:55:11 woglinde: it doesn't emit a warning, my build succeeds and i can run openvpn on target.. only to see it fail because it cannot create a TUN-device Jan 13 10:55:16 mago_ RRECOMMENDS != RDEPENDS Jan 13 10:55:54 yes, i know, but shouldn't all RRECOMMENDS be treated as RDEPENDS unless BAD_RECOMMENDATIONS, NO_RECOMMENDATIONS or PACKAGE_EXCLUDES states otherwise? Jan 13 10:56:03 but it is a problem when you build into the kernel instead of modul Jan 13 10:56:18 mago hm don't know Jan 13 10:56:52 i don't build it statically into the kernel either.. i'm mostly curious why OE doesn't warn me when it failed to include a recommended package Jan 13 10:57:22 i'm pretty sure this will go away once i set CONFIG_TUN=m in my kernel config.. but still, i should've gotten a warning? Jan 13 11:07:03 mago_: the warning will be in the do_rootfs log Jan 13 11:07:14 mago_: it's by design that OE itself won't give you a warning Jan 13 11:08:04 since OE doesn't parse the kernel config (and shouldn't, since the resulting openvpn package can run on multiple MACHINES with the same arch) Jan 13 11:34:20 koen: i see, thanks Jan 13 11:54:38 hi guys Jan 13 11:54:55 I am seeing an odd issue with the linux-yocto Jan 13 11:55:26 i am using an older hash of the OE Jan 13 11:56:13 specifically meta-oe: a4bdcbdbca05bbb4a452e06982038f0a38bcb91f and oe: ad065f94acb0bfb81e33935890a1db251d6e2979 Jan 13 11:56:27 I am trying to build for qemuarm Jan 13 11:58:09 now in one of my own layers i have some patches for the kernel which apply on standard/arm-versatile-926ejs branch at hash 902f34d Jan 13 11:58:50 in my recipe i write SRCREV_machine_qemuarm = "902f34d36102a4b2008b776ecae686f80d307e12" Jan 13 11:59:22 if I provide no patches from my layer everything remains fine Jan 13 11:59:50 but as soon as I use SRC_URI_append = "file://my_patch.patch" Jan 13 12:00:35 the checked out kernel hash on which my patches are being applied is different from the one mentioned in SRCREV Jan 13 12:01:08 specifically there are additional commits in between my patches and the SRCREV Jan 13 12:01:34 in the kernel tree after the do_patch step Jan 13 12:13:45 abelal: maybe you meant SRC_URI_append += ? Jan 13 12:15:45 mago_: yes that's how it is Jan 13 12:18:35 abelal: i don't fully understand what you're trying to do, are you changing the SRCREV of linux-yocto, and then apply some custom patches to it through your own layer? Jan 13 12:22:59 mago_: yes that is what I am trying Jan 13 12:23:33 mago_: I am writing a minimal sort of bbappend that I can share to point out the exact issue Jan 13 12:28:00 abelal are you using a bbapend file? Jan 13 12:28:47 woglinde: yes I have a bbappend Jan 13 12:29:24 woglinde: on the hash i mentioned for OE, i am using a linux-yocto_3.14.bbappend file for providing my updates Jan 13 12:42:42 abelal: and you're building with MACHINE=qemuarm? otherwise your SRCREV override will be ignored Jan 13 12:43:02 mago_: obviously :) Jan 13 12:43:34 so you're saying once your layer is included, linux-yocto gets the incorrect SRCREV, even if you're setting it in your .bbappend? Jan 13 12:55:55 mago_: if I only set the SRCREV and do a git log in the kernel src dir the top commit is the one set through SRCREV, which is correct Jan 13 12:56:18 mago_: now if I provide a patch through SRC_URI_append from my bbappend Jan 13 12:56:35 and check the git log in the src dir Jan 13 12:57:05 there are additional commits between the SRCREV and patches i provide Jan 13 15:19:21 anyone know if ASSUME_PROVIDED_remove = "git" would work? Jan 13 15:19:56 i assume you mean git-native. git is required at parse time, so the one on the host is going to be used anyway for fetching, whether we build our own or not Jan 13 15:20:25 I have a special problem Jan 13 15:20:39 Crofton|work: you are special Jan 13 15:20:43 yes Jan 13 15:21:20 uhd uses git from the sysroot to put a git hash in the binary Jan 13 15:21:39 because the devs are confused about releases :) Jan 13 15:22:01 ah, 'git describe' in the makefile? Jan 13 15:22:15 something liek that Jan 13 15:22:24 and cmake will not let it use the build system binary Jan 13 15:22:27 thank god Jan 13 15:22:39 so I need to get it into the sysroot Jan 13 15:22:50 ah Jan 13 15:22:51 and I do not want to edit the file in oe-core Jan 13 15:23:03 and due to assume_provided, DEPENDS=git-native doesn't work Jan 13 15:23:12 right Jan 13 15:24:27 in theory it should work, in that git-native should be built if you remove it from ASSUME_PROVIDED Jan 13 15:25:37 and I could expect the syntax to work? Jan 13 15:26:14 except using git-native :) Jan 13 15:26:37 why not just patch out the bit where it tries to find git? assuming that is not automatically handled by cmake Jan 13 15:27:05 because the devs crap themselves when they see "unknown" in the version string :) Jan 13 15:27:30 even though I am refsuing to build images from unreleased versions Jan 13 15:28:08 btw bitbake -e is your frined :) Jan 13 15:29:01 crofton sorry I will not make it this year to fosdem Jan 13 15:29:28 Crofton|work: I didn't mean patch out the code that sets the version, I meant patch out the part where it looks to find whether or not git is installed Jan 13 15:29:49 because that is where the problem lies, right? Jan 13 15:32:03 We'll miss you Jan 13 15:32:20 bluelightning, the build works fine Jan 13 15:34:08 Crofton|work: I'm confused then, I thought you said cmake was erroring out Jan 13 15:34:21 no, the developers core dump :) Jan 13 15:34:38 linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.000-0-unknown Jan 13 15:35:22 does the uhd recipe fetch from git or not? Jan 13 15:35:22 actually, they are much better at releases these days Jan 13 15:40:59 yes, that is fine. Just can't run git from camke during configure, without git in sysroot Jan 13 15:41:35 koen, any chance of some of your co-workers who use OE helping a t the stand some during FOSDEM Jan 13 15:45:38 Crofton|work: dunno Jan 13 15:45:45 fabo, suihkulokki ? Jan 13 15:47:28 oh that is interesting Jan 13 15:47:39 you can remove git-native from assume provided Jan 13 15:47:41 Crofton|work: I don't see why git is required in the sysroot Jan 13 15:47:45 and see it gone in bitbake -e Jan 13 15:47:54 cmake will not find git on the host Jan 13 15:48:02 (which is good) Jan 13 15:48:10 so I need it in the sysroot Jan 13 15:48:11 right, hence my suggestion to tell cmake to stop looking (and still call it) Jan 13 15:48:37 the complaint is failure to insert the git hash into the version string Jan 13 15:48:39 cmake doesn't need to know you are using git for you to use it... Jan 13 15:48:43 so that wouldn't solve the user complaint Jan 13 15:49:02 koen: Crofton|work: I can sign up for helping at the stand Jan 13 15:49:04 yes and there are still numerous ways to get it into that string without cmake doing the running Jan 13 15:49:12 fabo, that would be great Jan 13 15:49:18 Crofton|work: update the wiki page, right? Jan 13 15:49:23 bluelightning, is the guy to talk to Jan 13 15:49:25 yeah Jan 13 15:49:33 Sunday might be best Jan 13 15:49:36 akc Jan 13 15:49:39 I'm in the sdr devroom then Jan 13 15:49:44 ack I meant :) Jan 13 15:50:22 we aren't super formal about scheduling, just trying to get the load spread out and let people see talks Jan 13 15:50:34 I'll try to bring by lunch on saturday as usual Jan 13 15:51:03 I think I have everyones dietary restrictions memorized Jan 13 15:51:17 koen: thanks, I certainly appreciated it last year :) Jan 13 15:52:02 seems to be a bug in the ASSUME_PROVIDED_remove handlign :) Jan 13 15:52:15 WARNING: Explicit target "git-native" is in ASSUME_PROVIDED, ignoring Jan 13 15:52:17 but Jan 13 15:52:25 Crofton|work: I strongly suggest not trying to solve it that way... Jan 13 15:52:32 [balister@thuvia build]$ bitbake -e gnuradio-dev-image | grep ^ASSUME_PROVIDED Jan 13 15:52:32 ASSUME_PROVIDED="bzip2-native chrpath-native grep-native diffstat-native patch-native perl-native-runtime python-native-runtime tar-native virtual/libintl-native texinfo-native bash-native" Jan 13 15:52:36 bluelightning, I hate it Jan 13 15:53:41 this is the proverbial sledgehammer to crack a nut Jan 13 15:53:48 yep Jan 13 15:54:51 we should invite the Free Electrons guys to help with the stand Jan 13 15:55:08 I'd be glad to let them do a little self promotion even :) Jan 13 16:11:49 hm when I want to upstream a patch to meta-oe from some else how do put in that I adapted it for upstream? Jan 13 16:14:28 i'd add a sign-off and then a note to the commit message indicating what was changed Jan 13 16:14:46 ah found the guideline Jan 13 16:15:02 unfornatly zecke did not sign it off Jan 13 17:23:52 crofton how does qt5 work with the seperate build dir? Jan 13 17:25:20 hm okay I see gnuradio uses cmake Jan 13 17:42:49 no qt5 experience here Jan 13 17:44:08 crofton I actually figured it out Jan 13 17:44:18 the .pro file did not have any install handling Jan 13 18:42:24 hm what is the proper way to install something recursive in do_install Jan 13 18:43:58 JaMa: what's with the version-going-backwards issues at the end of the status email? Jan 13 18:44:18 PR server issues Jan 13 18:44:48 and signatures issues Jan 13 18:45:15 anything we need to fix? Jan 13 18:46:20 woglinde: I'm not sure install supports that, you may need to use cp -r Jan 13 18:46:34 I know we have in a number of recipes Jan 13 18:46:52 bluelightning okay Jan 13 18:47:16 only wanted to know if we have a proper solution Jan 13 18:48:34 bluelightning: yes, if we ever want reliable upgrade paths Jan 13 18:49:02 JaMa: so, what is the specific problem? Jan 13 18:49:41 JaMa: I've also noticed that version-going-backwards will also trigger across archs Jan 13 18:50:10 e.g. foo 1.2-r2 on armv5 and foo 1.2-r0 mips Jan 13 18:50:10 the mips one will get the warnings Jan 13 18:50:40 jama do you know offhand a recipe which uses libspatiallite? Jan 13 18:52:28 bluelightning: first we need correct signatures/PACKAGE_ARCHs http://lists.openembedded.org/pipermail/openembedded-core/2014-August/095195.html Jan 13 18:53:15 bluelightning: without this fixed, the version is going back and forth with every MACHINE change Jan 13 18:53:31 surely it should only ever increment? Jan 13 18:54:31 no, because if the signature already exists in database it will return its older lower number Jan 13 18:54:48 I see, that is behaviour I wasn't aware of Jan 13 18:55:07 bbl Jan 13 19:04:21 woglinde: not offhand Jan 13 19:05:37 woglinde: you can ask jluebbe@debian.org Jan 13 19:09:01 jama ;) I know Jan 13 19:09:17 JaMa I will send soon an update Jan 13 19:09:19 to 4.2 Jan 13 22:33:36 arrrgh Jan 13 22:33:41 * kergoth grumbles Jan 13 22:35:50 kermit the frog get lose? Jan 13 22:39:05 getting annoyed with this task, every time i think i have it fixed, i break it worse Jan 13 22:39:22 still working on this damn recipetool python support stuff Jan 13 22:39:49 trying to process package_dir from setup.py has caused all manner of trouble Jan 13 22:44:43 you can't sanely do dependency scanning without maintaining info about context — what package this file is in, to be able to handle relative imports Jan 13 22:44:49 which gets irritating Jan 13 22:50:33 it will be worth it :) Jan 13 22:59:55 I might just back out the handling of py_modules/packages/scripts from setup.py and let it scan from the root of the source tree for now, and revisit this later, since the tool was working before i screwed it up trying to get this working with package_dir :) **** ENDING LOGGING AT Wed Jan 14 02:59:59 2015