oscillatord-rebuild

Scripts for releasing update to oscillatord and it's dependencies.

How to use

Prerequisites

1. user went through the wiki and set everything up, klist shows valid ticket.
2. user has packager group permissions (required to upload new sources)
3. user uploaded SSH key in accounts.fedoraproject.org (required to clone repos via ssh)
4. user has git configured: git config --global user.email username@fedoraproject.org && git config --global user.name "John Doe"
5. All packages repos forks are cloned via ssh out under ~/fedora-forks/{oscillatord,disciplining-minipod}
6. All package origins are cloned via ssh out under ~/fedora/{oscillatord,disciplining-minipod}
7. centos8-stream EPEL is aliased as epel8: mkdir -p $HOME/.config/mock && ln -s /etc/mock/centos-stream+epel-8-x86_64.cfg $HOME/.config/mock/epel-8-x86_64.cfg
8. local repo is set up under '~/local_yum_repo': mkdir -p $HOME/local_yum_repo/Packages && cd $HOME/local_yum_repo && createrepo_c .
9. mock is configured to use local repo by putting this in ~/.config/mock.cfg (don't forget to replace user with your user name):

config_opts['dnf.conf'] += """
[my-local]
baseurl=file:///home/user/local_yum_repo
enabled=1
gpgcheck=0
name=local_repo
"""

Release upgrade

Once new fedora is branching out one needs to:

• Patch https://pagure.io/oscillatord-rebuild/blob/main/f/build.sh#_10 to "bump" the rawhide
• Update this README to include new release in build.sh section

Main scripts

They allow for semi-automated trivial rebuild of oscillatord and it's deps. If something goes wrong or requires manual changes, they can be replaced by manual updates to spec followed by localbuild.sh and push.sh, as described in 'Supporting scripts' section.

bump.sh

pass new version as an argument, and both oscillatord and disciplinging-minipod specs will be updated to this version, and commits created with the change.

Once the changes are commited to your forks, create Pull Requests in origin repos via the web UI, wait for CI and merge the PRs.

./bump.sh 3.2.4

If second argument is present, only bump this package instead of both (useful when part of the process failed).

./bump.sh 3.2.4 oscillatord

bump_ubloxcfg.sh

pass version and git commit as arguments, and ubloxcfg spec will be updated to this version, and commits created with the change.

./bump_ubloxcfg.sh 1.13 c3ddcfe7751fedb4c2685ae36818419292df31ba

build.sh

Pull Requests resulted from bump.sh run should be merged to main package repos at this point.

You would need to do this for at least EPEL and rawhide + current stable versions of Fedora (so epel8, epel9, f39, f40 and f41 at the moment of writing).

request side-tag and chain-build packages for EPEL8, will print the BODHI command to create the update

./build.sh epel8

chain-build packages for Fedora 36 in existing side-tag, will print the BODHI command to create the update

./build.sh f36 f36-build-side-54544

If more dependencies need to be included in the build chain (like ubloxcfg), the script needs to be modified accordingly (specifically the fedpkg chain-build part)

Supporting scripts

localbuild.sh

pass package name to trigger local build for epel8, with resulting RPMs put into local repo if applicable. Doesn't update the spec or modify the repo state in any way, useful to trigger builds when making manual changes to specs.

./localbuild.sh disciplining-minipod

push.sh

Pass package name to trigger sources upload, followed by commit and push to repo. Doesn't update the spec or trigger build, useful to commit and push manual changes to repo verified via 'localbuild.sh'.

./push.sh oscillatord

rebase.sh

Pass package name to trigger rebase of fork's rawhide branch on top of upstream/rawhide. If upstream remote is not present, it will be added to the checkout on first run.

./rebase.sh oscillatord

When things go wrong

Build aready exists

Chain builds are tricky, and it often happens that first part of the chain succeeds, while latter fails.

When problems with the build are resolved, it will be impossible to chain-build again with same params, as the build already exists (even if it's from a different build-tag).

This situation looks like this:

> ./build.sh epel8
...
  95745325 build (epel8-build-side-61551, /rpms/disciplining-minipod.git:4426fcd3115137c65beb6fef9aa9fb13b69b0351): open (buildvm-ppc64le-13.iad2.fedoraproject.org) -> FAILED: GenericError: Build already exists (id=2106216, state=COMPLETE): {'name': 'disciplining-minipod', 'version': '3.4.2', 'release': '2.el8', 'epoch': None, 'task_id': 95745325, 'source': 'git+https://src.fedoraproject.org/rpms/disciplining-minipod.git#4426fcd3115137c65beb6fef9aa9fb13b69b0351', 'extra': '{"source": {"original_url": "git+https://src.fedoraproject.org/rpms/disciplining-minipod.git#4426fcd3115137c65beb6fef9aa9fb13b69b0351"}}', 'owner': 5179, 'state': 0, 'completion_time': None, 'pkg_id': 34384, 'start_time': 'NOW', 'volume_id': 0}
  0 free  2 open  0 done  1 failed
    95745326 buildSRPMFromSCM (/rpms/disciplining-minipod.git:4426fcd3115137c65beb6fef9aa9fb13b69b0351): open (buildvm-ppc64le-25.iad2.fedoraproject.org) -> closed                                                                           0 free  1 open  1 done  1 failed
95745324 chainbuild (epel8-build-side-61551): open (buildvm-ppc64le-30.iad2.fedoraproject.org) -> FAILED: GenericError: Build already exists (id=2106216, state=COMPLETE): {'name': 'disciplining-minipod', 'version': '3.4.2', 'release': '2.el8', 'epoch': None, 'task_id': 95745325, 'source': 'git+https://src.fedoraproject.org/rpms/disciplining-minipod.git#4426fcd3115137c65beb6fef9aa9fb13b69b0351', 'extra': '{"source": {"original_url": "git+https://src.fedoraproject.org/rpms/disciplining-minipod.git#4426fcd3115137c65beb6fef9aa9fb13b69b0351"}}', 'owner': 5179, 'state': 0, 'completion_time': None, 'pkg_id': 34384, 'start_time': 'NOW', 'volume_id': 0}                                                          0 free  0 open  1 done  2 failed
95745324 chainbuild (epel8-build-side-61551) failed

what we need to pick from this output is this:

Build already exists (id=2106216, state=COMPLETE): {'name': 'disciplining-minipod', 'version': '3.4.2', 'release': '2.el8'

as it allows us to proceed with normal build of oscillatord while relying on existing build of disciplining-minipod. We can figure out the version of successfull build from the line 'version': '3.4.2', 'release': '2.el8', and use it to tag the build for our build-tag:

> koji tag epel8-build-side-61551 disciplining-minipod-3.4.2-2.el8
Watching tasks (this may be safely interrupted)...
95745495 tagBuild (noarch): free
95745495 tagBuild (noarch): free -> closed
  0 free  0 open  1 done  0 failed
95745495 tagBuild (noarch) completed successfully

Once it's done, we just need to wait for build-tag to re-populate it's repo:

> koji wait-repo epel8-build-side-61551

and once it's done, we can build oscillatord:

> fedpkg build --target=epel8-build-side-61551

and publish bodhi update:

> bodhi updates new --autokarma --autotime --type enhancement --severity low --stable-karma 1 --from-tag epel8-build-side-61551 --notes "Updating oscillatord to 3.4.2"