Maintaining RPMs

[Alexandre Oliva]

Hello, Caleb,

Thanks again for your interest, sorry it took me so long.  It's been a
busy couple of weeks.

On Oct 17, 2021, Caleb Herbert <csh at bluehome.net> wrote:

> As mentioned on IRC, I would like to start maintaining the RPMs for
> Linux Libre, so that Fedora users can keep their systems libre. But I
> am not too familiar with building kernels or packaging software.

How about we get you started rebuilding one of the current kernels?

If you run:

  svn checkout \
  https://www.fsfla.org/svn/fsfla/software/linux-libre/freed-ora/current/f35

You'll get something that resembles the f35 git build environment, just
stored in a svn repo (more on why that's useful later), and modified to
build linux-libre instead of linux.

  cd f35
  fedpkg --release f35 --name kernel sources

will let you know which files you need to fetch from the linux-libre
server, typically a base release .tar.xz and an incremental patch file.

fedpkg can fetch some of the source files, that we don't modify, from
Fedora's own source repo.

Eventually it will succeed, and then you'll be able to run:

  fedpkg --release f35 --name kernel srpm

Having the .src.rpm file, we're going to use mock to build it in a
pristine distro buildroot.  These are the commands I use:

  arch=x86_64
  ver=`fedpkg --release f35 --name kernel verrel | \
    sed 's,^kernel-\(libre-\)\?,kernel-libre-,'`
  mock -r fedora-35 init
  mock -r fedora-35 --no-clean --target $arch \
        --resultdir=`pwd`/$ver.$arch \
        rebuild $ver.src.rpm'

This will download a lot of packages, use a lot of disk space in /var
and take a long time to complete.  Once it does, it should place the
rebuilt srpm and the corresdonding binary rpms in $ver.arch/, along with
the build logs.


Now, this would be a duplicate of a build I've already published, so now
I'm going to tell you how to set things up to build newer releases, and
then how to go about building them.

When it comes to freed-ora, the goal is to track fedora builds with
minimal changes.  Fedora maintains packages sources in git repositories.
I won't link to them because they lead to non-Free bits, but you should
be able to locate it, and git clone the kernel repository.  If you got a
kernel.spec in there, you found it.  For the present example, check out
the f35 branch.


Now, to get you set up to combine our changes onto newer fedora builds,
we want to commit the stuff that's in svn onto the git branch.  The
trick I use to that end is to keep .svn and .git in the same directory.

First, we have to make sure they're at the same release.  

Check out a fresh copy of the svn branch, so that we don't have any
build artifacts left in it as we get started.  fedpkg ... verrel will
then tell you the package version you've just checked out.  (I may have
moved the branch since you ran your first build above)

Now, back in the git tree, git reset --hard it to the commit of the
upstream version corresponding to the -libre version you've got checked
out in svn.  The commit id to reset to may be found in git log for the
branch, or in fedora's koji build system, but AFAIK fedora git repo
doesn't use tags).

fedpkg verrel (no arguments needed here, because fedpkg can find its way
in a git repo) should print the same NVR, except for -libre and .gnu.
git tag the freed-ora commit, it might come handy later if you want to
get back to it, or to compare it, whatever.

Now here comes the magic: move (or copy) the .git info into the svn f35
dir, then switch to the svn dir.  git status will then tell you what
files I have modified for freed-ora, which ones I have added or removed.
Get all of these changes committed onto the git corresponding branch.
git tag it too, if you wish.

Now you have a freed-ora git branch for f35.  The old git clone dir can
now be wiped out.  This mixed git/svn tree is what we're going to use
from now on.  Be careful: the git history carries non-free stuff from
fedora, so you (presumably) don't want to publish it.  I don't publish
mine, I only publish the cleaned-up svn stuff.

(the notion of using only git, instead of mixed git/svn is conceivable,
squashing or porting over individual git commits onto a cleaned-up
branch, but that's not the way I've done it)


So, how do we go about merging new versions?

git fetch, to download them onto the .git metadata.  Do *not* git pull.
We wish to switch to a subsequent release.  Look at koji kernel builds
and find the next .f35 build you wish to integrate and build.  Open the
web page for that build, and look for the commit <id> hash in Source,
git tag it if you wish, and git merge --no-commit <id>.

There will usually be conflicts in kernel.spec and sources.  Resolve
them in favor of the -libre versions.  Add your %changelog entry to
kernel.spec, if you wish.  You'll likely have to add the hash for a
newer libre patch.  Download it from the GNU Linux-libre site, along
with the .sign, check the signature, and compute the hash with

  sha512sum >> sources --tag patch-5.14-gnu-5.14.<n>-gnu.xz

git add the .sign file, and git remove the old .sign file.
Also svn add the .sign file, and svn remove the old .sign file.

git add kernel.spec sources and commit.

fedpkg verrel should now print a -libre .gnu version corresponding to
the one you've merged.  You can now download the GNU Linux-libre source
tarball and the Fedora kernel aux sources (fedpkg sources).

Also add or remove any files to the svn metadata.  Not the tarballs or
patch files, those are usually too big to keep in svn, that's why they
have to be downloaded separately.  Indeed, it's good to update 'svn pe
svn:ignore .' so that you don't add them by mistake.  It's best to do
this before building, at least for starters, so that you don't
accidentally add any build artifacts.  I use commands like:

  svn pe svn:ignore .
  svn status | sed -n 's,^[?],,p' | tr + \  | xargs svn add
  svn status | sed -n 's,^[!],,p' | tr + \  | xargs svn rm

Unlike git, do *not* commit to svn; git commits are local until you git
push, but svn commits are published right away.  You don't have write
access yet, but even if you did, it's best to wait to "push" a commit
until the build has succeeded.

Now you're ready to build the srpm and then mock-build (with mock, but
for real :-) the new release.

If it fails, adjust, and git commit --amend (or commit without --amend,
your call), rinse and repeat.  Adjust svn while at that.

Once the build succeeds and you're happy with it, tag it in git; now
would be the time to commit and tag it in a public svn repo, and publish
the rpms.


Please let me know in case any of this doesn't make sense to you, or if
you have any questions.  Once you're comfortable with these steps, I can
teach you some more about how I manage multiple fedora release branches,
and how I maintain the rpm repositories, as well as some scripts to
automate some of these processes.

Have fun, ;-)

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>