Skip to content

Home

Jump to bottom
Matyas Selmeci edited this page Jan 29, 2026 · 12 revisions

xrootd (PelicanPlatform patchset)

This repo is for organizing patches that get applied to OSG builds of XRootD RPMs. (It is not meant to be a fork of XRootD.) This gives us a workflow for managing patch updates and ordering.

Issue conventions (for issues related to patches)

  • The description of an issue should include a link to the upstream (xrootd/xrootd) issue or PR, if there is one (and hopefully there is one).

  • Add the long-term label if the corresponding upstream issue/PR has been rejected, is not planned to be created, or there is some other reason why the patch will continue to be in this repo for an indeterminate amount of time.

  • Add the upstream-6.x label if the upstream PR has been merged into their master branch. If it is marked for a specific milestone upstream, also add that milestone to the issue.

  • Add the osg-built label if a Koji build containing the patch has been made (unless that build doesn't work, see below):

  • Add the osg-not-built label if a Koji build has been attempted and failed (or hasn't passed testing) -- basically if a patch needs a fix

  • Add the osg-shipped label if a Koji build containing the patch has been pushed to the OSG release repos.

  • Close the issue when the patch is dropped from the most recent branch.

Workflow for developers (Pelican team)

New XRootD release

  1. Pull the new tag from the upstream XRootD repository (https://github.com/xrootd/xrootd)

  2. Create a branch based on the new tag, named after the tag with "-pelican" appended. For example, the branch for patches applied to "v5.7.3" should be "v5.7.3-pelican".

  3. Push the tags to this repo if necessary (git push --tags pelican if you named this remote pelican)

  4. Cherry-pick all the patches that were applied to the previous branch. If Git reports that the cherry-pick is empty (meaning the patch is already applied), resolve the corresponding issue.

  5. (Optional, requires repo admin privileges) Change the default branch of the repo to the newly created branch.

Adding a new patch

  1. Create a GitHub issue for the patch; include a link to the upstream PR (if available) for the patch.

  2. Squash the patch into a single commit; apply it to the branch we want to apply the patch to. Tip: If you add ".diff" to the end of a PR URL, you will get a squashed diff of the PR. (It won't have a commit message though.)

Prefix the subject of the patch (i.e., the first line of the commit message), with the corresponding issue, so it's easy to link the two. For example, if the issue is "Fix MacOS poller" and it's issue #11, for the subject, use "11-Fix MacOS poller".

Do a direct push, don't make a PR.

Assuming the new patch is HEAD, run git show HEAD | git patch-id --stable and add a comment in the GitHub issue with the output.

  1. Let the OSG Software Team know about the new patch.

Updating an existing patch

  1. Get a new squashed diff for the patch, as a file. (For example, 1234.diff.)

  2. Check out the branch you want to apply the patch to. (For example, v5.7.3-pelican.)

  3. Make a backup branch. (For example, v5.7.3-pelican.bak). Push it.

  4. Take a deep breath, do an interactive rebase on the tag the branch is based on (For example, git rebase -i v5.7.3).

  5. Find the commit you want to change in the list and change "pick" to "edit". Save.

When the rebase gets to that commit:

  1. git checkout HEAD~ -- . will undo the file changes from that commit in the working tree, but leave the current commit alone. (This will let you reuse the commit message.)

  2. git apply 1234.diff to add the changes from the new patch to the working tree.

  3. git commit --amend -a to change the current commit to have the new changes instead.

  4. Run git show HEAD | git patch-id --stable and add that as a comment to the GitHub issue. Tip: Put it in a text editor first in case you need to make multiple attempts at the interactive rebase.

  5. git rebase --continue to keep going with the rest of the commits.

If there are any merge conflicts

  1. Fix the conflicts using git mergetool

  2. Do git commit --amend -a

  3. Run git show HEAD | git patch-id --stable and add that as a comment to the GitHub issue for the commit you just fixed. (Hopefully it has the issue number in the subject!)

If you mess up, do git rebase --abort and try again. If your repo is still in a bad state, follow that up with git reset --hard v5.7.3-pelican.bak.

  1. If you're good with the results, do a force push.

  2. Let the OSG Software Team know about the updates.

Workflow for packages (OSG SW team)

If the version to apply the patches to is, for example, v5.7.3:

  1. git clone -o upstream https://github.com/xrootd/xrootd && cd xrootd
  2. git remote add -f pelican https://github.com/PelicanPlatform/xrootd
  3. git format-patch v5.7.3..pelican/v5.7.3-pelican

Add the short git patch-id to the filename:

for it in *.patch; do
	it_base=${it%.patch}
	hash=$(< "$it" git patch-id --stable | cut -b -7)
	[[ $hash ]] && mv "$it" "${it_base}~${hash}.patch"
done

(The hash created by git patch-id is based on the contents of the patch, not the commit as a whole (so it excludes the commit message from the hash calculation for example). If a rebase had no effect on a patch, its patch-id will be the same.)

  1. Move all the created patch files to the xrootd/osg/ dir in the OSG SW branch you're building for (e.g. 24-main)

  2. If any are new, svn add them. and also add them as PatchN files.

  3. Remove old ones with svn rm.

  4. In the spec file, edit the PatchN lines to add new patches, remove old patches, rename modified patches.

  5. Go to the %prep section and adjust the %autopatch lines if necessary (usually not, unless some of the patches are conditionally applied).

  6. Bump the release, add a %changelog entry, do a scratch build.

  7. Commit, do a real build.

Clone this wiki locally