The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Funtoo:Metatools/Advanced Usage/Gitolite Setup
Overview
For our local development setup, we will be using gitolite. Gitolite will make things quite a bit easier by managing git repositories for us. Think of gitolite as your own private GitHub that has no Web user interface (we modify its settings by pushing to its special gitolite-admin repo) and you'll have a pretty good idea of what gitolite does. To keep things simple, we will be using a single development system in our setup example below. However, because gitolite can be accessed over the network, you can easily set up gitolite on another system on your LAN or a remote system on the Internet and securely access it simply by modifying the git URL.
This document assumes you have basic knowledge of ssh-keygen and how to generate public/private SSH key pairs. If you don't know how to to this, see Generating SSH Keys for quick steps or OpenSSH Key Management, Part 1 for a more detailed introduction. For this article, you'll probably want to generate a private keys without a passphrase, which is more convenient but a much greater security risk if the private key gets compromised, or one with a passphrase but using keychain to manage ssh-agent for you.
Gitolite
Installation
To set up gitolite, we will use a repos user on your local development system. On this system, perform the following steps as root:
repohost # useradd -m repos
The repos user will be a dedicated user account on the system that will have gitolite enabled and will house our git repositories. Now, we are going to su to this new user and perform gitolite configuration:
repohost # su --login repos user $ git clone https://github.com/sitaramc/gitolite user $ install -d ~/bin
Now, as the repos user, add the following within your ~/.bashrc file:
~/.bashrc export PATH=$HOME/bin:$PATH
What we're doing is setting up a bin directory where the gitolite command will be installed, which will be in your path, so that you can use it more easily. With this done, perform the following steps:
user $ source ~/.bashrc user $ gitolite/install -ln
Now, your repos account is almost ready to be used for hosting repositories. The way gitolite works is that it is going to basically take over ssh access to the account, so that when you connect via ssh with git, it will perform its own authentication. For this to work, you will need to enable your own "master key" to access gitolite.
To do this, you'll want to decide from which account you'll want to administer gitolite itself. I prefer to use my "drobbins" account on local system, so I will copy my ssh public key from ~/.ssh/id_ed25519.pub to /var/tmp/drobbins.pub, and then perform the following steps to "prime" gitolite with this admin public key -- do this as the repos user:
user $ gitolite setup -pk /var/tmp/drobbins.pub
Gitolite will now be initialized to recognize the drobbins account as an administrator, which will allow this account to clone from repos@localhost:gitolite-admin and push any changes to this special git repository which contains the master configuration for gitolite. This is important because we will be performing the rest of gitolite setup over ssh, using this account.
OK, gitolite is installed! From this point forward, we will be using the drobbins (or equivalent) account on your development workstation to configure gitolite.
If you are setting up gitolite on a separate server, and assuming you have ssh properly configured, it would be prudent at this point to test the connection to the remote server from your local workstation . Perform ssh -T, or ssh test command appropriate to your setup, as shown below to verify you can connect:
user $ ssh -T repos@remote-server-name
You should receive confirmation message similar to:
hello repos, this is repos@remote-server-name running gitolite3 v3.6.11-3-g39293e6 on git 2.19.1 R W gitolite-admin R W testing
If you receive the following message during testing:
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), ...
then localization settings for the remote server have not been completed. If remote server is Funtoo-based, complete the steps on the page Funtoo Linux Localization on the remote server.
gitolite-admin Clone
Now that gitolite is ready under the repos user on your local system, we can configure the rest by cloning the gitolite-admin repo and commiting configuration changes to it. I am going to use the drobbins account on the same system to do this, and you will use whatever account is associated with the public key you loaded into gitolite. I like storing my development repos in ~/development , so I'll go ahead and clone the gitolite-admin repo to that location so it can live along all my other git repos. Feel free to put this git repo wherever you like to store git repos that you develop on:
user $ cd ~/development user $ git clone repos@localhost:gitolite-admin user $ cd gitolite-admin
We are now ready to configure gitolite. We'll do this by modifying conf/gitolite.conf in the git repo and adding new ssh public keys to keydir/ as needed. You will see that the initial public key you used to "prime" gitolite already exists in keydir/. Once we change the configuration, and potentially add new public ssh keys that we want to grant access to gitolite-managed repositories, we'll perform a git commit and git push, and if gitolite doesn't complain about our changes, they'll take effect immediately. We'll go through our initial configuration steps below.
gitolite Configuration
Since I will be generating meta-repo and kits using my drobbins user, this account will need to have permissions to create repositories in gitolite.
We're ready to edit conf/gitolite.conf so that it looks like this:
gitolite.conf # Group definitions below, starting with @. This makes it easy to associate multiple ssh keys with a particular person.
# Admins will have full control over gitolite.
@admins = drobbins
# Developers will be able to create, read and write git repositories.
@developers = drobbins
# Users will have read-only access.
@users = drobbins
# repositories:
# SPECIAL ADMIN REPO BELOW -- modify with care!
repo gitolite-admin
RW+ = @admins
# AUTO-CREATED (wild) REPOS: gitolite will auto-create repos under wildrepo/ for us
# upon initial clone of any path within, if the repo doesn't already exist.
repo wildrepo/..*
C = @developers
RW+ = @developers
R = @developers @users
Now, we will want to commit and push our changes in the gitolite repo so they take effect -- This is how gitolite configuration changes are applied:
user $ git add . user $ git commit -a -m "Initial setup" user $ git push Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 12 threads Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 607 bytes
Configuration
Now that merge-scripts is cloned, we will need to create a ~/.merge configuration file. Here is an example file that can serve as a starting point. In this example, developer bcowan has forked the kit-fixups repository on code.funtoo.org, and wants to test his personal changes by generating a complete meta-repo of his own:
/root/.merge [sources]
flora = https://code.funtoo.org/bitbucket/scm/co/flora.git
kit-fixups = ssh://git@code.funtoo.org:7999/~bcowan/kit-fixups.git
gentoo-staging = https://code.funtoo.org/bitbucket/scm/auto/gentoo-staging.git
[destinations]
# This is the key setting that tells merge-kits to push up to our local repo-space:
base_url = repos@localhost:wildrepo/staging
[branches]
flora = master
kit-fixups = master
meta-repo = master
Sources Section
Let's walk through this configuration file. The [sources] section defines locations of repositories that the merge scripts will use as sources for creating kits and meta-repo. In the above sample config, we are using the official Flora repository from Funtoo, and the official gentoo-staging repository used by Funtoo, but we are using our own fork of kit-fixups, which will allow us to add new ebuilds that will appear in kits, such as bug fixes to existing ebuilds in kits, as well as security fixes. For a core Funtoo Linux developer, this is a good way to start. If you are more interested in contributing third-party ebuilds, then you may instead choose to create your own fork of flora, and use our standard kit-fixups repository. Or, you could choose to create forks of both. The recommended best practice is to use our upstream repos when possible, and fork only those repos you want to customize. This way, you'll ensure that you have the most up-to-date versions of ebuilds in those unforked repos.
Branches Section
The [branches] section is used to define the default branches that are used by the merge-scripts. In general, sticking with master is fine, but if you need the flexibility, you can point the merge scripts to a particular feature branch to use instead, for example.
Work Section
The [work] section is used to define paths where the merge-scripts will do their work. The source and destination settings above are good defaults, and define where the merge-scripts will clone source repositories and destination (written to) repositories, such as kits and meta-repo. These are kept in two separate hierarchies so they don't get mixed up.
Generating New Kits
With this all configured, you are ready to generate new kits. These kits will be generated as root on your development system, and will be pushed up to repos@localhost/staging/repo_name. Here are the steps you'd perform:
root # merge-kits 1.4-release
merge-kits will proceed to create new kits and meta-repo, and will push them up to repos@localhost:wildrepo/staging/meta-repo, repos@localhost:wildrepo/staging/core-kit, etc. This process can take quite a while but has been optimized to run quickly on multi-core systems and use caching extensively so successive runs will complete quickly.
Using New Kits
Now that the new meta-repo and kits are created, here's how you'll use them on an existing Funtoo system, instead of your official Funtoo meta-repo and kits. First, we'll want to modify /etc/ego.conf as follows:
/etc/ego.conf [global]
sync_user = drobbins
sync_base_url = repos@localhost:wildrepo/staging/{repo}
# Yes, you are supposed to have a literal "{repo}", above. Ego recognizes this special pattern.
# You can have whatever [kits] section you want, below...
Since we are syncing as a regular user, we will need to make sure that our user account is in the portage group and that /var/git is writable by, in this case, drobbins:
root # chmod g+rwx /var/git
Let's also move the current meta-repo out of the way -- you can also simply delete the existing meta-repo. And then we'll re-run ego sync:
root # cd /var/git root # mv meta-repo meta-repo.official root # ego sync user $ ego sync Running as regular user. Syncing meta-repo Cloning into '/var/git/meta-repo'... X11 forwarding request failed on channel 0 remote: Enumerating objects: 13, done. remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 100% (11/11), done. remote: Total 13 (delta 1), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (13/13), done. Resolving deltas: 100% (1/1), done. Syncing browser-kit branch 1.4-release
You will note a lot of failures at the end of sync that look like this:
ERROR: There was an error syncing qt-kit (error code True) ERROR: There was an error syncing ruby-kit (error code True) ERROR: There was an error syncing science-kit (error code True) ERROR: There was an error syncing security-kit (error code True) ERROR: There was an error syncing text-kit (error code True) ERROR: There was an error syncing xfce-kit (error code True) ERROR: Sync not successful.
This is just a cosmetic issue and as long as /var/git/meta-repo exists and the git clones themselves went fine, you should have a custom meta-repo on your system, ready to use!
If you type emerge -auDN @world, ego will now be using your custom kits, rather than the official Funtoo ones. This means that you can perform a variety of things you couldn't before. You can now add your own custom ebuilds to your fork of kit-fixups, and merge-kits will automatically incorporate these changes into your own custom kits. This will allow you to locally test any changes before submitting them as pull requests to Funtoo. You will also be able to maintain your own meta-repo and kits with your own local modifications, and have your systems use these meta-repo/kits instead of the official Funtoo ones.
Using New Kits with Metro
Rather than using new kits on a local Funtoo Linux system, you may want to use the kits to perform a metro build. This is desirable when you may want to use metro to perform continuous integration by attempting to perform a full stage1, 2 and 3 build, which is what the steps in this example accomplish. To do this, first set up Metro on your system.
Then, prior to running metro, set the EGO_SYNC_BASE_URL in your environment as follows:
root # export EGO_SYNC_BASE_URL="repos@localhost:wildrepo/staging/{repo}"
Metro should grab these settings and automatically adjust the ego.conf it uses based on these settings, to grab your meta-repo instead of the official one. You should now be able to perform
CI testing of your changes.