I'm trying to build a Yocto image for a AWS Greengrass Core Device using meta-aws layer. I'm really new to this topic, so I already stuck at the very beginning... It seems as there are compatibility problems of meta-aws with older Yocto versions.
I've already created an image for my hardware (i.MX8MP processor) and this is running fine. The Yocto version I'm using is Hardknott.
Now I would like to add the AWS features. Hence I've cloned meta-aws layer to my source directory and checked out branch "hardknott" and also added the layer to my Yocto project. But when I try to bitbake the image, I always get parsing errors in severel recipes of meta-aws. The problem is, that in many recipes the "new" override syntax ":" instead of "_" is used, which was introduced with Honister.
I'm really wondering about this, as there is an explicit branch for Hardknott. Why is this branch using a syntax which is not compatible with Hardknott?
Could anybody explain this to me and may have a solution to this?
I already searched in the web, but information about intergrating meta-aws to Yocto project is really rare.
Thanks a lot in advance!
Huh. Well, that's inconvenient. A glance at the repo looks like they updated many of the recipes in the Hardknott branch of meta-aws, but some of those newer recipes use the new syntax, which would break the build as you describe. I'd submit this as an issue to the repo. Otherwise, fix the syntax yourself until it builds. If there are multiple versions of the recipe available perhaps try using PREFERRED_VERSION to select an earlier recipe that may have the correct syntax.
Related
I'm trying to compile the examples under cpp starting with minimal_build. I don't have much cmake experience. Must this be run under docker, or can it just be compiled in a Linux shell? I'm running Centos7 on a AWS EC2 instance, and I've installed cmake 3.20.2. Executing sudo ./run.sh, errors immediately with "cd: /io: No such file or directory". When I try and make what I think are the necessary changes to the scripts, I keep hitting errors. So I just want to see is this is even possible before proceeding further.
Thanks.
Yes, it is possible. I recently built Arrow on CentOS 7. With any C++ project there are going to be challenges switching amongst Linux distributions. The docker image is a way to provide a single example that the Arrow project can verify. You will need to adapt your Linux environment based on the issues you encounter. #Tsyvarev is also correct, you will want to use run_static.sh instead of run.sh. In order to do this you will need to dive a bit further into the details.
The build script has two steps. First, it will build the Arrow project itself. This is probably going to be the more challenging step. This guide is helpful for this step and provides a lot more detail into how Arrow builds and what options there are. The second step will be to compile and build the example.
Specifically for CentOS 7 one of the challenges you will face is that you will need a newer version of CMake. I ended up building CMake from source. If you go this route you also need to make sure that CMake is built with curl/https support. I used the --system-curl option for this.
That is all I remember having to do special for CentOS 7 at the moment. As you go about this task if you run into further, more specific, issues, feel free to ask them here or on the Arrow dev/user mailing list.
I have the latest version of Swiftlint (via brew). When I check github, I see that they have added a bunch of rules since the release, even a few a couple of days ago. How do I get those rules onto my mac? Do I have to uninstall the version I have and reinstall the same version? (will that even get the new rules?) Do I have to download the zip from github?
Use brew update. But some of the new code is not yet in the release branch. For the dev-branch you would need to pull the newest version manually. It is a shame that the new documentation on rules is so poor, because i ran into the exact same problem.
I would suggest waiting until the rules are in release branch and are deployed by brew. Sometimes those rules can be buggy and are not reliable.
An alternative to brew update is to integrate SwiftLint using CocoaPods, and in that case you would update it with pod update.
I recommend the CocoaPods approach as it garanties that all co-developers get the same errors (and warnings), and avoids situations were one developer doesn't get any error, pushes code and confronts another developer to build errors.
Today after updating our projects it seems Xunit.KRunner is no longer available on NuGet. We checked the Microsoft projects and it looks like they are using the xunit.runner.kre package. When trying to install this the xunit.assert assemly is failing to download from Nuget. Any suggestions to get this working? I am guessing that the versions are messed up.
Here are my nuget package locations:
I'm also using the beta2 version of the kre.
There is/was an issue with the new xunit.runner.kre and VS CTP 5. See below discussion:
https://github.com/aspnet/Testing/issues/65
xunit.runner.xre is available only on myget/vnext feed. Include that in the Nuget.config that you should be able to restore the package
By running on the beta2 kre you're then having mismatched dependencies. If you look at the versions of your xunit bits they're all beta3. I'd recommend upping your kre to beta3 to fix your issue (will affect which packages your app pulls in).
Also as a side note I'd recommend ensuring your nuget.org/api/v2/ feed is enabled (in the SS you posted it wasn't). There's currently an issue where it'll occasionally disable itself; has definitely made my life frustrating several times when things don't build :).
One great feature of TravisCI is the ability to add a configuration file to your repository which describes how Travis should run your build. Is something similar possible with TeamCity?
I've done some pretty heavy configuration for enterprise TeamCity servers so I'm fairly well versed in it, but I've never seen or heard of this type of configuration and so far as I can tell it's not in the docs. I'd be okay with a plugin as well, assuming it's stable.
It seems this feature was requested some time ago and is being tested in a newer version of TC.
Full discussion: http://youtrack.jetbrains.com/issue/TW-2806
Relevant comment: http://youtrack.jetbrains.com/issue/TW-2806#comment=27-781368
Try out EAP, this feature is already there.
EAP is currently free http://confluence.jetbrains.com/display/TW/TeamCity+EAP+(Latest)
http://code.google.com/r/hectorchu-go-windows/source/list
If you could compile it successfully, I like to know the procedures of how to.
Assuming you are using Hector's source tree:
Install MinGW and MSYS, along with MSYS Bison and any other tools you think you'll find useful (vim, etc).
Install ed from the GNUWin32 project.
Install Python and Mercurial.
Clone the [hectorchu-go-windows mercurial repository](https://hectorchu-go-windows.googlecode.com/hg/ hectorchu-go-windows) to C:\Go.
Run an MSYS shell (or rxvt). The rest of these are bash commands...
mkdir $HOME/bin
export PATH=$HOME/bin:$PATH
export GOROOT=C:\\Go
export GOARCH=386
export GOOS=mingw
cd /c/Go/src
./all.bash
Correct errors as it spits them out at you, repeat step 10 until it starts building.
It's the same idea as on Linux or MacOS, basically.
However, I still stand by what I said in my comment above: this isn't necessarily going to generate anything that actually works yet. You'd be better served by waiting until this effort has merged into the main Go tree before tackling it, unless your interest is in assisting with the porting effort.
Update: there is now a mostly-functional pre-built windows port available, for those not interested in building the compiler themselves. However, given the rate of change of the project, the lack of formal releases (other than the hg "release" tag), and the possibility of Hector's changes being merged into the main branch soon, keeping up with development via source builds is likely to produce better results over time.
Just FYI, there is seems official one now.
http://code.google.com/p/go-windows/
Hector said he was only able to get as far as being able to compile and run an empty main. See issue 107:
http://code.google.com/p/go/issues/detail?id=107
There is still a lot of work to do in porting that, especially since the code has lots of dependencies on ptrace and syscall, not to mention the different threading models between Linux/BSD and Windows.
Update:
There's a new thread on golang-nuts (started 26.03.2010) with a link to a recent build and some current building instructions (using MinGW+MSYS).