Project:Toolchain/Patchsets with Git

From Gentoo Wiki
Jump to: navigation, search
Warning
This page is a work in progress by dilfridge (talk | contribs). Treat its contents with caution.


This page describes in detail how the sys-libs/glibc patchsets have been migrated to Git. Hopefully we'll at some point use the same or a very similar system for all parts of toolchain (ie., gcc, binutils, ...).

sys-libs/glibc

Regular upstream development

The libc git repository has a master branch where current development takes place. On this master branch, releases are tagged as, e.g, glibc-2.26. From each release tag, a stable / backport branch starts with name release/2.26/master.

Upstream git repository: git://sourceware.org/git/glibc.git

Vendor branches and tags

The following branches and tags used to be in upstream git. Right now I am pushing them to a separate github repository, but I'll try to eventually get access to upstream git again.

Github git repository: git@github.com:gentoo/glibc.git

Gentoo has a vendor branch gentoo/2.26, which branches off at the upstream glibc-2.26 tag. On this branch the commits corresponding to Gentoo ebuild releases are tagged as gentoo/glibc-2.26-0, where in this case 0 is the patchset number. When upstream makes a new release, say glibc-2.27, a new such branch gentoo/2.27 shall be created starting at that tag, and the existing gentoo/2.26 head be rebased ont it to forward-carry Gentoo-specific patches.

Setting yourself up for development basically means

user $cd ~/Gentoo/misc/
user $cd glibc
user $git remote add gentoo git@github.com:gentoo/glibc.git
user $git fetch gentoo
user $git checkout gentoo/2.26

Making patches

Making patches is easy; just add commits to one of our vendor branches as e.g. gentoo/2.26.

Usually they should be cherry-picked from the upstream stable branch release/2.26/master or the upstream development branch master. In rare cases it may also make sense to add more Gentoo-specific stuff.

Any commit where the commit message starts with [no-patch] will not generate a patch; this is useful for changes in the extra Gentoo files as e.g. the patchset generation script.

Note
Please only add commits to the gentoo/* vendor branches, never rebase or force-push them! The only exception from this rule is the gentoo/9999 vendor branch, which should be rebased onto upstream master and force-pushed whenever necessary.
Note
The gentoo/* vendor branches must have a linear history, i.e. no merge commits. (Otherwise the patchset generation may fail.)

Making a patchset

user $cd ~/Gentoo/misc/glibc
user $git checkout gentoo/2.26
user $scripts/gentoo/make-tarball.sh 2.26 1

This generates from the current head of gentoo/2.26 a patchset tarball named libc-2.26-patches-1.tar.bz2, and tags the current head of gentoo/2.26 as gentoo/glibc-2.26-1.

  • Please read the script before using it!
  • Make sure your gpg is working for the signed tag!
  • Any commit where the commit message starts with [no-patch] will not generate a patch.
  • Uploading the tarball and pushing stuff to git still must be done manually.
  • So far this infrastructure only exists for 2.26 and 2.25; earlier branches on request.

sys-devel/binutils

Where

Versioning

  • The upstream release branch is usually named as binutils-2_29-branch
  • The upstream release tags usually looks like binutils_2_29_1
  • The Gentoo branches are named gentoo/binutils-2.29.1 (since we might one day also make patchsets for gdb)
  • The Gentoo patchset tags look like gentoo/binutils-2.29.1-2
  • Since there are irregularities in the release tag naming, you can override them by creating a tag gentoo/binutils-2.29.1-upstream and that will be used as reference for the tarball instead.

Patches

Gentoo branches are occasionally rebased on top of upstream branches. Gentoo-specific patches contain "Gentoo: " prefix. Gentoo patches are initially maintained in gentoo/binutils-9999 branch and later cherry-picked into release branches.

Notes:

  • Upstream pushes a daily automated commit onto each branch, increasing the date in a file. make-tarball.sh sskips date bumping patches when tarball is done. This eases patch rebasing.
  • The "development flag" is a variable set to "true" in git and to "false" in tarballs. Since occasionally patches touch that (while not yet released), we add a patch 0000-... that makes it true, and a patch 9999-... that makes it false again... We definitely do not want it true since it adds -Werror and makes the soversion of libbfd contain the date.

How to cut a new patchset

To create new branch and cut first patchset you need to:

  • create a new gentoo granch based on upstream branch
  • apply gentoo-specific patches on top (usually from gentoo/binutils-9999 branch).
  • tag and tarball
  • push tags and branches

Example session:

user $git checkout -b gentoo/binutils-2.32 origin/binutils-2_32-branch
user $git cherry-pick origin/master..gentoo/binutils-9999
user $./scripts/gentoo/make-tarball.sh 2.32 1
user $git push gentoo gentoo/binutils-2.32:gentoo/binutils-2.32
user $git push --tags gentoo

To cut new patchset on existing branch you need to:

  • [optional] rebase gentoo-specific branch on top of upstream branch to pull in fresh patches
  • apply new gentoo-specific patches (or cherry-pick from gentoo/binutils-9999 anew)
  • tag and tarball.
  • push tags and branches

Example session: TODO

sys-devel/gcc

Gentoo's gcc patches live at https://gitweb.gentoo.org/proj/gcc-patches.git/

These are just versioned contents normally seen files/ subtree.

adding new patch

Every Gentoo developer has access to push patches to the patch tree.

  • drop a patch to versioned directory, like 8.2.0/gentoo/
  • add an entry to README.history, like 8.2.0/gentoo/README.history
  • [optionally] cut new patchset with make-tarball.sh

See README files for more details.