Compare commits

...

No commits in common. "c9-beta" and "c10s" have entirely different histories.

91 changed files with 432 additions and 6 deletions

View File

@ -1,3 +0,0 @@
2edabd9f5766b84889b07b366b4438e93e994005 SOURCES/gdb-12.1.tar.xz
1ad1d2c6f0141b37bbe32b8add91b5691ecc6412 SOURCES/gdb-libstdc++-v3-python-8.1.1-20180626.tar.xz
fc22d7dfb0c4c686d7dfde9da2aa5b41c475899e SOURCES/v2.0.5.tar.gz

6
.gitignore vendored
View File

@ -1,3 +1,3 @@
SOURCES/gdb-12.1.tar.xz
SOURCES/gdb-libstdc++-v3-python-8.1.1-20180626.tar.xz
SOURCES/v2.0.5.tar.gz
/gdb-12.1.tar.xz
/gdb-libstdc++-v3-python-8.1.1-20180626.tar.xz
/v2.0.5.tar.gz

104
README.local-patches.md Normal file
View File

@ -0,0 +1,104 @@
# Fedora GDB local patches policy
In order to make things easier for the Fedora GDB maintainer, we
choose to auto-generate the local patches by making use of an upstream
git repository. Below you can find a few instructions on how to work
using this method.
You need to run the following commands from the directory that
contains the "gdb.spec" file.
## Importing the GDB patches into a git repository
1) The local patches (`*.patch`) need to be imported into an upstream
git repository. For example, let's assume you cloned the repository
by doing:
`$ git clone git://sourceware.org/git/binutils-gdb.git`
> TIP: if you already have the repository cloned somewhere in your
> system, you can pass a "--reference <dir>" to the "git clone"
> command and it will use your local repository as much as possible
> to make the clone, speeding up things.
2) After cloning the upstream repository, you can import your patches
by using the script "generate-git-repo-from-patches.sh":
`$ sh generate-git-repo-from-patches.sh <REPOSITORY_DIR>`
The script will basically cd into the repository, checkout the
revision specified in the file `_git_upstream_commit`, iterate through
the file `_patch_order` and "git-am" every patch *in that order*.
This operation should complete without errors; if you find a problem
with `git-am`, it probably means that the revision specified in the
file `_git_upstream_commit` is wrong.
## Rebasing the patches against a newer version/release
1) First, cd into the upstream repository. All you have to do is
choose the revision against which you plan to rebase the patches, and
`git rebase <REVISION>`. git will do the rest, and you will be able
to perform conflict resolution by git's algorithm, which is smarter.
## Creating new patches
1) Create the new patch on top of the the others, as usual. Note that
you can use `git rebase` whenever you want to reorder patch order, or
even to delete a patch.
2) When writing the commit log, you must obey a few rules. The
subject line *must* be the filename of the patch. This line will be
used when exporting the patches from the git repository, and
(obviously) it gives the filename that should be used for this
specific patch.
3) You can also add comments that will go into the auto-generated
`Patch:` file (see below). To do that, use the special marker `;;` at
the beginning of the line. This way, a commit log that says:
~~~~~~~~~~~
test-patch.patch
;; This is a test patch
;; Second line
~~~~~~~~~~~
Will generate the following entry in the auto-generated `Patch:` file:
~~~~~~~~~~~
# This is a test patch
# Second line
PatchXYZ: test-patch.patch
~~~~~~~~~~~
## Exporting the GDB patches from the git repository
1) When you're done working with the patches, go back to the directory
that contains the `gdb.spec` file, and from there you run:
`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR>`
This will regenerate all of the `*.patch` files (excluding the ones that
were also excluded from the git repository), and also regenerate a few
control files. These control files are:
- `_gdb.spec.Patch.include`: This file contains the `Patch:` directives.
- `_gdb.spec.patch.include`: This file contains the `%patch` directives.
- `_patch_order`: This file contains the patches, in the exact order
that they must be applied. It is used when importing the patches
into the git repository.
- `_git_upstream_commit`: This file contains the last upstream commit
against which the patches were rebased. It is used when importing
the patches into the git repository.
NOTE: If you did a rebase against a newer upstream version, you need
to specify the commit/tag/branch against which you rebased:
`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> <COMMIT_OR_TAG_OR_BRANCH>`
For example, if you rebased against `gdb-8.1-release`:
`$ sh generate-patches-from-git-repo.sh <REPOSITORY_DIR> gdb-8.1-release`

1
_git_upstream_commit Normal file
View File

