**** BEGIN LOGGING AT Mon Nov 16 02:59:58 2015 Nov 16 06:43:58 morning all Nov 16 11:12:40 hallo, i have a trouble with populating a sdk. the command i use is "bitbake -C populate_sdk" the error i receive is from binutils "configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69.". wich is the right way to solve the problem? just write a patch for configure.ac isn't the right thing to do, i think. Nov 16 11:33:54 the configure step of a software i am packaging fails with Nov 16 11:33:57 ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Nov 16 11:34:26 looking through the configure.ac i see a lot of hardcoded references to /usr/local, /opt/local, etc... Nov 16 11:34:54 how can I prefix these so that they reference the yocto sysroot? Nov 16 11:35:01 or rather should I? Nov 16 12:02:04 hi Nov 16 12:03:02 it is possible to have in one layer 2 bbappends for one recipe but for different machines only (I've added COMPATIBLE_MACHINE for bot but it's not working) Nov 16 12:14:46 hi all Nov 16 12:15:28 how could i force all tasks starting from do_configure to run for a package? Nov 16 12:15:51 (while trying to debug an issue by directly modifying the fetched source code.) Nov 16 12:17:37 oh... bitbake -c configure -f followed by bitbake might be sufficient Nov 16 12:23:46 Ulfalize1: -C Nov 16 12:24:08 -C is "invalidate the stamp for a specific task and then run do_build" Nov 16 12:24:22 so bitbake foo -C configure will re-run configure and everything after it Nov 16 12:51:09 anyways it's possible to 2 bbappends for one recipe? Nov 16 13:33:19 marek_: yes Nov 16 13:34:46 drou: can I use also different COMPATIBLE_MCHINE for both of them? Nov 16 13:35:15 drou: because it seems it's doing problems Nov 16 14:45:47 hi guys, quick question: I have ofono on my target image, and I don't know why Nov 16 14:45:59 1) how can I easily know who is adding it to the image? Nov 16 14:46:11 2) how can I remove packages from the image? Nov 16 14:46:16 some blacklisting or similar Nov 16 14:46:56 without avoiding the "inherit core-image" Nov 16 15:17:23 Hi. I'm an Archlinux user and I have to bring a software project to Yocto. I've heard that Nov 16 15:18:14 Hi. I'm an Archlinux user and I have to bring a software project to Yocto. I've heard that Yocto is different from other distros but I didn't find what the differences are exactly. Nov 16 15:18:26 Is there a list of major differences? Nov 16 15:18:36 Is the package management different? Nov 16 15:20:31 I know that Yocto is easier to be built small and optimized for certain devices but assuming I include this 'smart' package manager, is there any real different between the image I built and any other distibution? Nov 16 15:29:27 SoleSoul: The smart package manager is a front-end for rpm. It's kind of like yum, zypper, apt, up2date, etc. Nov 16 15:30:06 SoleSoul: when you enable package management, the default is rpm... but you can also select deb,, ipk, or even tarballs (I think). Nov 16 15:32:25 SoleSoul: IMHO, Yocto's strong suit is in generating complete OS images. While the package management systems work well, I don't think they're up to par with big distros like Fedora, Ubuntu, and Debian. Nov 16 15:32:55 And by "work well" I mean "always leave the system in a good and repeatable state." Nov 16 15:33:25 gabrbedd: Thanks. So it's basically a normal distro, but it's easier to create images from. Nov 16 15:33:53 your last comment about leaving the system in a good state is important. So it's not meant for a day to day use Nov 16 15:34:55 i see the value as something in which you're in control. you don't take debian or redhat or whatever and customise it, at the whim of their control Nov 16 15:34:59 gabrbedd: Do I have multiple package repositories to choose from or is there a main one (or only one)? Nov 16 15:35:15 SoleSoul: that's up to you, as you'll be building the repos Nov 16 15:35:24 I can't tell you what the upstream folks /indend/ for package mgmt, but _I_ wouldn't try to use Yocto like I use Debian: with binary package updates to my system. Nov 16 15:36:04 SoleSoul: I would say "So it's basically a normal distro, but it's easier to create CROSS-COMPILED images from." Nov 16 15:36:23 rburton: Is there a main repo? Nov 16 15:36:33 that someone has already built? Nov 16 15:36:42 SoleSoul: not really. Nov 16 15:36:54 SoleSoul: angstrom has one, but thats only if you want to run the angstrom distribution Nov 16 15:36:55 gabrbedd: what if I need a newer gcc (which I already do)? Nov 16 15:37:05 the entire point is *you* build the distro you want Nov 16 15:37:34 SoleSoul: the 2.0 release has gcc 5.2, is that new enough? Nov 16 15:37:43 as you can see, I'm still trying to understand the concept. Thanks for your patience. Nov 16 15:37:51 rburton: yes it is Nov 16 15:37:56 I have 4.9 here Nov 16 15:38:05 "it's not a linux distribution, it lets you build your own linux distribution" Nov 16 15:38:39 rburton: yeah I got that part but I thought that if I take an already built image I could roll with it just as I do with other distros Nov 16 15:39:00 SoleSoul: The canonical Yocto repositories all have "bitbake recipes" -- these are like Gentoo ebuild descriptions. Nov 16 15:39:29 gabrbedd: This concept I do know. I've used Gentoo before. Nov 16 15:39:36 SoleSoul: as a matter of breaking up the problem and re-using previous compiles, it also will use some packaging tools (RPM, DEB, IPK) to generate the emages. Nov 16 15:39:52 SoleSoul: sure, start from poky or angstrom or something, but building an image is sufficiently fast that you might as well start from scratch Nov 16 15:40:32 (scratch being from sources, and not from an existing image) Nov 16 15:40:38 rburton: maybe I should try building a new image to understand what's going on even if I'm not going to use it. Nov 16 15:40:43 yes Nov 16 15:40:57 SoleSoul: I've worked on an OpenEmbedded-based system where we used IPK's for updates. We created our own package repositories. Nov 16 15:41:26 SoleSoul: the poky quickstart is a good introduction - gets you building an image for the poky distro (the reference distro for QA purposes) nice and quickly. then you can take that wherever you want. Nov 16 15:41:35 gabrbedd: the only 'embedded' linux I used was OpenWRT and it does have compiled packages so this is new to me. Nov 16 15:41:40 SoleSoul: it generally worked OK when we upgraded things... but pre-install and post-install scripts became problematic for us since we needed a high-reliability upgrade. Nov 16 15:42:04 yeah for reliability you don't want packages, you want whole-image updates, secondary images, and rollback Nov 16 15:42:06 gabrbedd, this is why both RPM and IPK (and deb) are supported.. Nov 16 15:42:16 not quite trivial Nov 16 15:42:34 rburton you can do high reliability with packages -- but -- you need to be smart about it and control how the upgrade happens.. Nov 16 15:43:02 secondary images (or at least a maintenance image) is often used to facilitate that.. Nov 16 15:43:07 why isn't there a central binary repository? Is it against Yocto's purpose? Nov 16 15:43:16 SoleSoul: yes Nov 16 15:43:32 why wouldn't I want that? Nov 16 15:43:39 the problem is that you need to weigh the download of the update against the reliability factor and make smart decisions.. if the image is 1 MB, easy do an image.. but if the image is 1 GB.. then packages are much better.. Nov 16 15:43:46 SoleSoul: because who is to say that your systemd package has the same options as mine? Nov 16 15:43:51 SoleSoul, this is where the 'custom distribution' part fits in.. Nov 16 15:44:01 SoleSoul: it becomes pointless once you do not use pre-defined machines or architectures. Nov 16 15:44:03 SoleSoul: think about Gentoo's USE flags. Bitbake uses something like them -- and it makes the binary packages slightly incompatible. Nov 16 15:44:12 The example configuration for the YP's systemd, bash, coreutils, etc may be different then your needs.. Nov 16 15:44:21 SoleSoul: which in turn is exactly what most OE/YP users actively want Nov 16 15:44:26 so there is no one way to do things Nov 16 15:44:38 SoleSoul: sounds like you actually want angstrom or such. Nov 16 15:45:00 Thank you all for the answer :) Nov 16 15:45:16 LetoThe2nd: Not necessarily, I'm just trying to understand the concept Nov 16 15:45:49 SoleSoul: just think about - "what binaries do you want to provide if you have to assume that every single user has a different architecture". Nov 16 15:46:09 LetoThe2nd: Yeah I think I get it. Nov 16 15:46:17 :-) Nov 16 15:46:53 I have a client who has a built of Yocto which he builds himself. Before sending him my sources I want to make sure that my application works on Yocto. I got an image of Yocto that my coworker built and it misses some things I need. That's where my questions came from. Nov 16 15:47:22 SoleSoul: the problems all come from the mindset "image of yocto" Nov 16 15:47:34 what's wrong about it? :) Nov 16 15:47:40 SoleSoul: that it doesn't exist. Nov 16 15:47:55 it's for a specific hardware build which we both use. Nov 16 15:48:15 me and my coworker Nov 16 15:48:21 the client will get sources Nov 16 15:48:23 SoleSoul: your problem is more like this. "my customer has a linux image, and my coworker has a linux image. they are different." Nov 16 15:48:39 they just used a similar mechanism to build it. Nov 16 15:49:00 distro, machine, and image are orthogonal concepts in these build tools. what packages go into the image is largely independent of what the target board happens to be. much as multiple desktops can run ubuntu but have entirely different packages installed, only more so, since build configuration is more of a factor Nov 16 15:49:02 * kergoth yawns Nov 16 15:49:02 hardware only affects the kernel configuration and the format of the resulting ELF binaries.. Nov 16 15:49:19 but it doesn't explain how things were configured and the overall system design issues you may have selected.. Nov 16 15:49:28 as kergot said, these are all orthogonal concepts... Nov 16 15:49:28 SoleSoul: just like "see, i've got this 18-wheeler, and my friend has this sports car. why don't my tyres fit there? they both have an engine, so its both suposed to be a car!" Nov 16 15:49:41 LetoThe2nd: Actually, the customer knows more about Yocto than I do. He'll be fine. I'm trying to understand how to make a testing/development machine for myself Nov 16 15:50:10 You need to establish a configuration.. one that specifies the BSP and distribution settings you and your customer agree on.. Nov 16 15:50:13 SoleSoul: ask him for a copy of the image, or access to his layers and configuration so you can repeat his build Nov 16 15:50:22 SoleSoul: then ask your customer to provide you with the sdk that he wants you to use. Nov 16 15:50:23 then you select one or more image recipes that have the filesystem confgiuration.. Nov 16 15:50:28 then you'll both be on the same page Nov 16 15:51:31 Sounds logical. Thanks Nov 16 15:53:17 It's so nice to have an irc channel on a topic I'm interested in. Nov 16 15:53:58 I'll be going now. I really appreciate your help you'all :) Nov 16 15:54:05 * armpit work build ate my disk.. again Nov 16 15:54:09 Time to do some homework on the topic Nov 16 15:59:00 quick poll Nov 16 15:59:10 there's a series on the list to fix five CVEs in libav Nov 16 15:59:15 one patch per cve Nov 16 15:59:46 as in each cve fix is a patch to the recipe, and each patch is added in an independent commit to the recipe Nov 16 16:00:05 should these be squashed so one commit to the recipe adds all five fixes (in separate files) Nov 16 16:00:16 (I'd be fine with one commit -- but one patch per CVE is the best way to handle this in my experience) Nov 16 16:00:33 Yeah, I'd think one commit but one patch per CVE in the layer Nov 16 16:00:35 the commit is and should be considered the logical change. 5 CVEs can be one logical change Nov 16 16:00:37 fray: for reference its poky-contrib/jhuang0/d_libav-cve_151113-1 Nov 16 16:01:03 personally i'd squash it so there's a single commit in oe-core which adds five files Nov 16 16:01:17 *definitely* a patch per cve for analysis Nov 16 16:01:32 if there is a reason to take these patches individually (bisect or otherwise) then multiple commits.. otherwise I'd be fine squashing -- OR -- keeping them individual.. doesn't really matter as long as the system works with one or all Nov 16 16:01:40 if 'all' is required, then they should be squashed Nov 16 16:01:58 hm the upstream-status is wrong too Nov 16 16:03:10 huh Nov 16 16:03:23 a libav cve, fixed with a patch from ffmpeg Nov 16 16:03:28 not sure we have a upstream-status for that Nov 16 16:03:32 Upstream-Status: Disaster Nov 16 16:04:57 I wouldn't squash them. Nov 16 16:05:21 the fixes for one CVE might evolve or change or turn out to be wrong. Nov 16 16:05:38 they might get fixed upstream at different times. Nov 16 16:05:57 if you squash them you'll have to unpick the patch if any of that happens. Nov 16 16:05:58 fledermaus: the cve fixes themselves would still be separate files Nov 16 16:06:13 oh right. Nov 16 16:06:14 just the commit to oe-core would add five patches, instead of five commits with a patch each Nov 16 16:06:20 fine whatever then :) Nov 16 16:06:27 yeah hard to have a strong opinion Nov 16 16:06:39 my main argument for squashing is length of commit log :) Nov 16 16:08:42 speaking of which Nov 16 16:08:45 libav vs ffmpeg Nov 16 16:08:47 FIGHT! Nov 16 16:09:26 whoever wins, we lose? Nov 16 16:11:04 having a commit per cve allows users to cherry pick what they want Nov 16 16:12:05 not all issues are equal Nov 16 16:12:48 meh, they can tweak the bb file to drop a patch just as easily. Nov 16 16:14:37 armpit: that's a fair point. i would expect folks who want updates to stable branches would likely want all security fixes, but it depends on how risk averse they are and which form of risk is most concerning to them, security or potential breakage :) Nov 16 16:14:50 meh Nov 16 16:16:24 its more of an issue once our customer deply. they only want the high and critical changes only.. but that is more of my problem.. just trying to save me time Nov 16 16:19:03 * kergoth nods Nov 16 16:19:07 makes sense Nov 16 16:23:14 * kergoth thinks devtool's oe-local-files should really just be source controlled in the repo alongside our patches, then changes to them could be tracked when using e.g. devtool sync Nov 16 16:23:22 s/patches/changes from our patches/ Nov 16 16:47:47 is there an environment variable I can use to make ${PN}-cross-${MYARCH} or is there a variable that will be MYARCH? Nov 16 16:48:00 I'm trying to avoid hardcoding x86_64 in my layer because I know that's not correct Nov 16 16:52:18 look at one of the existing recipes. there's a PN .= line in all the cross reicpes that append an architecture Nov 16 16:52:43 kergoth: thanks. Nov 16 16:53:00 Another stupid question... what's really the need of the cross packages? Nov 16 16:53:12 I'm wondering if this layer is totally screwed up Nov 16 16:53:29 It's building the Rust language and it builds rust-native, rust-cross-x86_64 and rust Nov 16 16:53:38 A cross recipe is built to run on the host but target the target architecture. It's how you build a crosscompiler toolchain that runs on teh build machine but emits binaries for the target Nov 16 16:53:59 alright Nov 16 16:54:25 So I probably want rust-native and rust-cross to build but not rust for a package. Nov 16 16:54:36 The compiler isn't necessary to execute packages on the target. Nov 16 16:54:58 if you never want to support on target development with rust, sure Nov 16 16:56:05 Well if I write a program in Rust, it shouldn't depend on rust the package. Just rust-cross Nov 16 16:56:13 Since it gets compiled to native code. Nov 16 16:56:23 Assuming my logic is correct here. Nov 16 16:56:24 that sounds accurate, indeed Nov 16 16:56:40 Last question Nov 16 16:56:55 SECURITY_CFLAGS-pn_rust-cross-x86_64 = "" would be correct? Nov 16 16:57:58 to clear out SECURITY_CFLAGS for rust-cross. Nov 16 17:01:11 it's _pn-, not -pn_ Nov 16 17:01:42 the syntax is generic for anything in OVERRIDES. _. in this case the override is pn-${PN} Nov 16 17:01:53 so yes, SECURITY_FLAGS_pn-rust-cross-whatever would likely do the job Nov 16 17:01:58 er sorry I typoed that Nov 16 17:02:04 but use bitbake -e yourrecipe to examine the final value to make sure it's set to what oyu want Nov 16 17:02:32 Would I use "rust-cross-x86_64" for yourreceipe or just "rust"? Nov 16 17:06:07 as i just said, it' sthe recipe's PN variable Nov 16 17:06:15 which would include the arch, since it's appended to PN Nov 16 17:07:30 kergoth: Ok. thank you. I appreciate your help. Nov 16 17:08:17 np Nov 16 19:24:57 hi team question is there any standard solution to create an IoT newtwork ? from the comunication to the app and analitics point of view ? ( I have just found zatar : http://www.zatar.com/ ) Nov 16 19:30:11 there are a number fo commercial products that assist with this.. Nov 16 19:30:25 (and lots of OSS components to build your own) Nov 16 19:31:00 agree Nov 16 19:31:12 I was just wondering if somethin yocto was involved in Nov 16 19:33:19 not that I am aware of Nov 16 19:33:38 hmm... does do_patch commit each patch to the git tree? Nov 16 19:34:37 or why I got a user.name and user.email not set error during do_patch (they are not set using git config --global) Nov 16 19:39:15 apparently it does git-am Nov 16 19:40:38 gunnarx: depends on what PATCHTOOL is set to, generally Nov 16 19:42:23 ah, ok. Well git-am requires user.name to be set so I'm guessing that's what is happening Nov 16 19:46:04 How does PATCHTOOL play in? meta/lib/oe/patch.py suggests to me git-am is involved anyway Nov 16 19:48:03 I wonder how often this just ends up using whatever is set in git config --global? Should bitbake provide something so the operation doesn't simply fail on a bare machine? Nov 16 19:48:28 ? Nov 16 19:48:37 patch.py has multiple classes that apply patches Nov 16 19:48:39 the git class is just one Nov 16 19:48:44 and is only used when PATCHTOOL is set to git Nov 16 19:49:14 but yes, it should probably add a sane fallback the way buildhistory does (see http://git.openembedded.org/openembedded-core/commit/?id=f62255bfa6c5a322c867b7c4ea5686ea7bfab3fe) Nov 16 19:49:22 ok, fair enough. the failing do_patch is on a git repo anyway Nov 16 19:49:45 yes, looks like same issue Nov 16 19:49:57 just because it's a git repo dioesn't mean git would be use dto apply the patches, unless PATCHTOOL is set to git Nov 16 19:50:03 i'd suggest opening a bug in the yocto bugzilla Nov 16 19:51:11 kergoth: The amount of configuration is amazing. It would be the default to use git as PATCHTOOL for a git repo at least? :) Nov 16 19:51:29 i doubt that would be a very good idea Nov 16 19:51:38 git apply (and therefore, git am) is much picker about applying patches than patch is Nov 16 19:51:48 patch handles fuzz better Nov 16 19:51:51 * zeddii nods Nov 16 19:51:58 switching to git application by default for git repositoiries would cause us patch application failures Nov 16 19:52:13 one might argue that its a net gain to not keep around fuzz in our patches, but that'd have to be a conscious choice Nov 16 19:52:33 do-able for kernel ; not sure about a wider net than that... Nov 16 19:52:35 and a flag day sort of thing. Nov 16 19:53:04 we already took that hit for linux-yocto kernels, but that's a relatively small scope compared to the horrors of userspace and all the layers. Nov 16 19:53:14 agreed. Nov 16 19:55:08 ISTR that you could "tune" git-am to allow the same level of fast-n-loose fuzz that patch allows by default... Nov 16 19:56:08 OTOH, I think I'd rather just see git-am fail and then manually intervene to check things out vs. having crap mis-applied in a section that has nothing but whitespace and curly braces Nov 16 19:56:36 that is typically where I've seen patch fuzz in crap incorrectly ; where the context is vague. Nov 16 19:56:53 agreed Nov 16 19:57:19 I've often seen duplicated sections or entire functions when the only context is a closing } in a previous block or something Nov 16 19:57:28 yep, seen that too. Nov 16 19:57:52 fortunately gcc gets pretty angry about that, even if the meatware at the keyboard missed spotting it. Nov 16 19:59:17 often things like that seem to come up if folks bump versions and blindly test patch application for failures rather than actually checking to see if the underlying issues fixed by the patches were addressed upstream Nov 16 20:01:42 kergoth, paulg : sorry, was off looking at bugzilla. makes sense what you are saying. I'll try to figure out then why this project is (maybe) using git-am, at least that's my theory wrt the error Nov 16 20:07:44 offending recipe sets PATCHTOOL to git seemingly to get support for binary patches. Thanks for leading me to the solution guys. Nov 16 20:09:44 whee. binary patches. :-/ Nov 16 20:09:53 yay Nov 16 20:10:58 yeah some png file. Ought to be fetched but you know, lazy recipe writers. Nov 16 20:14:07 I was going to guess some hideous firmware blob. Nov 16 20:31:43 Question: When I do my yocto build, where is the version of the kernel to use defined? Nov 16 20:33:47 in your local layer conf or your distro conf, look for... Nov 16 20:33:56 PREFERRED_VERSION_linux-yocto ?= <...> Nov 16 20:34:55 kergoth: another potential silly question for Rust. Nov 16 20:35:24 The native can be built with as many targets as necessary. Is there an advantage to building rust-native and rust-cross-${TARGET_ARCH}? Nov 16 20:35:34 or just building all those targets into the native? Nov 16 20:35:59 rust-native isn't even used to build rust-cross-${TARGET_ARCH} Nov 16 20:36:58 if a single build can target any number of archs, i'd think it could do the job and avoid the need for the cross incarnations, but i dont' really know much about rust Nov 16 20:37:40 QEMU is setup similarly, in that we generally build QEMU to support all of the available targets we care about Nov 16 20:39:23 i think go and clang/llvm are along similar lines Nov 16 20:44:35 hi guys Nov 16 20:45:06 thanks @paulg Nov 16 20:45:38 kergoth: Rust is on top of llvm similarly to clang Nov 16 20:45:57 I'll check out how clang is built. Nov 16 20:52:15 So, say you wanted to include the output of one image into another. How would you go about that? Say I have one image that is a PXE server and another image that is an initramfs that I want to embed into the PXE server image. Any advice on how I could go about doing that? Nov 16 20:53:02 jcreekmore: one image depends on the other, the hddimg formats all do this as they embed a initramfs Nov 16 20:53:52 But where would it put that? Would I need to write a custom rule to get it installed into a particular place? Nov 16 20:55:20 rburton: would it be a RDEPENDS or DEPENDS? Nov 16 20:55:27 for jcreekmore's issue Nov 16 20:57:15 has anyone experience this kind of perl issue: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed? i'm not sure about my configuration, i added libio-socket-ssl-perl & libnet-ssleay-perl Nov 16 20:58:21 Cardoe: depends, rdepends are specific to packages Nov 16 20:58:57 jcreekmore: to be honest, assuming your pxe image is just a tarball or directory, that's already supported Nov 16 21:02:44 otavio: https://autobuilder.yoctoproject.org/main/builders/nightly-rpm/builds/522/steps/BuildImages/logs/stdio <— you broke lttng's ptest Nov 16 21:02:52 (clearly i failed to test build that) Nov 16 21:07:38 it seems that im missing something to verify the certificates on my target Nov 16 21:20:35 Is there a package or option I could include or use to cause the -dbg packages for all packages in my image to also be installed? Nov 16 21:22:54 Would anyone happen to be aware of an existing recipe for linux kernel, drm-intel-nightly branch? Nov 16 21:23:16 If not, has anyone ever seen this one pop up? "Failure expanding variable WORKDIR, expression was ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} which triggered exception RuntimeError: maximum recursion depth exceeded while calling a Python object" Nov 16 21:25:05 rburton: thanks, that helped me figure it out. Nov 16 21:26:18 WarheadsSE the message says that something in the way 'WORKDIR' is defined failed, because it somehow become recursively defined.. Nov 16 21:26:40 you should be able to use 'bitbake -e' and look how it is defined.. (as well as bitbake -e ) and compare.. it might help you spot the recusion Nov 16 21:27:59 fishey1: dbg-pkgs IMAGE_FEATURE Nov 16 21:29:21 fray: understood, going spelunking. Nov 16 21:31:07 well, -e results in only that warning. Nov 16 21:36:42 and nothing seems to jump at be about recursion, looking at the set values. Nov 16 21:43:49 * WarheadsSE smh, moved PR= below an inc. Nov 16 21:44:06 * WarheadsSE viola *jazzhands* Nov 16 21:45:21 rburton: thanks Nov 16 22:50:58 G'day all Nov 16 22:51:42 Does anyone know why the meta-intel BSP is missing for the Jethro release? Nov 16 22:52:03 Jethro was released on Tuesday of last week. I'd guess meta-intel isn't ready yet Nov 16 22:52:57 I was thinking that might be the case but seems strange they would put broken links on the YP page (https://www.yoctoproject.org/downloads/bsps) **** ENDING LOGGING AT Tue Nov 17 02:59:58 2015