Do anyone know how to get or make a gitian key so that I can use it to build bitcoin in different platform from source code using gitian builder?
In gitian process doc, it mentions the setup script to run:
pushd ./bitcoin
export SIGNER=(your Gitian key, ie bluematt, sipa, etc)
export VERSION=0.13.0
git fetch
git checkout v${VERSION}
popd
https://github.com/bitcoin-core/gitian.sigs
This repository contains Gitian signatures for releases and release
candiates of Bitcoin Core.
How to Make and Submit Gitian Sigs
See the Bitcoin Core Gitian documentation and the Bitcoin Core Release
Process for instructions on Gitian building. You might have to use the
release process of the tag that you are building.
Related
We are trying to manage our own C++ static libraries using JFrog Artifactory CE. In the near future, these libraries could be accessed by third parties so we don't want to put any .cpp files in the package, we just want to put .h files and compiled libraries in our conan packages hosted on Artifcatory.
I read through the conan official guide https://docs.conan.io/en/1.3/creating_packages.html
https://docs.conan.io/en/1.3/creating_packages/package_repo.html
but I cannot find any description of how to exclude source files from the recipe.
If I don't specify exports_sources or exports in my conanfile.py I cannot build static libraries but if I specify those parameters, conan puts source files under export/conan_sources.tgz automatically when I execute conan create.
How can I create a conan package without including source files in the recipe?
There are 2 different ways to do this, instead of using the exports_... functionality:
Use the source() method, to retrieve whatever tarball, git-clone, or what is necessary to fetch the sources. This might require some authentication, which can be provided through env-vars. It is typical to use the conandata.yml to put the data there, and let the source() method to read the self.conan_data. Check this docs. The recipes in the conan-center-index repo, that serves to build ConanCenter, uses this approach.
Use the scm component if the recipe lives in the same repo as the source code, to capture the URL and commit of the sources, but without capturing the sources. If the scm code is behind auth, only authorized devs will be able to see the sources or build from sources. Check this section of the docs about SCM
In both cases, if the access to the source is restricted, non-privileged users that try to build packages from sources with --build will fail.
b) After generating the .NET C# server stub, the documentation is not very verbose about how to use it:
You need to implement the logic yourself to handle whatever work the
API needs to do. Once the implementation is ready, you can deploy the
API locally or on your server. See the README.md file in the
downloaded archive to get started.
Is there any tutorial about how to use the code? I would like to use inheritance to avoid code changes of the generated code. But the documentation talks about just ignoring some generated files. The swagger support told me to just "migrate" the changes on every change. What is possible, but I hoped to be able to leave generated files untouched. Am I wrong here, is there no parctical need for this? I would like to use the server stub in a continuous integration environment.
One option you have is to customize the templates.
Clone the swagger-codegen repository.
Assuming you are using the latest stable v2 version of the code generation tool, then master branch is fine. Otherwise checkout the tag for the tool version you are using.
In Windows Explorer, open swagger-codegen\modules\swagger-codegen\src\main\resources\ and copy the aspnetcore directory. Paste that into your customer source code repository.
When next you run the codegen tool, provide the -t argument:
java -jar swagger-codegen-cli.jar generate
-i <your Open API spec URL/file>
-l aspnetcore
-o <outputdir>
-t <relative path to your>\aspnetcore
... other args as needed
Now you can modify those templates with custom code. For example, you could have an external library with a new base controller class that provides some generic business logic. Then you could modify the controller.mustache file to reference your base class. Just one of many examples. Add your custom templates to your source control for continuous integration.
Caveats: There is a controller.mustache file directly in aspnetcore and another in aspnetcore\2.1. In studying the source code, I see that the 2.1 folder is used for any version of ASP.NET Core other than 2.0. I'm new to this tool myself and have not fully figured out how to exploit it; the utility generates source code that will not build for me out of the box. It does not generate the security classes, but it does generate code that tries to use those security classes. Thus I'm having to comment out the security code in the templates.
DLUX is dropped from upstream releases, so I have to compile DLUX and add back to my application.
Firstly, I need to download & compile DLUX (odl-dlux-core, odl-dluxapps-*):
git clone -b stable/oxygen https://github.com/opendaylight/dlux.git
mvn clean install
Then create new ODL application:
mvn archetype:generate -DarchetypeGroupId=org.opendaylight.archetypes -DarchetypeArtifactId=opendaylight-startup-archetype -DarchetypeCatalog=remote -DarchetypeVersion=1.1.0-SNAPSHOT
mvn clean install
./karaf/target/assembly/bin/karaf
Next, how can I add dlux-core and all of dluxapps features to the repository and install them to my new application?
// The default repo location is `./karaf/target/assembly/system`,
// what I need to do to run the following commands?
feature:repo-add mvn:org.opendaylight.dlux/odl-dlux-core/0.7.4-SNAPSHOT/xml/features mvn:org.opendaylight.dlux/odl-dluxapps-<app_name>/<app_version>/xml/features
feature:install odl-dlux-core odl-dluxapps-<app_name>
Unfortunately it is not as simple as adding the existing features to your new karaf distribution. As #vorburger said, you basically would need to do some maintenance tasks on the old DLUX source code, at the very least to update any of its OpenDaylight dependencies to the same version as the archetype (which I assume comes from master and is based on Neon). Once you bump versions, you may need to update the DLUX code to new APIs, if it is the case.
If DLUX is important to you, you may need to invest some effort to revive it. You may find the #opendaylight channel on Freenode IRC to be a good resource to find help.
The DLUX (UI) application is no longer supported and therefore included in recent ODL distributions, because there were no more active maintainers for it.
If you are using DLUX and have an interest in it, we (the ODL community) would be excited if someone wanted to seriously work on helping to maintain DLUX. This is how open source works.
[Answering your Comment below that this is not about DLUX specific but more generally via Editing this Answer instead of Comment, because it's too long; perhaps best open a new and more specific question, if still not clear; instead of further extending this.]
I'm not sure if you would like to learn (a) how to add a new feature to an existing ODL Karaf, or (b) "patch" an existing feature?
If it's (a) in general, then I think this is duplicate of OpenDaylight Oxygen Deploy app built from opendaylight-startup-archetype ... does that help?
If it's (b) then you would just do your patch (and, ideally, get engaged on mailing lists with the "upstream" community, and contribute it back on https://git.opendaylight.org ?), then locally "mvn clean install" that, and then from another project as per (a) make a dependency to that feature - it will find it in your local Maven repo, and use that, instead of the original, to build your own Karaf distro. HTH?
In my project.json I have a reference to
"Microsoft.AspNet.Mvc": "6.0.0-beta6-14192",
In github https://github.com/aspnet/Mvc I don't know which source is used for this build.
Where do I find this information?
Right now, there's no easy way to get the commit id. But for all the packages that will be released after today noon-ish time (PDT), that will be possible. You will be able to run dnu sources get <package-name> and you'll get the sources for that particular package.
To unblock you, I've looked in our internal CI. MVC build 14192 was produced from commit 37f056ce2bd930635fbfa1370b7ccf5752130c7f
I am looking for a solution to automatically increment a package version (not to be confused with an assembly version) after each build on CI server (particularly Atlassian Bamboo). Every appx package has a version defined in its manifest file (appxmanifest). Thus in order to increase the version a manifest must be edited before commit. I am considering different approaches to implement this. The first one makes changes in manifest and pushes it back to the repo.
Starts building a plan (in order to lock a build number)
Modifies manifest so that a revision is set to the current build number
Pushes changes to SCM (particularly Atlassian Stash). This step shouldn't trigger the next build.
Continues building the package (invoke MSBuild, UT and other tasks)
Cons
Leads to incorrect workflow on Bamboo: checkout -> push -> build
Each build makes a new commit
Another approach is to setup post receive Stash hook which would modify appxmanifest.
Cons Hard to keep a build number in sync with Bamboo.
Is there any other (cleaner and proper) way to achieve this?
ex-Stash developer here (not that it matters),
I would highly recommend not checking in derived/version information or files. It's going to cause you no end of problems (some of which you have pointed out in your question).
My advice - generate what information you need on the build. I don't know anything about appx packaging, but can you use a placeholder/property (like this) which can be resolved on the Bamboo build? For our builds we use the git hash and timestamp as the version, and in the past I've also used the job/build number (timestamp is better though).
As more food for thought - if that appx version is important for developers to see locally, and it becomes hard to match up with the Git version then you can also attach a Git tag/note to the commit in Bamboo as well. The nice thing about that is that anyone fetching from Git can easily see that extra metadata, but it doesn't result in extra commits for every build. If the appx version need to be based off the previous version then this makes it possible for the build scripts to inspect the previous commit and bump the version appropriately.
I hope that helps.