@ -0,0 +1 @@
e53a8e8685685c97588f8319d993ea6cd5635e47

72
_patch_order Normal file
View File

@ -0,0 +1,72 @@
gdb-6.3-rh-testversion-20041202.patch
gdb-6.3-gstack-20050411.patch
gdb-6.5-bz185337-resolve-tls-without-debuginfo-v2.patch
gdb-6.5-sharedlibrary-path.patch
gdb-6.5-BEA-testsuite.patch
gdb-6.5-last-address-space-byte-test.patch
gdb-6.5-readline-long-line-crash-test.patch
gdb-6.5-bz218379-ppc-solib-trampoline-test.patch
gdb-6.5-bz109921-DW_AT_decl_file-test.patch
gdb-6.3-bz140532-ppc-unwinding-test.patch
gdb-6.3-bz202689-exec-from-pthread-test.patch
gdb-6.6-bz230000-power6-disassembly-test.patch
gdb-6.6-bz229517-gcore-without-terminal.patch
gdb-6.6-testsuite-timeouts.patch
gdb-6.6-bz237572-ppc-atomic-sequence-test.patch
gdb-6.3-attach-see-vdso-test.patch
gdb-6.5-bz243845-stale-testing-zombie-test.patch
gdb-6.6-buildid-locate.patch
gdb-6.6-buildid-locate-solib-missing-ids.patch
gdb-6.6-buildid-locate-rpm.patch
gdb-6.7-charsign-test.patch
gdb-6.7-ppc-clobbered-registers-O2-test.patch
gdb-6.7-testsuite-stable-results.patch
gdb-6.5-ia64-libunwind-leak-test.patch
gdb-6.5-missed-trap-on-step-test.patch
gdb-6.5-gcore-buffer-limit-test.patch
gdb-6.3-mapping-zero-inode-test.patch
gdb-6.8-bz442765-threaded-exec-test.patch
gdb-6.5-section-num-fixup-test.patch
gdb-6.8-bz466901-backtrace-full-prelinked.patch
gdb-simultaneous-step-resume-breakpoint-test.patch
gdb-core-open-vdso-warning.patch
gdb-ccache-workaround.patch
gdb-lineno-makeup-test.patch
gdb-ppc-power7-test.patch
gdb-archer-next-over-throw-cxx-exec.patch
gdb-6.6-buildid-locate-rpm-librpm-workaround.patch
gdb-test-bt-cfi-without-die.patch
gdb-bz634108-solib_address.patch
gdb-test-pid0-core.patch
gdb-test-dw2-aranges.patch
gdb-test-ivy-bridge.patch
gdb-glibc-strstr-workaround.patch
gdb-rhel5.9-testcase-xlf-var-inside-mod.patch
gdb-rhbz-818343-set-solib-absolute-prefix-testcase.patch
gdb-rhbz947564-findvar-assertion-frame-failed-testcase.patch
gdb-rhbz1007614-memleak-infpy_read_memory-test.patch
gdb-6.6-buildid-locate-misleading-warning-missing-debuginfo-rhbz981154.patch
gdb-rhbz1156192-recursive-dlopen-test.patch
gdb-rhbz1149205-catch-syscall-after-fork-test.patch
gdb-rhbz1186476-internal-error-unqualified-name-re-set-test.patch
gdb-rhbz1350436-type-printers-error.patch
gdb-rhbz1084404-ppc64-s390x-wrong-prologue-skip-O2-g-3of3.patch
gdb-fedora-libncursesw.patch
gdb-opcodes-clflushopt-test.patch
gdb-rhbz1261564-aarch64-hw-watchpoint-test.patch
gdb-container-rh-pkg.patch
gdb-linux_perf-bundle.patch
gdb-add-index.patch
gdb-rhbz1553104-s390x-arch12-test.patch
gdb-backport-readline_support.patch
gdb-backport-fix-break-main-file-remove-fail.patch
gdb-sw22395-constify-target_desc.patch
gdb-rhbz2143992-libiberty-fix-c89isms-in-configure.patch
gdb-rhbz2152431-label-symbol-value.patch
gdb-backport-python-config-replace-deprecated-distutils.patch
gdb-gcc-13-backport-self-move-diagnostic-fix
gdb-backport-call-check_typedef-at-beginning-of-dwarf_expr_context.patch
gdb-rhbz2153228-fail-if-sh_info-is-zero.patch
libiberty-infinite-recursion-fix-1-of-2.patch
libiberty-infinite-recursion-fix-2-of-2.patch
libiberty-infinite-recursion-fix-3-of-3.patch

