**** BEGIN LOGGING AT Mon Jan 19 02:59:58 2015 Jan 19 04:51:21 anyone have a kernel recipe pointing 3.19-rc4 or later? Jan 19 04:52:31 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/ looks like it has 3.19-rc5 Jan 19 09:30:53 morning all Jan 19 09:33:44 howdy Jan 19 10:20:04 howdy! i'Ve got a package where i need to debug the configure step. so my thought was to use externalsrc, and being able to retry as often as i need to Jan 19 10:21:03 but i looks like it gets cached somehow. any pointers on how to have bitbake -c configure just starting cleanly over each time? Jan 19 10:26:33 LetoThe2nd: do_configure gets stamped as normal when you use externalsrc - you can use -c configure -f (or -C configure) to force it however Jan 19 10:27:21 if you really want you can set do_configure[nostamp] = "1" in your recipe / a bbappend to have it always run Jan 19 10:28:50 bluelightning: hm ok. and i have INHERIT += "externalsrc" as well as EXTERNALSRC_mypackage = "/my/path" in local.conf, right? Jan 19 10:29:25 EXTERNALSRC_pn- yes Jan 19 10:29:52 pn-? Jan 19 10:31:03 the override to apply only for a specific recipe (PN, to be precise) is _pn- e.g. EXTERNALSRC_pn-gettext = "/path/to/srctree" if the PN of the recipe you want to apply it to is gettext Jan 19 10:32:01 that works for any variable Jan 19 10:32:11 i see, did that change recently? Jan 19 10:33:02 no, we've had that for a very long time Jan 19 10:33:18 hm. my package is name libfoobar for example. so verbose, it really shuold be 'EXTERNALSRC_pn-libfoobar', not 'EXTERNALSRC_libfoobar', right? Jan 19 10:33:27 yes Jan 19 10:33:31 gotcha. Jan 19 10:34:54 seems this does the trick, thanks. :) Jan 19 10:36:32 so deciding to postpone it until monday #yocto office time was the correct choice yesterday 6am instead of wasting more time ;) Jan 19 10:46:48 heh Jan 19 10:47:32 I am occasionally on over the weekend, but not always paying attention Jan 19 10:49:54 i would want anybody spending his sundays over my $orkplace problems. its enough if i do. Jan 19 10:53:27 s/would/wouldn't/ Jan 19 11:04:16 hm. "This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities." Jan 19 11:04:35 is there some possibility to find out *what* exactly triggered the message? Jan 19 11:04:57 the configure step did work fine just a moment ago from externalsrc Jan 19 11:14:57 LetoThe2nd: see config.log, look for "unsafe for cross-compilation" Jan 19 11:20:05 bluelightning: the only thing i see is configure: WARNING: using cross tools not prefixed with host triplet Jan 19 11:20:53 LetoThe2nd: is that in log.do_configure or config.log? Jan 19 11:21:37 bluelightning: log.do_configure Jan 19 11:22:07 LetoThe2nd: right, when checking for that error the QA check is looking at config.log, so you'll need to look there Jan 19 11:22:30 ah gotcha Jan 19 11:22:44 we really ought to just re-print the error text Jan 19 11:24:01 dang, exactly what i feared. the libboost detection i use seems to be b0rk3d Jan 19 12:11:29 Hi bluelightning. Do you happen to know what the registry fields in http://layers.openembedded.org/layerindex/api/layerDependencies/ mean? Jan 19 12:12:16 mario-goulart: registry? Jan 19 12:12:24 records, sorry. Jan 19 12:13:26 bluelightning: I mean, what's "id" in that context? Jan 19 12:13:53 mario-goulart: id is just the id of the layer dependency record, it's not particularly useful outside of the database Jan 19 12:14:52 bluelightning: oh, I see. I think I get it now. Thanks. Jan 19 12:15:32 layerbranch is a pointer to the layerbranch record for which the dependency is recorded, but dependency is a pointer to the layer that it depends upon (note that branch-specific and non-branch-specific data is kept in separate tables) Jan 19 12:16:14 mario-goulart: you may find this useful as a reference for the database structure: http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/tree/layerindex/models.py Jan 19 12:16:29 Cool. Thanks. Jan 19 12:41:58 Hi, could different compiling hosts be able to share sstate cache? Noticed that my Debian unstable one wasn't used by an Ubuntu container based build. Jan 19 13:26:43 Hi, is somebody using OpenEmbedded with busybox init instead of sysvinit/systemd? Jan 19 13:27:46 I could not find any information about this in the docs Jan 19 15:37:36 is there a recommended way to copy with packages that use autoconf, but not automake? e.g. that ship with a Makefile.in? Jan 19 15:38:46 s/copy/cope/ Jan 19 15:39:16 and it seems to have issues with inherit autotools Jan 19 15:52:05 LetoThe2nd: Did you try autotools-brokensep instead? Jan 19 15:54:55 bachp_: hehe. actually i did, but externalsrc bit me. just the very same moment you asked me, i retried in the proper way ;) Jan 19 15:57:55 bachp_: compiles now, just needs fixing the install stage. hooray! Jan 19 16:06:05 Glad to hear it's working Jan 19 17:18:20 Hi, can someone please explain the use of KFEATURE_COMPATIBILITY in .scc files ? Jan 19 17:21:14 eg: http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-kernel/linux/linux-yocto/xen.scc Jan 19 17:21:52 it's documentation. some external tools use it to decide if optional fragments are presented to users as valid. Jan 19 17:25:46 zeddii: ok, thanks .. Jan 19 18:18:07 hi. is there an edison layer ? Jan 19 18:18:36 I want to try to build meta-tizen for the edison Jan 19 18:34:32 I think there are meta-edison* layers that you can download from Intel's Edison software site. Jan 19 18:34:51 Not sure if there is any caveats. Haven't used it. Jan 19 18:40:53 * Crofton|work grumbles Jan 19 18:40:54 ERROR: Task do_configure in /home/balister/src/oe-core/oe-core/meta/recipes-kernel/lttng/lttng-modules_2.5.2.bb depends upon non-existent task do_shared_workdir in /home/balister/src/oe-core/oe-core/meta/recipes-kernel/linux/linux-dummy.bb Jan 19 18:40:58 zeddii, any ideas? Jan 19 18:42:13 yay for random log-outs Jan 19 18:43:09 trip0: 10:33 < Sid_H__> I think there are meta-edison* layers that you can download from Intel's Edison software site. Jan 19 18:43:12 10:33 < Sid_H__> Not sure if there is any caveats. Haven't used it. Jan 19 18:44:23 Crofton|work. aha. yah, you'd be the first person that linux-dummy was used and it doesn't have our new routine. I can add it to linux-dummy, but obviously that lttng-module build wouldn't work afterwards anyway. Jan 19 18:44:47 thx, ulf` Jan 19 18:45:06 and thx Sid_H__ Jan 19 18:45:21 I don't really care, just need something to boot on another kernel Jan 19 18:46:24 lttng modules shouldn't be building at all. if it was before, and against linux-dummy .. something odd is going on. Jan 19 18:46:41 hmm Jan 19 18:46:46 hmmm https://www.yoctoproject.org/releases-yocto-version/yocto-project-11-edison Jan 19 18:48:33 tools-profile Jan 19 18:48:56 and in your build, you don't have a kernel defined. like you mentioned. it is from somewhere else, right ? Jan 19 18:49:11 yeah Jan 19 18:49:16 I copy from an older build Jan 19 18:49:24 haven't made it build with new gcc Jan 19 18:49:34 old kernel, new gcc issue I never solved Jan 19 18:51:43 gotcha. the dummy kernel should have that task .. or the kernel.bbclass needs a fallback .. but whatever garbles out of lttng modules would fail anyway. Jan 19 18:51:44 hmm. Jan 19 18:52:49 well I use tools-profile, so it gets sucked in Jan 19 18:53:06 wait a minute... "Edison" happens to also be the name of a yacto release (v 1.1). Jan 19 18:53:09 that's not what I want. Jan 19 18:54:26 zeddii, with any luck a dizzy build will work and solve my actual problem Jan 19 18:54:37 jsut ran a test against master and found the issue there Jan 19 18:54:55 k. but I'm adding the default ask now as well. Jan 19 19:11:46 https://fosdem.org/2015/schedule/event/ohr_fpga/ Jan 19 19:12:29 Tizen is "Yocto-enabled" Jan 19 20:12:26 what's the easiest/best way to disable netfilter? i see that even tiny configurations includes ip_nf.scc, so i would have to explicit disable it in a config fragment. is there any other way to do it? Jan 19 21:14:40 trip0: regarding the edison bsp layers https://lists.yoctoproject.org/pipermail/meta-intel/2015-January/002886.html Jan 19 21:15:35 trip0: this email has links directly to the Edison BSP tarball and an import of it's contents and patches to linux-yocto-3.10 https://lists.yoctoproject.org/pipermail/meta-intel/2015-January/002885.html Jan 19 21:30:14 hippiehacker: cool. thx Jan 19 21:31:39 hippiehacker: so the merger has not happened yet? Jan 19 21:33:02 I haven't heard anything from Intel yet, though I'm hoping I'll hear something soon: https://communities.intel.com/message/274398#274398 Jan 19 21:33:30 "Hello @hippiehacker, Please post all your feedback and concerns about the Edison BSP in this thread. We will get in contact with the team in charge of the Edison BSP and we will inform them about your concerns. Intel_Peter." Jan 19 21:34:57 Anyone building a BSP against 3.19 yet? I'm really wanting some features out of it (Edison is currently on 3.10.17) Jan 19 21:36:00 I want to create a usb gadget that looks like a keyboard (hid), ethernet (rndis), and disk (mass_storage), and be able to swap out what is exported via mass_storage without killing rndis or the keyboard. Jan 19 21:36:28 * ulf` tries to find out who intel_peter is Jan 19 21:37:27 warthog9: Do you know who intel_peter is? Jan 19 21:37:35 warthog9: https://communities.intel.com/message/274398#274398 Jan 19 21:37:52 So you could plug the edison into a computer, power it on, and the edison (via usb keyboard/hid) would select from the bios to boot from usb disk, which might contain ipxe, which can boot from usb rndis Jan 19 21:37:56 https://communities.intel.com/people/Intel_Peter Jan 19 21:39:07 ulf`: looking Jan 19 21:39:22 ulf`: no idea Jan 19 21:42:33 hippiehacker: I can't even register on that site. It doesn't like my captcha responses in Chrome :) Jan 19 21:48:42 Doesn't seem to work in either browser Jan 19 21:48:45 * ulf` emails them Jan 19 21:50:45 Hi dvhart **** ENDING LOGGING AT Tue Jan 20 02:59:59 2015