FreeBSD/Setup/Area51: Difference between revisions

From KDE Community Wiki
< FreeBSD‎ | Setup
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Area 51 repository =
= Area 51 repository =
Note: KDE at the moment the repository is mostly used to prepare commits to the main tree; as updates rarely take more than a few hours (or days, in case of an exp-run), the branches are shortlived. So as unless you are trying to contribute to the kde@ maintained ports, there is no real need to track the ports tree, instead of the main, one at the moment
Area 51 is used for development of KDE and Qt ports that are maintained by the KDE on FreeBSD team. Right now, that is for Plasma 5 and the latest (KF5-based) KDE Applications.


<blockquote>In the KDE 3 days, around FreeBSD 5, the repository where KDE ports were developed was called Area 51 – the famous place where aliens land. Although 'area51' no longer appears in the host name or repository name, we still call it Area 51.</blockquote>
<blockquote>In the KDE 3 days, around FreeBSD 5, the repository where KDE ports were developed was called Area 51 – the famous place where aliens land. Although 'area51' no longer appears in the host name or repository name, we still call it Area 51.</blockquote>
Line 13: Line 17:
= Source organization =
= Source organization =


The Area 51 ports tree is an official git fork of the official FreeBSD ports tree; it is hosted on GitHub alongside the XOrg and GNOME ports trees. This section talks about the procedures used to keep the ports tree up-to-date. This is for *maintainers* of the ports tree, not *users* of the ports tree.
The Area 51 ports tree is an official git fork of the official FreeBSD ports tree; it is hosted on GitHub alongside the XOrg and GNOME ports trees. This section talks about the procedures used to keep the ports tree up-to-date. This is for ''maintainers'' of the ports tree, not ''users'' of the ports tree.


Most important for maintainers: *never* push to master except when synchronizing with upstream.
Most important for maintainers: <b>never push to main except when synchronizing with upstream</b>.


== Initial Clone ==
== Initial Clone ==
Line 31: Line 35:


{{Input|1=<nowiki>
{{Input|1=<nowiki>
git checkout master
git checkout main
git fetch -p upstream
git fetch -p upstream
git merge --ff-only upstream/master
git merge --ff-only upstream/main
git push</nowiki>}}
git push</nowiki>}}


Line 43: Line 47:


{{Input|1=<nowiki>
{{Input|1=<nowiki>
git checkout master
git checkout main
git checkout -b my-feature</nowiki>}}
git checkout -b my-feature</nowiki>}}


Then modify ports, add commits of the changes you make. Since the working copy of the tree is exactly what you are modifying, you can use poudriere to build your changes quite easily.
Then modify ports, add commits of the changes you make. Since the working copy of the tree is exactly what you are modifying, you can use poudriere to build your changes quite easily.


*Do not ever commit directly to master*
<center><b>Do not ever commit directly to main</b></center>


You may push a topic branch to origin; this can be useful for collaboration and for testing purposes.
You may push a topic branch to origin; this can be useful for collaboration and for testing purposes.


To sync with master (do this before making a PR), first synchronize with upstream, and then merge master into your feature branch; this will show you if anything has changed "out from under you".
To sync with main (do this before making a PR), first synchronize with upstream, and then merge main into your feature branch; this will show you if anything has changed "out from under you".