6
gating.yaml Normal file
View File

@ -0,0 +1,6 @@
--- !Policy
product_versions:
- rhel-9
decision_context: osci_compose_gate
rules:
- !PassingTestCaseRule {test_case_name: baseos-ci.brew-build.tier1.functional}

View File

@ -0,0 +1,81 @@
#!/bin/sh
# Generic function to print an error message and bail out.
die ()
{
echo $1 > /dev/stderr
exit 1
}
# Print usage
usage ()
{
cat <<EOF
$0 -- Generate a git repository from .patch files
Usage:
$0 [-u] [-h] <REPOSITORY>
<REPOSITORY> is the directory where the rebase was performed. You
need to clone the repository first.
Options are:
-h: Print this message
-u: Uncommit all patches and initialize stgit repo
EOF
exit 0
}
test -f gdb.spec || die "This script needs to run from the same directory as gdb.spec."
test -z $1 && die "You need to specify the repository."
test "$1" = "-h" && usage
uncommit=0
if [ "$1" = "-u" ]; then
command -v stg > /dev/null 2>&1 \
|| die "Cannot find stg. Is stgit installed?"
uncommit=1
shift
fi
git_repo=$1
if [ ! -e $git_repo ]; then
echo "$0: repository \"$git_repo\" does not exist"
exit 1
fi
test -f _git_upstream_commit || die "Cannot find _git_upstream_commit file."
test -f _patch_order || die "Cannot find _patch_order file."
last_ancestor_commit=`cat _git_upstream_commit`
cd $1
git name-rev $last_ancestor_commit
test $? -eq 0 || die "Could not find $last_ancestor_commit in the repository $1. Did you run 'git fetch'?"
f=`cd .. && pwd`
# Create a branch for the checkout if using stgit; use the distro name in
# the name of this branch.
if (($uncommit)); then
name=devel-`basename $f`
branch="-b $name"
else
branch=""
fi
git checkout $branch $last_ancestor_commit
echo "Applying patches..."
for p in `cat ../_patch_order` ; do
git am ../$p
test $? -eq 0 || die "Could not apply patch '$p'."
done
if (($uncommit)); then
echo "Uncommitting patches..."
stg init
stg uncommit -t $last_ancestor_commit -x
fi

101
generate-patches-from-git-repo.sh Executable file
View File

@ -0,0 +1,101 @@
#!/bin/sh
# Generic function to print an error message and bail out.
die ()
{
echo $1 > /dev/stderr
exit 1
}
# Print usage
usage ()
{
cat <<EOF
$0 -- Generate .patch files for a RPM package from a git repository
Usage:
$0 <REPOSITORY> [<COMMIT_OR_TAG_OR_BRANCH>]
<REPOSITORY> is the directory where the rebase was performed.
<COMMIT_OR_TAG_OR_BRANCH> is the commit or tag or branch against which
the rebase was performed. It generally just needs to be provided if
the file "_git_upstream_commit" doesn't exist, or if you are doing a
rebase. This script will then use 'git merge-base' to find the most
recent common ancestor between HEAD and COMMIT_OR_TAG_OR_BRANCH.
Options are:
-h: Print this message
EOF
exit 0
}
test -f gdb.spec || die "This script needs to run from the same directory as gdb.spec."
test -z $1 && die "You need to specify the repository."
test "$1" = "-h" && usage
commit_or_tag="`cat _git_upstream_commit`"
if test ! -z "$2" ; then
commit_or_tag="$2"
fi
test -z $commit_or_tag && die "Because the '_git_upstream_commit' file doesn't exist, you need to specify a commit/tag/branch."
test -d $1 || die "$1 is not a directory."
# Remove all the current patches
for f in `cat _patch_order` ; do
git rm -f $f
done
cd $1
# If patches were uncommitted when the patches were applied,
# make sure that we're sitting at the top-most patch. Otherwise
# we'll only add patches up to the current top patch.
# It's safe to just assume stgit was used -- the push will simply
# fail.
stg push --all > /dev/null 2>&1
git name-rev $commit_or_tag
test $? -eq 0 || die "Could not find $commit_or_tag in the repository. Did you run 'git fetch'?"
idx=1
common_ancestor=`git merge-base HEAD $commit_or_tag`
test -z "$common_ancestor" && die "Could not find common ancestor between HEAD and $commit_or_tag."
temp_PATCH_file=/tmp/_gdb.spec.Patch.include
temp_patch_file=/tmp/_gdb.spec.patch.include
temp_patch_order_file=/tmp/_patch_order
rm -f $temp_PATCH_file $temp_patch_file $temp_patch_order_file
for c in `git rev-list --reverse ${common_ancestor}..HEAD` ; do
fname=`git log -1 --pretty='format:%s' $c`
test -z $fname && die "Could not determine filename for commit $c."
# Because git-format-patch generates patches with the first line
# containing the commit hash, every time we do a git-format-patch
# here we will have a different .patch file from what we had
# before, even if nothing has changed. This is bad, so we replace
# the commit hash by something constant (the string
# "FEDORA_PATCHES").
git format-patch --no-signature --no-stat --keep-subject -1 --stdout $c | sed -e '1 s/^From [0-9a-f]\+ \(.*\)/From FEDORA_PATCHES \1/' -e '/^index [0-9a-f]\+\.\.[0-9a-f]\+.*$/d' > ../$fname
(cd .. && git add $fname)
cat >> $temp_PATCH_file <<EOF
`git log -1 --pretty='format:%b' $c | sed -n 's/^;;/#/p'`
EOF
printf "Patch%03d: %s\n\n" $idx $fname >> $temp_PATCH_file
printf "%%patch%03d -p1\n" $idx >> $temp_patch_file
echo $fname >> $temp_patch_order_file
idx=`expr $idx + 1`
done
cd ..
mv $temp_PATCH_file _gdb.spec.Patch.include
mv $temp_patch_file _gdb.spec.patch.include
mv $temp_patch_order_file _patch_order
echo "$common_ancestor" > _git_upstream_commit

