**** BEGIN LOGGING AT Mon Nov 18 02:59:59 2013 Nov 18 07:35:25 morning Nov 18 07:37:07 what does it means "skipped" in the output of bitbake-layers show-recipes? Nov 18 07:37:19 e.g., libx11: Nov 18 07:37:19 meta 1.5.0 (skipped) Nov 18 07:37:48 or how can i enable that recipe? :-) Nov 18 08:29:15 Hi all, is there a way to depend from a nativesdk package on a target-package (without prefix) ? Nov 18 09:30:13 gagi: no, if you think about that a bit you'll realise that doesn't make sense Nov 18 09:31:47 RP: mhh the point is that the target tools are created with the correct paths and everthing and this creates a conf file which is needed for the nativesdk package. Currently i'm copying that to a STAGE_DIR location and than use it iside the nativesdk package Nov 18 09:34:35 gagi: is this file the same for all target architectures? Nov 18 09:34:55 RP: no Nov 18 09:35:40 gagi: there is only one nativesdk package so how does this depend on the file for different target architectures then? Nov 18 09:35:58 gagi: this is why you can't depend on a target package from nativesdk... Nov 18 09:36:30 gagi: We do have the cross-canadian packages which are architecture specific Nov 18 09:36:39 gagi: ohh sorry yes it's the same for all target architecture, but it depends on how the target package is configured, but it's independend on how the nativesdk package is configured Nov 18 09:37:14 gagi: so the same file works unchanged for arm, mips, powerpc and so on? Nov 18 09:37:34 RP: if the target packages are all configured in the same way, yes Nov 18 09:38:02 RP: It's just a configuration files to tell the nativesdk package where to find the files Nov 18 09:38:06 gagi: Usually you'd just write a nativesdk recipe to package up the file then Nov 18 09:39:11 RP: yes but if somebody appends the target recipe and changes the path he would also change the nativesdk paths of the conf file otherwise it won't work, that's why i want to generate it there Nov 18 09:40:30 RP: It's really a special case, but if there is no way around that, then i will generate it inside the nativesdk package Nov 18 09:43:14 RP: If you have both BB_VERBOSE_LOGS = 1 and BUILDHISTORY_COMMIT = 1, is there a way to avoid buildhistory from outputting its script execution to stdout (due to set -x being active when buildhistory_commit executes in an event)? Nov 18 09:44:10 gagi: the nativesdk mapping happens in nativesdk.bbclass. You could so something horrible like append onto nativesdk_virtclass_handler... Nov 18 09:44:11 RP: I.e., I would want set -x not to be active for events as they are not logged to files... Nov 18 09:45:05 RP: no it don't want to mess with the system, if there is no easy way which doesn't damage the system, i will go the other way ;-) Nov 18 09:46:16 Saur: well, its effectively what BB_VERBOSE_LOGS does :/ Nov 18 09:46:51 gagi: you will have to mess with the system a little to do that as there is no easy way to force a target dependency like that into nativesdk Nov 18 09:47:23 RP: Yeah, I've followed the code. Though, to me, the LOGS part of BB_VERBOSE_LOGS implied log files... Nov 18 09:48:35 Saur: I guess this is the only piece of code using exec_func from an event handler... Nov 18 09:49:00 RP: So far the only one I've seen at least... Nov 18 09:50:31 Saur: I'd suggest we talk to bluelightning when he appears, maybe we should add log redirection to buildhistory Nov 18 09:50:31 RP: A related question, bb.msg.loggerVerboseLogs that controls if set -x shall be active seems to be a global variable. If I change it temporarily in the event, will this affect any other task? Nov 18 09:51:08 Or does the multiple slaves somehow help me here? Nov 18 09:51:25 Saur: The execution of event handlers is in the server context Nov 18 09:51:37 Saur: I suspect you could influence other things Nov 18 09:52:02 RP: Are there multiple threads in the server? Nov 18 09:53:03 Saur: kind of, yes Nov 18 09:53:27 Hmm, ok Nov 18 09:54:00 Saur: there are a lot of different threads/processes in bitbake these days so it depends on what you mean Nov 18 09:54:16 RP: A "simple" solution would of course be to rewrite buildhistory_commit in python... Nov 18 09:56:10 RP: Well, if a task would start during the execution of the event, and I have changed the global bb.msg.loggerVerboseLogs temporarily, then the task would pick up the modified value and not log its execution as expected... Nov 18 09:59:42 Saur: since this particular event is at BuildCompleted, there should be no other task running Nov 18 10:15:09 Morning all, when I build ${CORE_IMAGE_BASE_INSTALL} with INCOMPATIBLE_LICENSE = "GPLv3", I got the following issue : "libreadline.so.6 is needed by bluez4-4.101-r3.armv7a_vfp_neon" (libreadline.6 is gplv3 but libreadline.5 is not). Anyone got an idea? What exactly happen? This error appear when pkg is build doesn't it? Nov 18 10:37:13 TuTizz: Did you set INCOMPATIBLE_LICENSE on an existing build? Nov 18 10:40:48 RP, I did it with core-image-minimal.bb on IMX6 platform (bluez available as default) packagegroup-core-boot + packagegroup-base-extended Nov 18 10:45:07 good morning Nov 18 10:54:40 this file "/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/bluez4-4.101-r3/pkgdata/runtime/bluez4" contain FILERDEPENDS_/usr/bin/gatttool_bluez4: libreadline.so.6 which part of yocto create this file? Nov 18 11:10:13 hello, yocto -c fetchall in dora doesn't seems to fetch git (or even all the tarballs), is it a known bug or i'm doing something wrong ? Nov 18 11:58:02 tid: git-native is in ASSUME_PROVIDED these days Nov 18 12:02:52 rp : hum.. :) that mean ? Nov 18 12:03:37 tid: I guess I don't follow your question then. Why do you think fetchall should fetch git? Nov 18 12:03:46 oh, i mean -c fetchall doesn't seem to fetch git files from recipes (so i can built it online) Nov 18 12:03:52 offline Nov 18 12:04:33 tid: which recipe did you -c fetchall for? Nov 18 12:04:46 my image recipe Nov 18 12:05:00 tid: and DL_DIR/git2 was empty? Nov 18 12:05:13 it's a minimal one with some added packages. Nov 18 12:05:16 nop Nov 18 12:05:25 the files are here you are right Nov 18 12:05:43 but still the build fail it try to fetch my kernel on github Nov 18 12:06:39 tid: are you using AUTOREV? Nov 18 12:06:50 yup Nov 18 12:07:06 SRCREV = "${AUTOREV}" in the recipe Nov 18 12:07:08 tid: to work offline, you need to change that to a revision Nov 18 12:07:25 something like SRCREV = "3.5" Nov 18 12:07:29 ? Nov 18 12:07:40 tid: a git hash Nov 18 12:07:49 hum Nov 18 12:07:52 tid: i.e. the revision you want to build Nov 18 12:08:41 oki :) I try that thanks a lot :) Nov 18 12:31:54 RP: Would something like this http://pastebin.com/EjgMF2K1 be acceptable as a workaround for buildhistory_commit() logging to stdout when BB_VERBOSE_LOGS is enabled? Nov 18 12:32:36 Saur: that hacks around bitbake internals so no :( Nov 18 12:32:41 tid: (you need to use a hash as otherwise it has to go to the repo and see what that tag/branch refers too) Nov 18 12:33:19 bluelightning: Saur has an interesting problem with buildhistory. The use of exec_func from a task handler leads to unexpected output on stdout with BB_VERBOSE_LOGS Nov 18 12:48:41 RP: should I be using something other than exec_func? Nov 18 12:49:46 bluelightning: good question. The trouble is all the logging setup happens in exec_task which usually wraps exec_func Nov 18 12:50:05 bluelightning: we did that since we wanted logs per task, not per function Nov 18 12:50:38 from an event handler, this is a bit trickier... Nov 18 12:56:13 rburton : oki thx too. Nov 18 14:37:39 rp : replacing AUTOREV solved it thanks a lot, maybe a note on the documentation could help some others :) Nov 18 14:38:11 tid: is there a particular place you'd mention this? Nov 18 14:39:16 http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html where -c fetchall is mentionned :) Nov 18 14:40:03 tid: hmm, adding things about AUTOREV in the quickstart isn't ideal :/ Nov 18 14:40:54 if anything I'd say the quickstart needs to be pared down Nov 18 14:41:41 bluelightning: agreed. Perhaps we can move this to another manual section Nov 18 14:43:27 tid: I've passed the comment to our tech writer Nov 18 14:46:51 thx! perhaps this could be avoid by caching the autoref ... Nov 18 14:48:14 autorev should be avoided in general unless you have a urgent need for it Nov 18 14:50:34 that's a solution ^^ Nov 18 15:12:38 bitbake does cache it, and you can set a variable to make it use the cache as is instead of checking for the currnet values, but of course that'll only help if you've done at least one build first to populate the cache Nov 18 15:12:42 * kergoth yawns Nov 18 17:01:07 jackmitchell: fixed the jsonc parallel problem. a net reduction in character count. Nov 18 17:01:36 rburton: awesome, what was it? Nov 18 17:01:55 it seems the configure cruft problem is also fixed in master which is good Nov 18 17:18:54 what's the variable keeping the name/version of the recipe? Nov 18 17:19:51 Krz-: ${P} ? Nov 18 17:31:30 haha, "P" as in "reciPe" Nov 18 17:37:06 RP: yeah, that would be this one, thanks Nov 18 17:39:47 P is PN-PV, basically Nov 18 17:41:01 Depending on where it is being used, you might need to use BP, which is base name without any multilib prefixes. Nov 18 17:41:32 Krz-: sgw_ is right, you may want ${BP} Nov 18 17:41:53 tlwoerner: its the common part of PN-PV-PR :) Nov 18 17:44:09 RP: i understand (and partially agree with) the decision to not try to convert P's into R's, but part of me wishes we could still have a flag day and do the conversion :-) Nov 18 17:44:33 It's inheritance from portage, no? Nov 18 17:44:56 mario-goulart: correct Nov 18 17:45:24 tlwoerner: actually all the R* variants take package names, the P* ones don't Nov 18 17:45:36 tlwoerner: so there is a significant difference Nov 18 17:50:08 RP: there are R* variants of PN, PV, PR? Nov 18 17:50:19 tlwoerner: no Nov 18 17:51:38 moin Nov 18 17:52:18 (INCOMPATIBLE_LICENSE = "GPLv3") RP, yep that was that I changed my local.conf on a existing build. I cleaned all my directory and that work now Nov 18 17:52:53 RP: ah, i see. thanks Nov 18 17:53:31 TuTizz: good to know, thanks. I guess we should try and sanity check this more... Nov 18 17:53:47 bluelightning: something to add to sanity.bbclass do you think? Nov 18 17:54:45 RP: could be yes Nov 18 17:55:08 bluelightning: along with maybe DISTRO_FEATURES... Nov 18 17:55:51 RP: I think we might not be popular if we did that... Nov 18 17:56:30 bluelightning: does changing DISTRO_FEATURES in tmpdir work though? Nov 18 17:57:24 it ought to these days, but I'll admit I haven't thoroughly tested it Nov 18 17:57:26 sort of, if you're careful Nov 18 17:57:40 mess with the systemd feature and you'll be cursing not wiping for hours later Nov 18 17:57:59 (hey guess why i wrote a wipe-deploy script) Nov 18 17:58:39 out of tree builds helps a lot but its not perfect Nov 18 17:58:59 * mr_science hacked a few things to keep it out of the rpi build... Nov 18 18:42:26 tlwoerner, RP: technically, there are "R" variants of PN, PV, and PR, they just aren't using that exact naming :) PKG, PKGV, and PKGR on a per-package basis ;) Nov 18 18:45:31 kergoth: interesting! should those be in the ref-manual? Nov 18 18:45:33 kergoth: good point :) Nov 18 18:46:52 tlwoerner: 90% of the time one doesn't have to set them, they're just internal, with a couple exceptions Nov 18 18:47:08 but there's a certain amount of value in knowing about their existance Nov 18 19:08:08 how can i include a simple, insecure network shell (telnet or similar) for debugging in my image? ssh key pair generation is taking too long Nov 18 19:08:24 (yes, i know insecure shells are bad, but it won't be in my final image) Nov 18 19:08:52 (also i meant host key, not key pair) Nov 18 19:09:41 if you don't care about security, you could always pre-generate the host keys. but i do think setting up a telentd would be doable.. busybox provides one, though i dont know if there's a init script to startit Nov 18 19:09:44 in oe-classic there was a telnet package Nov 18 19:10:26 like kergoth said, part of the busybox build Nov 18 19:10:34 er, telnetd even Nov 18 19:11:01 we've played with pregenerating ssh host keys before, when using read only rootfs, as an alternative to generating them on every boot Nov 18 19:11:45 using busybox or openssh? Nov 18 19:12:38 hmm, found an initscript-telnetd.bb recipe Nov 18 19:13:41 literally just installs the intscript, so telnetd must also be packaged I would think... Nov 18 19:14:00 check your busybox recipe/packages Nov 18 19:16:17 mr_science: where can i find this recipe? the only telnet related thing i could find in Poky was inetutils Nov 18 19:16:45 also, i believe i have to modify BB's config to build telnetd? is there a "clean" way to do that? Nov 18 19:16:51 sorry, i mean busybox, not bitbake Nov 18 19:17:36 kergoth: also, is there a pre-existing system for pre-generated ssh host keys? that would solve my problem just as well Nov 18 19:18:07 (and yes, the problem is, as you say, that i have a read-only rootfs, and key generation kinda doubles boot time) Nov 18 19:24:36 nm, looks like image.bbclass does it automatically with read-only-rootfs in IMAGE_FEATURES. thanks for pointing me in the right direction Nov 18 19:25:37 np Nov 18 19:28:30 uh, that's IMAGE_FEATURES += "read-only-rootfs" in my image recipe, right? Nov 18 19:28:55 that'd be the usual place, yeah, but obviously bitbake doesn't really care where it's defined, as long as it ends up in the variable :) Nov 18 19:29:18 thx, rebuilding now Nov 18 19:32:35 Hi there Nov 18 19:38:16 BCMM: if it's not in current yocto/poky it's easy enough to port the initscript recipe Nov 18 19:38:50 you'll have to tell me about the busybox side since i only have classic handy Nov 18 19:39:10 olus i need to run some tests on the new build... Nov 18 19:41:39 by any chance has someone successfully cross compiled mysql connector for yocto? Nov 18 20:10:47 Hi All, anyone have any experience with connman and wifi? Nov 18 20:16:47 anyone home? Nov 18 20:33:04 hmm, turns out i was wrong, because i was reading a patch that I didn't realise didn't get accepted Nov 18 20:34:47 is there a way to search http://patchwork.openembedded.org? Nov 18 20:39:46 yes Nov 18 20:40:05 select project, use "Filter" link Nov 18 20:49:38 * mr_science sets the "you can check in, but you can't leave" trap Nov 18 20:58:29 JaMa: thanks Nov 18 21:13:31 i don't entirely understand how PROVIDES works - how would i install dropbear sshd, but not the ssh client? dropbear's recipe has: RPROVIDES_${PN} = "ssh sshd" Nov 18 21:15:02 you wouldn't, as the rprovides indicates, the package provides both. but if you install the openssh client on top of it, the alterantives mechanism would likely prefer the openssh client. also, iirc dropbear uses one combined binary for both client and server ala busybox, but i 'm not sure on that Nov 18 21:15:07 * kergoth shrugs Nov 18 21:17:46 i meant, i didn't need any ssh client Nov 18 21:26:31 might be easier to prefer openssh instead Nov 18 21:45:15 BCMM: http://paste2.org/5C304gLP Nov 18 21:45:56 oh wait, lemme paste the initscript too Nov 18 21:47:43 mr_science: thanks, but i've already got dropbear working, plus a seperate recipe for my keys Nov 18 22:05:06 http://paste2.org/kf7z1zYv Nov 18 22:05:15 oh, too late... Nov 18 22:06:13 it is kinda old and cheesy tho Nov 18 22:07:12 i tried hard to convince the manufacturing guys they should use ssh but their old comm software only works with telnet... Nov 18 22:15:58 BCMM: it's also an easy change to just switch to openssh-server if that helps Nov 18 22:17:00 IMAGE_FEATURES += "ssh-server-openssh" and rebuild Nov 18 22:17:04 done Nov 18 22:33:19 mr_science: thanks Nov 18 23:24:42 kergoth: is there a back-up to anonscm.debian.org for the certificates, that machine which also serves alioth also and had hardware failure last week. Nov 18 23:26:16 hmm, not sure Nov 18 23:26:53 kergoth: ok, just checking to see if you knew, thanks. **** ENDING LOGGING AT Tue Nov 19 02:59:59 2013