{{Input|1=<nowiki>
{{Input|1=<nowiki>
git checkout my-feature
git checkout my-feature
git merge master
git merge main
# Resolve any issues here
# Resolve any issues here
git push # If you want to publish</nowiki>}}
git push # If you want to publish</nowiki>}}


To create a diff for PR purposes, first sync with master and resolve any problems, and then diff between master and your feature branch:
To create a diff for PR purposes, first sync with main and resolve any problems, and then diff between main and your feature branch:


{{Input|1=<nowiki>
{{Input|1=<nowiki>
git diff master..my-feature > /tmp/pr.diff</nowiki>}}
git diff main..my-feature > /tmp/pr.diff</nowiki>}}


To clean up: once the PR is landed by a commit to the official FreeBSD SVN ports tree (e.g. by a ports committer), the upstream git mirror will update as well. This may take up to two hours. Then the content of the PR commit is available in the git tree.
To clean up: once the PR is landed by a commit to the official FreeBSD SVN ports tree (e.g. by a ports committer), the upstream git mirror will update as well. This may take up to two hours. Then the content of the PR commit is available in the git tree.


*Do not ever merge branches to master.*
<center><b>Do not ever merge branches to main.</b></center>


You can synchronize with upstream to check that the PR contents have landed properly -- to test, you can checkout master and then use poudriere to build against that tree.
You can synchronize with upstream to check that the PR contents have landed properly -- to test, you can checkout main and then use poudriere to build against that tree.
The remaining branches can be pruned, unless you really want to keep development history for them.
The remaining branches can be pruned, unless you really want to keep development history for them.


{{Input|1=<nowiki>
{{Input|1=<nowiki>
git checkout master
git checkout main
git branch -D my-feature  # Force delete of topic branch
git branch -D my-feature  # Force delete of topic branch
git push origin --delete my-feature # If you published it</nowiki>}}
git push origin --delete my-feature # If you published it</nowiki>}}
Line 122: Line 126:


Use <code>git branch -a</code> to see which branches are available. As of mid-june, 2017, there are the following branches:
Use <code>git branch -a</code> to see which branches are available. As of mid-june, 2017, there are the following branches:
* ''plasma5'', which contains the complete KDE Frameworks, Plasma Workspace, and KDE Applications. This is probably the branch you want.
* ''kde5-import'', which contains the complete KDE Frameworks, Plasma Workspace, and KDE Applications. This is probably the branch you want.
* ''kde5.9-import'', same as above, but with Qt-5.9 mixed in
* ''qt-5.9, Qt-5.9 work in progress ports
* ''kdevelop-5'', ''kdenlive-17.04'', which are branches updating only a single application or collection of related ports to the KDE Frameworks-based version of that application.
* ''kdevelop-5'', ''kdenlive-17.04'', which are branches updating only a single application or collection of related ports to the KDE Frameworks-based version of that application.
* ''cmake-3.9'', which contains preparations for the release of CMake 3.9.
* ''cmake-x.y'', which contains preparations for the release of CMake x.y -- (for some valid combination of x and y).


Use <code>git checkout plasma5</code> to switch to the ''plasma5'' branch, which is the one most likely to be useful at this point (mid-june 2017).
Use <code>git checkout kde5-import</code> to switch to the ''kde5-import' branch, which is the one most likely to be useful at this point (december 2017).


== Setting up the build jail ==
== Setting up the build jail ==
Line 136: Line 142:
== Running a build ==
== Running a build ==


Poudriere can bulk-build ports, given a jail and a ports tree to work with. It will generally rebuild all that is needed; assuming you are most interested in all the latest KDE software, the metaport <code>x11/kde</code> is the one to rebuild.
Poudriere can bulk-build ports, given a jail and a ports tree to work with. It will generally rebuild all that is needed; assuming you are most interested in all the latest KDE software, the metaport <code>x11/kde5</code> is the one to rebuild.


     # poudriere bulk -j 110amd64 -p freebsd-ports-kde x11/kde
     # poudriere bulk -j 110amd64 -p freebsd-ports-kde x11/kde5

Latest revision as of 16:28, 7 May 2021

Area 51 repository

Note: KDE at the moment the repository is mostly used to prepare commits to the main tree; as updates rarely take more than a few hours (or days, in case of an exp-run), the branches are shortlived. So as unless you are trying to contribute to the kde@ maintained ports, there is no real need to track the ports tree, instead of the main, one at the moment

Area 51 is used for development of KDE and Qt ports that are maintained by the KDE on FreeBSD team. Right now, that is for Plasma 5 and the latest (KF5-based) KDE Applications.

In the KDE 3 days, around FreeBSD 5, the repository where KDE ports were developed was called Area 51 – the famous place where aliens land. Although 'area51' no longer appears in the host name or repository name, we still call it Area 51.

Area 51 is used for development of KDE and Qt ports that are maintained by the KDE on FreeBSD team. These ports are not always in a stable state, so users are encouraged to test and report problems, especially during call for testing (CFT) periods. Area 51 is hosted on GitHub.

New versions and changes to ports are always committed here first and only later hit the FreeBSD ports tree. The history of commits is recorded in the KDE on FreeBSD e-mail list. Workflow is similar to the graphics stack ports development workflow, or GNOME ports: a complete Git clone of the ports tree is kept, branches work on specific updates, and that work gets merged to FreeBSD ports master when things are ready.


HIC SUNT LEONES

Source organization

The Area 51 ports tree is an official git fork of the official FreeBSD ports tree; it is hosted on GitHub alongside the XOrg and GNOME ports trees. This section talks about the procedures used to keep the ports tree up-to-date. This is for maintainers of the ports tree, not users of the ports tree.

Most important for maintainers: never push to main except when synchronizing with upstream.

Initial Clone

This assumes you have a GitHub account and permissions for the KDE-FreeBSD ports tree:

git clone https://github.com/freebsd/freebsd-ports-kde.git
git remote set-url --push origin [email protected]:freebsd/freebsd-ports-kde.git
git remote add upstream https://github.com/freebsd/freebsd-ports.git

}

Synchronizing with upstream

Do this at least every weekend:

git checkout main
git fetch -p upstream
git merge --ff-only upstream/main
git push

Working on a port

Use a topic branch. Topic branches are local, but you can also push them to the origin for collaboration. Topic branches are cleaned up once they are merged, and there is no need to hang on to them or references to them.

To get started:

git checkout main
git checkout -b my-feature

Then modify ports, add commits of the changes you make. Since the working copy of the tree is exactly what you are modifying, you can use poudriere to build your changes quite easily.

Do not ever commit directly to main

You may push a topic branch to origin; this can be useful for collaboration and for testing purposes.

To sync with main (do this before making a PR), first synchronize with upstream, and then merge main into your feature branch; this will show you if anything has changed "out from under you".

git checkout my-feature
git merge main
# Resolve any issues here
git push # If you want to publish

To create a diff for PR purposes, first sync with main and resolve any problems, and then diff between main and your feature branch:

git diff main..my-feature > /tmp/pr.diff

To clean up: once the PR is landed by a commit to the official FreeBSD SVN ports tree (e.g. by a ports committer), the upstream git mirror will update as well. This may take up to two hours. Then the content of the PR commit is available in the git tree.

Do not ever merge branches to main.

You can synchronize with upstream to check that the PR contents have landed properly -- to test, you can checkout main and then use poudriere to build against that tree. The remaining branches can be pruned, unless you really want to keep development history for them.

git checkout main
git branch -D my-feature  # Force delete of topic branch
git push origin --delete my-feature # If you published it

Packages and build status

The current status of some of the branches of Area 51 can be seen in the FreeBSD continuous integration (CI) system, which is a Jenkins instance kindly hosted by one of the team members:

Builds are done on both STABLE and 12.0-CURRENT.

Packages may be obtained from the unofficial repository that is created by the Jenkins CI system. To do this, add a configuration file /usr/local/etc/pkg/repos/area51.conf as follows:

FreeBSD: { enabled: false }
area51: {
  url: "http://meatwad.mouf.net/rubick/poudriere/packages/110-amd64-kde/"
  priority: 2
  enabled: true
}

The first line disables the official FreeBSD package repository. This avoids mixing packages from multiple sources, and is is strongly advised when using unofficial packages.

Poudriere

We strongly recommend using poudriere for building packages from Area 51. These packages can then easily be used with pkg(8). First things first, install poudriere:

   # pkg install poudriere

it is recommended to modify `/usr/local/etc/poudriere.conf` to use ZFS.

Setting up the ports tree

(Note that this can be done more easily with poudriere-devel.)

With poudriere installed, you must create one or more ports trees (to build from) and one or more jails (to build in). We'll start with the ports tree. Create a tree, but don't populate it; we'll call this ports tree freebsd-ports-kde.

   # poudriere ports -c -F -m git -p freebsd-ports-kde

Next, clone the ports tree from Area 51. This needs to go into the just-created directory for the ports tree, which could be anywhere on your system depending on how poudriere is configured. The default is under `/usr/local/poudriere/ports`. Depending on how you want to access Area 51, you may need to use a different user or credentials – this example just does an anonymous clone.

   # cd /usr/local/poudriere/ports
   # git clone https://github.com/freebsd/freebsd-ports-kde

With this setup, you can git pull and otherwise update the Git repository as you see fit: it is the working directory that will be used for the ports tree (so you can switch branches inside the clone, too).

Picking the right branch

The ports tree which has been cloned, above, has checked out the master branch. Master always follows the official FreeBSD ports tree, so it is not very interesting compared to the other branches in the Area 51 repository. Note, too, that master may lag behind the official ports: the KDE-FreeBSD team synchronizes master with the official ports tree at least every weekend.

Use git branch -a to see which branches are available. As of mid-june, 2017, there are the following branches:

  • kde5-import, which contains the complete KDE Frameworks, Plasma Workspace, and KDE Applications. This is probably the branch you want.
  • kde5.9-import, same as above, but with Qt-5.9 mixed in
  • qt-5.9, Qt-5.9 work in progress ports
  • kdevelop-5, kdenlive-17.04, which are branches updating only a single application or collection of related ports to the KDE Frameworks-based version of that application.
  • cmake-x.y, which contains preparations for the release of CMake x.y -- (for some valid combination of x and y).

Use git checkout kde5-import to switch to the kde5-import' branch, which is the one most likely to be useful at this point (december 2017).

Setting up the build jail

Create a jail to build in; this is essentially a whole new FreeBSD installation inside your existing one. It can also be an older FreeBSD version (newer than the host system is not recommended and may not work at all). This command creates a new 11.0 jail, calling it 110amd64, and installs the jail over FTP:

   # poudriere jail -c -j 110amd64 -v 11.0-STABLE -m ftp

Running a build

Poudriere can bulk-build ports, given a jail and a ports tree to work with. It will generally rebuild all that is needed; assuming you are most interested in all the latest KDE software, the metaport x11/kde5 is the one to rebuild.

   # poudriere bulk -j 110amd64 -p freebsd-ports-kde x11/kde5