3
sources Normal file
View File

@ -0,0 +1,3 @@
SHA512 (gdb-12.1.tar.xz) = 425568d2e84672177d0fb87b1ad7daafdde097648d605e30cf0656970f66adc6a82ca2d83375ea4be583e9683a340e5bfdf5819668ddf66728200141ae50ff2d
SHA512 (gdb-libstdc++-v3-python-8.1.1-20180626.tar.xz) = a8b1c54dd348cfeb37da73f968742896be3dd13a4215f8d8519870c2abea915f5176c3fa6989ddd10f20020a16f0fab20cbae68ee8d58a82234d8778023520f8
SHA512 (v2.0.5.tar.gz) = 2e7ac2aede84671b15597d9c56dbe077a81357bbf44b6684802592246fb7729b4a5743238ddf02f6ea143b4d29872f581408135f9c1ea1ccc99dab905916d98d

31
tests/README Normal file
View File

@ -0,0 +1,31 @@
Justification
Adds tests according to the CI wiki specifically the standard test
interface in the spec.
The playbook includes Tier1 level test cases that have been tested in
the following contexts and is passing reliably: Classic and
Container. Test logs are stored in the artifacts directory.
The following steps are used to execute the tests using the standard
test interface: Test environment
Make sure you have installed packages from the spec
# rpm -q ansible python2-dnf libselinux-python standard-test-roles
ansible-2.3.2.0-1.fc26.noarch
python2-dnf-2.6.3-11.fc26.noarch
libselinux-python-2.6-7.fc26.x86_64
standard-test-roles-2.4-1.fc26.noarch
Run tests for Classic (must be run as root)
# export ANSIBLE_INVENTORY=$(test -e inventory && echo inventory || echo /usr/share/ansible/inventory)
# ansible-playbook --tags=classic tests.yml
Run tests for Container (must be run as root)
# export ANSIBLE_INVENTORY=$(test -e inventory && echo inventory || echo /usr/share/ansible/inventory)
# export TEST_SUBJECTS=docker:docker.io/library/fedora:26
# ansible-playbook --tags=container tests.yml

3
tests/inventory Executable file
View File

@ -0,0 +1,3 @@
#!/bin/bash
export TEST_DOCKER_EXTRA_ARGS="--privileged"
exec merge-standard-inventory "$@"

27
tests/tests.yml Normal file
View File

@ -0,0 +1,27 @@
---
# This first play always runs on the local staging system
- hosts: localhost
roles:
- role: standard-test-beakerlib
tags:
- classic
- container
repositories:
- repo: "git://pkgs.devel.redhat.com/tests/gdb"
dest: "gdb"
tests:
- gdb/Sanity/debug-toolset-binary
- gdb/Sanity/debug-system-binary
required_packages:
- gdb
- coreutils
- binutils
- binutils-debuginfo
- glibc
- glibc-debuginfo
- gcc
- gcc-debuginfo
- zlib
- zlib-debuginfo
- coreutils-debuginfo
- which