git checkout -b master origin/master #create local copy of master
git checkout origin/feature # check out with no plan to commit
-However, Moonshot also has a number of submodules. These include
-libradsec, Shibboleth, and libeap.
-Each commit to the main Moonshot repository includes a reference to the
+However, Moonshot's source is distributed as a master repository with a number of [submodules](http://git-scm.com/book/en/Git-Tools-Submodules). These include
+libradsec, Shibboleth, and the moonshot GSS-API mechanism itself.
+Each commit to the master Moonshot repository includes a reference to the
appropriate commit of a sub project to use. This is a *commit*, not a
*branch*. That is, a Moonshot developer needs to make a explicit
decision to update what version of a subproject is being used on a given
-moonshot branch.
+moonshot branch. A commit of the master repository describes all the Moonshot software in use including every version of the submodules.
However, git does not automatically adjust the version of subprojects
you have checked out. After updating, either by pulling, checking out a new branch, merging or
rebasing, it is a good idea to run 'git submodule update'. This command
will set every subproject to the expected commit stored in the Moonshot
-branch you have checked out. See [[submodules]] for information on what
-to do if you need to work with one of these subprojects.
+branch you have checked out.
## Master ##
At least until we have stable releases, new users should be directed to
master.
-## meeting/moonshot2 ##
+[[Centos packaging|release/centos]] is built directly from the master branch. However, while master is always built on Centos, the version numbers of Centos packages need to be incremented before new Centos packages are installed.
-This is a [[integration branch]] for the second moonshot meeting. As the
-meeting approaches it is desirable to slow down the pace of change in
-code that participants will be using. It would be unfortunate to get
-into a situation where a change breaking master disrupted the
-meeting. This branch is managed by Sam Hartman; ask before committing to
-this branch.
+The Ubuntu automated builds merge the changes from master together with the changes from the Debian branch below to generate packaging.
-Participants at the second moonshot meeting are likely to find a build
-of this branch helpful.
-However during the meeting we will likely update this branch or
-sometimes work from master once we get basic functionality working.
+## Debian
-## tlv-mic ##
+The Debian branch includes [[Debian packaging|release/debian]] which is used for Debian and Ubuntu builds.
-This branch is a [[feature branch]] under development. The intent is to
-add a cryptographic checksum to Moonshot exchanges as part of
-extensibility.
+
+# Working with Submodules
+
+Whenever you run "git submodule update", all submodules end up in a [detached head](http://eclipsesource.com/blogs/2011/05/29/life-lesson-be-mindful-of-a-detached-head/) state. This produces very confusing behavior if you commit changes. It's easy to lose track of changes. Prior to changing a submodule, check out a branch. Typically the same branch as the master repository, although for projects imported from other sources we often use the moonshot branch for our local change. As of early 2014,, we're using the tr-integ branch for freeradius.
+
+In all cases, we're using the debian branch for debian packaging.
+
+## When you have something worth saving.
+
+If you have something working well enough to include in the master repository then:
+
+1. commit to the subproject
+
+2. push the branch containing the commit in the submodule.
+
+3. Run "git log origin/branchname" in the submodule and make sure your commit is there
+4. Run "git add submodule_directory" in the master repostiory
+
+4. Commit the master repository
+
+5. Push the branch in the master repository
--- /dev/null
+[[!title "Committing to Master"]]
+
+Committing to the [[master branch|branches]] of the Moonshot master repository has the following affects:
+
+1. Kicks off a new build of the Moonshot software to confirm everything builds. At this time, the results of this build are unused.
+
+1. Updates the recommended software for people building from source. We recommend folks building from source use our master branch.
+
+1. Triggers a Centos build. This may make new RPMs available; see [[Centos packaging|release/centos]].
+
+# Commit to the subproject
+
+Commit all the desired changes to the submodule. Use the appropriate branch for Moonshot development:
+
+* master for things that are native to Moonshot
+* moonshot for Shibboleth and things we fork
+* tr-integ for freeradius
+
+# Update Upstream Version?
+
+Consider updating the upstream version number in configure.ac. It's in the call to AC_INIT.
+
+# Make sure to push
+
+Make sure to push the submodule. The build will break if you do not.
+
+# Update master repository
+
+Add the submodule; commit and push the master repository. Se the bottom of [[branches]] for more details.
+# Monitor the build
+
+Take a look at the [buildbot](http://www.project-moonshot.org/buildbot/builders/) to see if the build succeeds.
--- /dev/null
+[[!meta title="Preparing Test Builds"]]
+
+This page describes performing test builds to run on Painless
+Security's test infrastructure.
+
+Log into moonbuild (10.1.10.10) and check out a tree. Below we check out a writable tree, because you'll probably end up making some changes:
+
+ ssh -A username@10.1.10.10
+ git clone username@moonshot.suchdamage.org:/srv/git/moonshot.git
+
+this will leave you on the master branch of the [[Moonshot repository|branches]].
+However, to build Debian test packages, you want to be on the debian branch. So:
+
+ git checkout debian
+ git submodule update --init
+
+Now, merge in the changes you want to test.
+Let's say that you're updating moonshot itself and that your changes are already on master.
+
+ cd moonshot
+ git merge origin/master
+
+Now we'll need to update the debian version number so we can do a fresh build:
+
+ dch -i
+
+This will pull up an editor. Describe the change. You will be modifying debian/changelog. We will not commit this file because we're just generating test packages.
+
+Change back to the root of your checkout of the master repository.
+
+Now, we want to disable stripping and optimization for our builds:
+
+ export DEB_BUILD_OPTIONS="noopt nostrip"
+
+Now would be a good time to remove the "debian_build" directory if it has contents from a previous build.
+
+And run the builds
+
+ ./debian-builder -s -c -s wheezy-i386 -s --arch=i386 -s -A directories
+The "-s" option gets repeated a lot because it passes the following option to sbuild, the Debian package build infrastructure. That will run an i386 (32-bit) build of the software using the wheezy-i386 (Debian 7.0) chroot (filesystem image). For directories include the directory of the software you're wishing to build.
+
+The output packages will be placed in the debian_build directory.
+
+Copy these to any test machines you like. You might like a loop something like
+
+ for ip in 21 22 23 90; do
+ rsync -e ssh -a debian_build root@10.1.10.$ip:/tmp
+ done
+
+That will copy the debian_build directory to the listed machines. Log into these machines and run
+
+ cd /tmp/debian_build
+ dpkg -i packages_you_want_to_install
+
+If dependencies are not installed try running "aptitude install" to fix. Make sure it doesn't "fix" things by removing the package you just installed.
+
+You can run
+
+ git reset --hard
+
+In the submodule checkout to throw awy your changes if you need to re-merge in some new fixes.
projects / devwiki.git / commitdiff