|
|
| (54 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| = Rawhide synchronization for the GNU Binutils = | | = Rawhide synchronization for the GNU Binutils = |
|
| |
|
| This page documents the process by which the rawhide binutils package is synced with the upstream GNU Binutils project. The aim of this process is to make syncing simple and easy so that it can be performed on a regular basis. Due to the fact that the binutils is an important component in the toolchain used to build many of the packages in rawhide however, it is important to make sure that any attempt at syncing does not break anything.
| | '''THIS PAGE IS UNDER DEVELOPMENT AND SHOULD NOT BE CONSIDERED READY FOR USE''' |
|
| |
|
| This process is based upon a similar process for the GNU C Library ([[GlibcRawhideSync]]), but tweak to fit the binutils package. | | This page documents the process by which the rawhide binutils package is synced with the upstream GNU Binutils project. The aim of this process is to make syncing simple and easy so that it can be performed on a regular basis. Due to the fact that the binutils is an important component in the toolchain used to build many of the packages in rawhide however, it is important to extensively test a new binutils before putting it into the buildroot. This does make the syncing process more time consuming and complicated. |
|
| |
|
| == TL;DR ==
| | This process is based upon a similar process for the GNU C Library ([[GlibcRawhideSync]]), but tweaked to fit the binutils' way of handling patches. |
|
| |
|
| Make sure you have authenticated and meet the pre-requisites (see notes below).
| | This process assumes that you already have a clone of the upstream GNU Binutils repository as well as the Fedora rawhide binutils. |
|
| |
|
| If you do this every week, here's the cut and paste snippets you need, minus the bits that change every week...
| | The decision for '''when''' to perform a sync is a complicated one. In general if there is a newly made official upstream release then that should be used. Otherwise if there is a recent upstream branch snapshot available then that should be used. Otherwise if there has not been a sync in the last two weeks then it is probably time for this procedure to run. |
|
| |
|
| <pre>
| | Follow these steps: |
| kinit
| |
| | |
| export GLIBC_MS=$HOME/fedsrc/glibc-maintainer-scripts
| |
| export TOOLS=$HOME/fedsrc/UpstreamToolchainBuildScripts
| |
| | |
| cd $GLIBC_MS; git pull --rebase
| |
| cd $TOOLS; git pull --rebase
| |
| cd $HOME/src/glibc-pristine; git pull --rebase
| |
| cd $HOME/fedsrc/glibc; git pull --rebase
| |
| fedpkg sources
| |
| rm -rf glibc-patches; $GLIBC_MS/glibc-patches-to-git.py
| |
| $GLIBC_MS/glibc-sync-upstream.py --import-git $HOME/src/glibc-pristine --verbose
| |
| git diff
| |
| cd $HOME/src/glibc-pristine; git log --oneline (fill)..(in) | sed 's/[^ ]* /- /'
| |
| cd $HOME/fedsrc/glibc; ${VISUAL:=vi} glibc.spec
| |
| | |
| fedpkg new-sources `/bin/ls -1rt glibc-*.tar.xz | tail -1`
| |
| git add glibc.spec
| |
| git commit
| |
| | |
| fedpkg srpm
| |
| fedpkg scratch-build --srpm `/bin/ls -1rt $PWD/glibc-*.src.rpm | tail -1`
| |
| | |
| rm -rf logs; mkdir logs; cd logs
| |
| $TOOLS/codonell/get-build-logs.sh https://koji.fedoraproject.org/koji/taskinfo?taskID=(fill-in)
| |
| | |
| cd $HOME/fedsrc/glibc; git push
| |
| fedpkg build
| |
| | |
| https://bodhi.fedoraproject.org/updates/?search=glibc
| |
| </pre>
| |
| | |
| == Synchronization Process ==
| |
| | |
| {{Admon/tip | Fedora CI/CD | Fedora Rawhide must pass Fedora CI/CD, in particular `baseos-qe.koji-build.scratch-build.validation` before you can consider the synchronization process complete.}}
| |
| | |
| '''1.''' Setup/Fetch a clean upstream master repository for glibc. This can be an existing directory also which you switch to master branch and ensure it has been rebased e.g. '''git pull --rebase''' cleanly to head.
| |
| <pre>
| |
| mkdir -p $HOME/src
| |
| cd $HOME/src
| |
| git clone git://sourceware.org/git/glibc.git glibc-pristine
| |
| </pre>
| |
| | |
| '''2.''' Setup/Fetch a clean Fedora rawhide glibc repository. If this is not your first time syncing, you may need to remove the glibc-patches subdirectory that the previous sync created.
| |
| <pre>
| |
| cd $HOME/fedsrc
| |
| fedpkg clone glibc
| |
| </pre>
| |
| | |
| '''3.''' Run '''fedpkg sources''' to downloads the .tar.xy file needed for creating the glibc-patches repository (next step).
| |
| <pre>
| |
| cd $HOME/fedsrc/glibc
| |
| fedpkg sources
| |
| </pre>
| |
| | |
| '''4.''' Convert the Fedora rawhide glibc dist-git repository to a glibc-patches repository (git repo with Fedora patches applied as commits).
| |
| <pre>
| |
| export GLIBC_MS=$HOME/fedsrc/glibc-maintainer-scripts
| |
| cd $HOME/fedsrc/glibc
| |
| $GLIBC_MS/glibc-patches-to-git.py
| |
| </pre>
| |
| | |
| '''5.''' Synchronize from upstream master to Fedora rawhide and review changes.
| |
| NOTE: Pick the appropriate set of instructions based on where we are in the release.
| |
| | |
| No release transitions occurring:
| |
| <pre>
| |
| cd $HOME/fedsrc/glibc
| |
| $GLIBC_MS/glibc-sync-upstream.py --import-git $HOME/src/glibc-pristine --verbose
| |
| git diff
| |
| Confirm that glibcsrcdir, glibcversion, and Release have the correct NEVRA.
| |
| </pre>
| |
| | |
| Transitioning from stable release -> master:
| |
| <pre>
| |
| cd $HOME/fedsrc/glibc
| |
| $GLIBC_MS/glibc-sync-upstream.py --import-git $HOME/src/glibc-pristine --verbose --import-git-branch master
| |
| git diff
| |
| Manually change the glibcsrcdir, glibcversion, and Release to match the new NEVRA.
| |
| </pre>
| |
| | |
| If a merge conflict occurs, review the section on '''Dealing with Merge Conflicts''' then return to the next step.
| |
| | |
| '''6.''' Manually document note-worthy changes in the %changelog. This step is probably the most complex. You need to look at all the changes since the last sync (the hash is recorded in the %changelog) in the upstream repo and see if there is anything note-worthy to talk about e.g. '''git diff HASH1^..HASH2'''. You will use this text in your commit message also.
| |
| <pre>
| |
| * Wed Nov 07 2018 Florian Weimer <fweimer@redhat.com> - 2.28.9000-14
| |
| - Auto-sync with upstream branch master,
| |
| commit 1df872fd74f730bcae3df201a229195445d2e18a:
| |
| - libanl: Fix crash if first helper thread creation failed (#1646381)
| |
| </pre>
| |
|
| |
|
| A useful command to summarize commits is <b>git log</b> like this:
| | 1. Make sure that your clone of the upstream GNU Binutils is up to date, on the right branch and clean. If there any problems or uncommitted changes, resolve them before continuing. |
| <pre>
| |
| cd $HOME/src/glibc-pristine
| |
| git log --oneline e0cb7b6131..0ddb7ea842 | sed 's/^[^ ]* /- /'
| |
| </pre>
| |
| The two hashes to use are based on the first ten digits of the last sync's git commit and the current sync's git commit. You want the log listing to show all of the new commits that have been included in the current sync. In the above example, we're updating from <tt>e0cb7b6131</tt> (the commit of the last sync) to <tt>0ddb7ea842</tt> (the commit of the current sync). Verify the boundary commits make sense.
| |
|
| |
|
| '''7.''' Add new files (still in the Fedora rawhide directory from the last step) and commit
| |
| <pre> | | <pre> |
| cd $HOME/fedsrc/glibc | | cd <upstream-binutils> |
| fedpkg new-sources glibc-*.tar.xz
| | git switch HEAD |
| git add glibc.spec
| | git pull |
| git commit
| | git clean -fdx |
| </pre> | | git status</pre> |
| An appropriate commit message would be:
| |
| <pre>
| |
| Auto-sync with upstream branch master
| |
|
| |
| Upstream commit: 1df872fd74f730bcae3df201a229195445d2e18a
| |
|
| |
| - libanl: Fix crash if first helper thread creation failed (#1646381)
| |
| </pre>
| |
| Following the spec file %changelog example from above.
| |
| | |
| '''8.''' Test a scratch build, and wait for it to complete.
| |
| <pre>
| |
| fedpkg srpm
| |
| fedpkg scratch-build --srpm ./glibc-XXX.src.rpm
| |
| </pre> | |
|
| |
|
| '''9.''' Verify scratch build results by downloading logs and looking for any unexpected failures. A list of known failures is kept at the end of this page, and should be updated as needed.
| | 2. Delete any old release tarballs and then create a source tarball from the upstream sources. Change the version number in the tarball's name to a commit id. |
| <pre>
| |
| export TOOLS=$HOME/fedsrc/UpstreamToolchainBuildScripts
| |
| $TOOLS/codonell/get-build-logs.sh https://koji.fedoraproject.org/koji/taskinfo?taskID=$TASKID
| |
| </pre>
| |
|
| |
|
| '''10.''' Push the commit and kick off a Rawhide build if the logs look good (you are not done yet!)
| |
| <pre> | | <pre> |
| git push | | rm -f *.xz |
| fedpkg build
| | export COMMIT_ID=`git rev-parse HEAD` |
| </pre> | | ./src-release.sh -x -r `git log -1 --format=%cd --date=format:%F $COMMIT_ID` binutils |
| | mv binutils-*.tar.xz binutils-$COMMIT_ID.tar.xz </pre> |
|
| |
|
| '''11.''' Fedora CI/CD must run and you must verify that `baseos-qe.koji-build.scratch-build.validation` succeeded. If Fedora CI/CD does not succeed please reach out to [mailto:mcermak@redhat.com Martin Cermak (BaseOS QE)]. To verify the status of CI/CD go to [https://bodhi.fedoraproject.org Bodhi] after your build successfully completes, select '''Search...''', type in '''glibc''', hit enter and pick the newest Rawhide build errata that was automatically created and select the '''Automated Tests''' tab. If `baseos-qe.koji-build.scratch-build.validation` is green then the test has passed and you are complete with the sync.
| | 3. Go to your clone of the fedora binutils package and make sure that it is clean and up to date: |
|
| |
|
| == Authentication ==
| |
|
| |
| '''1.''' Kerberos init with Fedora realm.
| |
|
| |
| '''2.''' Make sure your ssh agent has your Fedora ssh key for pagure.io.
| |
|
| |
| == Pre-requisites ==
| |
|
| |
| '''1.''' You have a Fedora account with an SSH key, and have setup your SSH key on pagure.io by logging in.
| |
|
| |
| '''2.''' Install '''fedpkg''', '''python3-pygit2''', '''python3-rpm''' and '''git-merge-changelog'''
| |
|
| |
| '''3.''' Configure your '''~/.gitconfig''' to have entries for '''name''', and a merge driver for GNU Changelogs.
| |
| <pre> | | <pre> |
| [user]
| | cd <rawhide-binutils> |
| name = My Name
| | git switch rawhide |
| | git pull |
| | git clean -fdx |
| | git status </pre> |
|
| |
|
| [merge "merge-changelog"]
| | 4. Delete the current source tarball and then copy in the source tarball created in step 2: |
| name = GNU-style ChangeLog Merge driver
| |
| driver = /usr/bin/git-merge-changelog
| |
| [core]
| |
| attributesfile = ~/.gitattributes
| |
| </pre>
| |
|
| |
|
| '''4.''' Configure your '''~/.gitattributes'''
| |
| <pre> | | <pre> |
| ChangeLog merge=merge-changelog
| | rm -f *.tar.xz |
| </pre>
| | cp <upstream-binutils>/binutils*.tar.xz . </pre> |
| | |
| '''5.''' Clone '''glibc-maintainer-scripts''' into '''$GLIBC_MS''' for the git synchronization scripts.
| |
| <pre> | |
| export GLIBC_MS=$HOME/fedsrc/glibc-maintainer-scripts
| |
| mkdir -p $HOME/fedsrc
| |
| cd $HOME/fedsrc
| |
| git clone https://pagure.io/glibc-maintainer-scripts.git
| |
| </pre>
| |
| | |
| '''6.''' Clone '''UpstreamToolchainBuildScripts''' from the Fedora Toolchain team for the build log fetching scripts.
| |
| <pre>
| |
| export TOOLS=$HOME/fedsrc/UpstreamToolchainBuildScripts
| |
| cd $HOME/fedsrc
| |
| git clone https://pagure.io/FedoraToolchainTeam/UpstreamToolchainBuildScripts.git
| |
| </pre>
| |
| | |
| Note: if you plan on editing either of the two git repos you just installed, use ssh://git@pagure.io instead of https://pagure.io
| |
| | |
| == Differences for Release Syncs ==
| |
| | |
| For syncing a glibc release branch into rawhide, you need to use a command line this, and manually reset the Release number the first time:
| |
| | |
| <pre>
| |
| $GLIBC_MS/glibc-sync-upstream.py --import-git-branch [Release branch you are using e.g. release/2.31/master] --import-git [Path to your updated checked out glibc tree e.g. $HOME/src/glibc-2.31] --verbose
| |
| </pre> | |
| | |
| For Fedora release branches, the process is basically the same, except you have to use the Bodhi system to push your build to a release.
| |
| | |
| * In the above instructions, use the release branch of glibc (typically like release/2.28/master) and the release branch of Fedora (typically like f29)
| |
| | |
| * Go to https://bodhi.fedoraproject.org/
| |
| | |
| * Click the ? icon in the upper right, to search for "glibc"
| |
| | |
| * Note previous updates for wordings and severities
| |
| | |
| * Select "Create" in the upper right and create a new update
| |
| | |
| * Type "glibc" in the packages field. If there's a popup, select the appropriate entry.
| |
| | |
| * type "glibc" in the candidate builds field, select the relevent build from the popup.
| |
| | |
| * Click in the "Related bugs" field. If your BZ doesn't show up, type in the number.
| |
| | |
| * Fill in the Update Notes field and final details.
| |
| | |
| * Submit! The system will advertise the update and request karma. When the update has enough karma, it's automatically pushed out.
| |
|
| |
|
| * This is an example of a Fedora 39 sync to release/2.38/master. It assumes you have done at least one sync previously, have completed the pre-requisites, and cloned the source files.
| | 4.5 [Optional] Tidy up the upstream repository. |
|
| |
|
| <pre> | | <pre> |
| kinit
| | pushd <upstream-binutils> |
| export GLIBC_MS=$HOME/fedsrc/glibc-maintainer-scripts
| | git clean -fdx |
| export TOOLS=$HOME/fedsrc/UpstreamToolchainBuildScripts
| | popd |
| | |
| cd $GLIBC_MS; git pull --rebase
| |
| cd $TOOLS; git pull --rebase
| |
| cd $HOME/src/glibc-pristine; git pull --rebase
| |
| * Checkout the version you are syncing to.
| |
| git checkout release/2.38/master
| |
| cd $HOME/fedsrc/glibc; git pull --rebase
| |
| * Checkout the version of Fedora that you are syncing.
| |
| git checkout f39
| |
| fedpkg sources
| |
| rm -rf glibc-patches; $GLIBC_MS/glibc-patches-to-git.py
| |
| * Specify --import-git-branch for the correct release.
| |
| $GLIBC_MS/glibc-sync-upstream.py --import-git-branch release/2.38/master --import-git $HOME/src/glibc-pristine --verbose
| |
| git diff
| |
| cd $HOME/src/glibc-pristine; git log --oneline (fill)..(in) | sed 's/[^ ]* /- /'
| |
| cd $HOME/fedsrc/glibc; ${VISUAL:=vi} glibc.spec
| |
| | |
| fedpkg new-sources `/bin/ls -1rt glibc-*.tar.xz | tail -1`
| |
| git add glibc.spec
| |
| git commit
| |
| | |
| fedpkg srpm
| |
| fedpkg scratch-build --srpm `/bin/ls -1rt $PWD/glibc-*.src.rpm | tail -1`
| |
| | |
| rm -rf logs; mkdir logs; cd logs
| |
| $TOOLS/codonell/get-build-logs.sh https://koji.fedoraproject.org/koji/taskinfo?taskID=(fill-in)
| |
| | |
| cd $HOME/fedsrc/glibc; git push
| |
| fedpkg build
| |
| | |
| * Create the bodhi update. You can use a previous update as an example:
| |
| https://bodhi.fedoraproject.org/updates/?search=glibc
| |
| </pre> | | </pre> |
|
| |
|
| == Dealing with Merge Conflicts ==
| | 5. Edit the ''binutils.spec'' file and change the ''Source0:'' field to reference the new tarball: |
| | |
| * Dealing with merge conflicts due to backport+rebase:
| |
| | |
| Sometimes, a fix is backported from upstream into rawhide, and subsequently a rebase is scheduled. During this rebase, the backport and its corresponding patch need to be dropped.
| |
| | |
| One way to achieve this is to manually edit the spec file prior to running '''glibc-patches-to-git''' so that the merge conflict is avoided in the first place.
| |
| | |
| Another way is to let the merge conflict occur, then run '''git rebase --skip''' in the '''glibc-patches''' directory/repository to skip the application of the current patch (i.e. the one backported, which is causing the merge conflict) and continue the rebase (this rebase is an internal detail of how '''glibc-sync-upstream''' is implemented and was started by the script before erroring out due to the conflict).
| |
| | |
| Then we continue the process by executing '''glibc-git-to-patches''' in '''$HOME/fedsrc/glibc''', which now skips the patch when creating '''glibc-patches'''.
| |
| | |
| Finally, we run '''glibc-patches-to-git --branch master''', to bring update dist-git with the recently refreshed '''glibc-patches'''.
| |
| | |
| * Dealing with Fedora patches that no longer apply cleanly due to changes in rawhide:
| |
| | |
| Another merge conflict scenario is when a Fedora patch does not apply cleanly. You may see a message
| |
| like this:
| |
|
| |
| CONFLICT (content): Merge conflict in nss/nsswitch.conf
| |
| error: Failed to merge in the changes.
| |
| | |
| In this case, the patch is needed for Fedora but an upstream change has caused the patch to be out of sync. You need to fix the patch in the glibc-patches directory. Using nss/nsswitch.conf as an example:
| |
|
| |
|
| <pre> | | <pre> |
| cd $HOME/fedsrc/glibc/glibc-patches
| | sed --in-place -e "s/Source0:.*/Source0: `ls *.tar.xz`/" binutils.spec </pre> |
| edit nss/nsswitch.conf to fix the merge conflict
| |
| git add nss/nsswitch.conf
| |
| git rebase --continue
| |
|
| |
|
| cd $HOME/fedsrc/glibc
| | Also check that the ''use_commit_id_tarballs'' define in the spec file is set to 1. |
| </pre>
| | This define is set to zero when the binutils is rebased to an official GNU Binutils release and only set to 1 once the rawhide syncing process begins. If you do need to change it's value to 1, also make sure that you update the ''Version'' field at the start of the spec file to add a ''.50'' suffix. |
| | |
| If you see that there is a glibc.spec and glibc.spec.new | |
|
| |
|
| <pre> | | <pre>grep -e "define use_commit_id_tarballs" binutils.spec |
| mv glibc.spec glibc.spec.old
| |
| mv glibc.spec.new glibc.spec
| |
| </pre> | | </pre> |
|
| |
|
| Now complete the git-to-patches process, regenerating the patch that failed previously:
| | Also increment the ''Release:'' field by one and add a changelog entry for the update: |
|
| |
|
| <pre> | | <pre> |
| $GLIBC_MS/glibc-git-to-patches.py -v
| | rpmdev-bumpspec -c "- Rebase to commit $COMMIT_ID" binutils.spec |
| </pre> | | </pre> |
|
| |
|
| You should see a message similar to this:
| | 6. Create a source tree and discover if any local patches no longer apply: |
| | |
| info: regenerating patch 'glibc-fedora-nsswitch.patch' because patch failed
| |
|
| |
|
| <pre> | | <pre> |
| git add glibc-fedora-nsswitch.patch
| | fedpkg prep </pre> |
| </pre> | |
| | |
| == Occasions that require special handling ==
| |
| | |
| * The addition of a new locale upstream:
| |
| | |
| When a new locale is added upstream, the change corresponds to a new line in `localedata/SUPPORTED` and `glibc.spec` needs to be adjusted to tackle this. The spec file includes a lua script containing a list of supported locales that is compared at build time to the list upstream. This is below the definition of `%package locale-source`. Grep for `^local locales =` to locate the list and add a line corresponding to the new locale there before building.
| |
| | |
| == Known Acceptable Build Failures ==
| |
|
| |
|
| For the purposes of "looking for any unexpected failures" (above), this is the current list of build failures that have been deemed "not to stop a sync". After you complete the scratch build and download the logs, compare the test failures in the logs with the results below. For each failure not listed here, analyze it, determine if it's safe to continue syncing, and add that failure below. For each failure listed below that no longer appears in the test results, remove it from below. I.e. most syncs will require minor updates in this section.
| | If a patch does not apply, decide if it is no longer necessary, or if it needs to be adjusted. Take whatever actions are necessary to resolve this issue and then repeat step 5 until a clean run is obtained. |
|
| |
|
| === All Hosts ===
| | If a patch is not needed, remove its entry from the ''binutils.spec'' file. |
|
| |
|
| | Also schedule the patch to be deleted from the repository: |
| <pre> | | <pre> |
| There is a known misc/tst-ttyname failure that needs waiving (https://bugzilla.redhat.com/show_bug.cgi?id=2210335) since we do not currently believe this is a glibc regression - per codonell.
| | git rm <unneeded-patch> |
| </pre> | | </pre> |
|
| |
|
| === aarch64 ===
| | Optionally add a mention of this to the changelog entry created in step 5. |
| | |
| <pre> | | <pre> |
| Rawhide (1 fail):
| | - Retire: <unneeded-patch> |
| FAIL: misc/tst-mount
| |
| | |
| FAIL: elf/tst-debug1
| |
| =====FAIL: elf/tst-debug1.out=====
| |
| Didn't expect signal from child: got `Bus error'
| |
| =====FAIL: elf/tst-debug1.test-result=====
| |
| FAIL: elf/tst-debug1
| |
| original exit status 1
| |
| =====FAIL: dlfcn/tst-dlinfo-phdr=====
| |
| see upstream bz 23293
| |
| </pre> | | </pre> |
|
| |
|
| === armv7hl ===
| | Optionally renumber the remaining patches referenced in the ''binutils.spec'' file so that they are in a monotonically increasing order. |
|
| |
|
| <pre>
| | 7. Run a local build to ensure that there are no surprises. |
| Rawhide (1 fail): FAIL: debug/tst-longjmp_chk2
| |
| =====FAIL: debug/tst-longjmp_chk2.out=====
| |
| not on alternate stack
| |
| in signal handler
| |
| on alternate stack
| |
| Didn't expect signal from child: got `Aborted'
| |
| =====FAIL: debug/tst-longjmp_chk2.test-result=====
| |
| FAIL: debug/tst-longjmp_chk2
| |
| original exit status 1
| |
|
| |
|
| FAIL: misc/tst-sysvshm-linux
| | <pre> fedpkg local </pre> |
| </pre> | |
|
| |
|
| The tst-sysvshm-linux failure is related to:
| | If there are problems, fix them. Note, local builds run in parallel, so it is not always easy to discover the location of a build failure. If the failure is due to a bug in the upstream sources, then it may be better to abort this sync and wait for the bug to be fixed. Or to fix the bug upstream first and then start the sync process again. If the failure is due to the local patches that are applied to the sources then they may need to be adjusted. If a failure is due to a testsuite problem then either the test might need to be tweaked, or just skipped if there is no easy way to correct it. |
| https://sourceware.org/bugzilla/show_bug.cgi?id=26862:
| |
|
| |
|
| === i686 ===
| | 8. Then run a scratch build. |
|
| |
|
| <pre> | | <pre>rm -f *.rpm |
| Rawhide (1 fail):
| | fedpkg srpm |
| FAIL: misc/tst-mount
| | fedpkg scratch-build --srpm *.rpm </pre> |
| </pre> | |
|
| |
|
| This seems to be transient, unable to reproduce manually:
| | If the build fails, investigate and fix the problems. The most likely cause at this point is new failures in one of the testsuites. Note - the ''build.log'' file created for the build for each architecture will include a uuencoded compressed tarball of the logs from the testsuite runs. Hence the logs can be downloaded and examined locally by: |
| <pre>
| |
| =====FAIL: io/tst-stat-time64.out=====
| |
| tst-stat-time64.c:88: numeric comparison failure
| |
| left: 8 (0x8); from: stx.stx_blocks
| |
| right: 16 (0x10); from: st.st_blocks
| |
| error: 1 test failures
| |
| </pre>
| |
|
| |
|
| <pre> | | <pre> |
| | | [download build.log file] |
| FAIL: math/test-double-erfc
| | uudecode build.log |
| FAIL: math/test-double-tgamma
| | tar xvf binutils-*.tar.xz |
| FAIL: math/test-float32x-erfc
| |
| FAIL: math/test-float32x-tgamma
| |
| FAIL: math/test-float64-erfc
| |
| FAIL: math/test-float64-tgamma
| |
| FAIL: math/test-float-hypot
| |
| FAIL: math/test-float32-hypot
| |
| | |
| These relate to this bug:
| |
| https://sourceware.org/bugzilla/show_bug.cgi?id=20305
| |
| FAIL: signal/tst-minsigstksz-1
| |
| FAIL: signal/tst-minsigstksz-2
| |
| </pre> | | </pre> |
|
| |
|
| === ppc64le ===
| | 9. This next step is optional, but recommended. It assumes that you have command line access to the COPR system and you have the ''mass-prebuild'' package installed. Warning - this step will take a '''long''' time to complete, as in 3-4 days... |
|
| |
|
| <pre>
| | Set up a config script for the mass pre-build tool. |
| | |
| FAIL: math/test-float-nearbyint
| |
| FAIL: math/test-float-rint
| |
| FAIL: math/test-float32-nearbyint
| |
| FAIL: math/test-float32-rint
| |
| | |
| Rawhide (2 fails)
| |
| FAIL: math/test-ibm128-llround
| |
| FAIL: math/test-ibm128-y1
| |
| | |
| Previous failures - no longer seeing these:
| |
| FAIL: misc/tst-mount
| |
| | |
| FAIL: misc/tst-sigcontext-get_pc
| |
| Sporadic failure:
| |
| FAIL: time/tst-cpuclock1
| |
| </pre>
| |
| | |
| === s390x ===
| |
|
| |
|
| <pre> | | <pre> |
| Rawhide (1 fail):
| | archs: x86_64 aarch64 ppc64le s390x |
| FAIL: misc/tst-mount
| | chroot: fedora-rawhide |
| | | name: binutils-$COMMIT_ID |
| Sporadic failure:
| | packages: |
| FAIL: rt/tst-cpuclock2
| | binutils: |
| | src_type: file |
| | src: <path-to-source-rpm-created-in-step-8> |
| | data: <path-to-results-directory> |
| | verbose: 1 |
| </pre> | | </pre> |
|
| |
|
| === x86_64 ===
| | Then use it to run a test of the new binutils |
|
| |
|
| <pre> | | <pre> |
| Rawhide (1 fail):
| | mpb --config <config-file> |
| FAIL: misc/tst-mount
| |
| | |
| =====FAIL: nptl/tst-stack4.out=====
| |
| =====FAIL: nptl/tst-stack4.test-result=====
| |
| FAIL: nptl/tst-stack4
| |
| original exit status 127
| |
| </pre> | | </pre> |
|
| |
|
| | If there are problems, try to find out what went wrong. |
|
| |
|
| == Known CI Failures ==
| | 10. Finally check that the fedora repository has not received any other commits, add the new sources, and commit the changes. |
|
| |
|
| Please list known CI failures here. CI failures must be coordinated with BaseOS QE.
| |
|
| |
| === fedora-ci.koji-build.rpmdeplint.functional ===
| |
| <pre> | | <pre> |
| glibc-devel-2.36.9000-21.fc38.aarch64 - testout.log
| | git pull |
| | | fedpkg new-sources binutils-*.tar.xz binutils-2.19.50.0.1-output-format.sed |
| glibc-devel-2.36.9000-21.fc38.aarch64 provides /usr/include/bits/sigaction.h which is also provided by glibc-headers-s390-2.36.9000-21.fc38.noarch
| | fedpkg commit -m "Rebase to commit $COMMIT_ID" |
| | | fedpkg push |
| The above is a known-failure because not all headers can be installed at the same time. The CI test is attempting to install every package we can install and that's not a valid test of anything.
| | fedpkg build |
| It is not valid to install the aarch64 headers and s390x headers at the same time. The test doesn't know this. Nobody would every need to do this. But it attempts all noarch package installs.
| |
| </pre> | | </pre> |
|
| |
|
| === baseos-qe.koji-build.scratch-build.validation ===
| | 11. Sit back and relax. Have a cup of tea. Then wait for the bug reports to flood in. |
| <pre>
| |
| ===i686 kernel scratch build mock-output.log ===
| |
| kernel-6.2.0-0.rc3.20230111git7dd4b804e080.26.fc38.i686
| |
| built with glibc-devel-2.36.9000-21.fc38.i686
| |
| | |
| No matching package to install: 'bpftool'
| |
| ...
| |
| Not all dependencies satisfied
| |
| Error: Some packages could not be found.
| |
| | |
| known failure - not a glibc issue
| |
| </pre>
| |
| | |
| <pre>
| |
| === aarch64 lua scratch build build.log ===
| |
| lua-5.4.4-7.fc38.src.rpm, aarch64
| |
| built with glibc-devel-2.36.9000-21.fc38.aarch64
| |
| | |
| <pre>
| |
| testing 'format %a %A'
| |
| >>> closing state <<<
| |
| /builddir/build/BUILDROOT/lua-5.4.4-7.fc38.aarch64//usr/bin/lua: strings.lua:342: assertion failed!
| |
| stack traceback:
| |
| [C]: in function 'assert'
| |
| strings.lua:342: in main chunk
| |
| [C]: in function 'dofile'
| |
| all.lua:165: in main chunk
| |
| [C]: in ?
| |
| .error: Bad exit status from /var/tmp/rpm-tmp.tSJRwD (%check) | |
| Bad exit status from /var/tmp/rpm-tmp.tSJRwD (%check)
| |
| RPM build errors:
| |
| Child return code was: 1
| |
| | |
| lua test suite fails assertion - not a glibc issue
| |
| </pre>
| |
Rawhide synchronization for the GNU Binutils
THIS PAGE IS UNDER DEVELOPMENT AND SHOULD NOT BE CONSIDERED READY FOR USE
This page documents the process by which the rawhide binutils package is synced with the upstream GNU Binutils project. The aim of this process is to make syncing simple and easy so that it can be performed on a regular basis. Due to the fact that the binutils is an important component in the toolchain used to build many of the packages in rawhide however, it is important to extensively test a new binutils before putting it into the buildroot. This does make the syncing process more time consuming and complicated.
This process is based upon a similar process for the GNU C Library (GlibcRawhideSync), but tweaked to fit the binutils' way of handling patches.
This process assumes that you already have a clone of the upstream GNU Binutils repository as well as the Fedora rawhide binutils.
The decision for when to perform a sync is a complicated one. In general if there is a newly made official upstream release then that should be used. Otherwise if there is a recent upstream branch snapshot available then that should be used. Otherwise if there has not been a sync in the last two weeks then it is probably time for this procedure to run.
Follow these steps:
1. Make sure that your clone of the upstream GNU Binutils is up to date, on the right branch and clean. If there any problems or uncommitted changes, resolve them before continuing.
cd <upstream-binutils>
git switch HEAD
git pull
git clean -fdx
git status
2. Delete any old release tarballs and then create a source tarball from the upstream sources. Change the version number in the tarball's name to a commit id.
rm -f *.xz
export COMMIT_ID=`git rev-parse HEAD`
./src-release.sh -x -r `git log -1 --format=%cd --date=format:%F $COMMIT_ID` binutils
mv binutils-*.tar.xz binutils-$COMMIT_ID.tar.xz
3. Go to your clone of the fedora binutils package and make sure that it is clean and up to date:
cd <rawhide-binutils>
git switch rawhide
git pull
git clean -fdx
git status
4. Delete the current source tarball and then copy in the source tarball created in step 2:
rm -f *.tar.xz
cp <upstream-binutils>/binutils*.tar.xz .
4.5 [Optional] Tidy up the upstream repository.
pushd <upstream-binutils>
git clean -fdx
popd
5. Edit the binutils.spec file and change the Source0: field to reference the new tarball:
sed --in-place -e "s/Source0:.*/Source0: `ls *.tar.xz`/" binutils.spec
Also check that the use_commit_id_tarballs define in the spec file is set to 1.
This define is set to zero when the binutils is rebased to an official GNU Binutils release and only set to 1 once the rawhide syncing process begins. If you do need to change it's value to 1, also make sure that you update the Version field at the start of the spec file to add a .50 suffix.
grep -e "define use_commit_id_tarballs" binutils.spec
Also increment the Release: field by one and add a changelog entry for the update:
rpmdev-bumpspec -c "- Rebase to commit $COMMIT_ID" binutils.spec
6. Create a source tree and discover if any local patches no longer apply:
fedpkg prep
If a patch does not apply, decide if it is no longer necessary, or if it needs to be adjusted. Take whatever actions are necessary to resolve this issue and then repeat step 5 until a clean run is obtained.
If a patch is not needed, remove its entry from the binutils.spec file.
Also schedule the patch to be deleted from the repository:
git rm <unneeded-patch>
Optionally add a mention of this to the changelog entry created in step 5.
- Retire: <unneeded-patch>
Optionally renumber the remaining patches referenced in the binutils.spec file so that they are in a monotonically increasing order.
7. Run a local build to ensure that there are no surprises.
fedpkg local
If there are problems, fix them. Note, local builds run in parallel, so it is not always easy to discover the location of a build failure. If the failure is due to a bug in the upstream sources, then it may be better to abort this sync and wait for the bug to be fixed. Or to fix the bug upstream first and then start the sync process again. If the failure is due to the local patches that are applied to the sources then they may need to be adjusted. If a failure is due to a testsuite problem then either the test might need to be tweaked, or just skipped if there is no easy way to correct it.
8. Then run a scratch build.
rm -f *.rpm
fedpkg srpm
fedpkg scratch-build --srpm *.rpm
If the build fails, investigate and fix the problems. The most likely cause at this point is new failures in one of the testsuites. Note - the build.log file created for the build for each architecture will include a uuencoded compressed tarball of the logs from the testsuite runs. Hence the logs can be downloaded and examined locally by:
[download build.log file]
uudecode build.log
tar xvf binutils-*.tar.xz
9. This next step is optional, but recommended. It assumes that you have command line access to the COPR system and you have the mass-prebuild package installed. Warning - this step will take a long time to complete, as in 3-4 days...
Set up a config script for the mass pre-build tool.
archs: x86_64 aarch64 ppc64le s390x
chroot: fedora-rawhide
name: binutils-$COMMIT_ID
packages:
binutils:
src_type: file
src: <path-to-source-rpm-created-in-step-8>
data: <path-to-results-directory>
verbose: 1
Then use it to run a test of the new binutils
mpb --config <config-file>
If there are problems, try to find out what went wrong.
10. Finally check that the fedora repository has not received any other commits, add the new sources, and commit the changes.
git pull
fedpkg new-sources binutils-*.tar.xz binutils-2.19.50.0.1-output-format.sed
fedpkg commit -m "Rebase to commit $COMMIT_ID"
fedpkg push
fedpkg build
11. Sit back and relax. Have a cup of tea. Then wait for the bug reports to flood in.
