iproute-6.2.0-1.el8
* Wed Apr 26 2023 Andrea Claudi <aclaudi@redhat.com> - 6.2.0-1.el8 - New version 6.2.0 (Andrea Claudi) [RHEL-424] Resolves: RHEL-424 Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
This commit is contained in:
Andrea Claudi
parent
2427c43e5c
commit
aa5bb9071a
1
.gitignore
vendored
1
.gitignore
vendored
@ -1,2 +1,3 @@
|
||||
SOURCES/iproute2-5.18.0.tar.xz
|
||||
/iproute2-5.18.0.tar.xz
|
||||
/iproute2-6.2.0.tar.xz
|
||||
|
||||
170
README
Normal file
170
README
Normal file
@ -0,0 +1,170 @@
|
||||
Iproute Package Management
|
||||
==========================
|
||||
|
||||
This document describes how changes to the iproute2 RPM package are performed
|
||||
by its maintainer and provides useful information for everyone who needs to
|
||||
work on the iproute RPM package.
|
||||
|
||||
In the following, both contributors and maintainers workflow are described in
|
||||
details, to make them as easy as possible to understand. We define
|
||||
"contributors" all the people contributing patches and backports to iproute2,
|
||||
while we define "maintainers" all the people building the iproute2 RPM package
|
||||
for Red Hat distros.
|
||||
|
||||
The current workflow is conceived to be as similar as possible to the kernel
|
||||
one, so that kernel developers will ideally meet no barrier in contributing
|
||||
backports to iproute.
|
||||
|
||||
Every task is performed on a Git repository containing the actual iproute2
|
||||
sources. A dedicated redhat/ directory contains the necessary files to prepare
|
||||
a dist-git commit for a new release when desired.
|
||||
|
||||
|
||||
Git repository structure
|
||||
------------------------
|
||||
|
||||
The authoritative git repository for iproute2 RPM package is:
|
||||
|
||||
https://gitlab.cee.redhat.com/aclaudi/iproute2
|
||||
|
||||
There are several branches:
|
||||
- 'devel' is the branch for package management changes. It tracks latest
|
||||
upstream tagged version
|
||||
- 'upstream' tracks iproute2 upstream stable repository
|
||||
- 'upstream-next' tracks iproute2 upstream -next repository
|
||||
- several other branches, named as the distro, followed by the distro version
|
||||
after an hypen. E.g. 'rhel-7.3' is the relevant branch for RHEL-7.3 iproute
|
||||
package, while 'centos-9' is the branch for CentOS Stream 9.
|
||||
|
||||
|
||||
Contributor Workflow
|
||||
--------------------
|
||||
|
||||
Each contribution to the iproute2 package is expected to happen using a
|
||||
GitLab merge request (MR).
|
||||
|
||||
Contributors can follow these general instructions on submitting an MR using
|
||||
the GitLab UI[^1]. Kernel developers who are familiar with the
|
||||
link:lab.adoc[lab] GitLab command line tool can use it to submit MRs.
|
||||
|
||||
Merge requests and individual commits are expected to follow some basic rules:
|
||||
- Draft MR, i.e. MR not intended to be merged by the maintainer, should have a
|
||||
title prefixed with "Draft: "
|
||||
- Every MR and commit must contain a "Signed-off-by: " line.
|
||||
- Every MR and commit targeted at the package management files/scripts (e.g.
|
||||
addressing the redhat/ directory content) must be prefixed with '[redhat]' in
|
||||
the title.
|
||||
- Every MR and commit must contain a 'Bugzilla:' line, with the exception of
|
||||
'[redhat]' ones.
|
||||
|
||||
Each MR will trigger an iproute2 CI pipeline. This will be described in detail
|
||||
in the 'iproute2 package CI' paragraph.
|
||||
|
||||
[^1] https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html
|
||||
|
||||
|
||||
Maintainer workflow
|
||||
-------------------
|
||||
|
||||
The iproute2 package maintainers will take care of all the tasks related to the
|
||||
creation of a working RPM package for Red Hat distros. They also take care
|
||||
about gating issues, bugzilla issues, errata, etc.
|
||||
|
||||
Maintainers perform the following tasks on the iproute2 RPM git repository:
|
||||
- Create branches for each distro version;
|
||||
- Check, review, approve and merge contributions;
|
||||
- Review CI pipelines results, and fix it when needed;
|
||||
- Rebasing the package to a new upstream version;
|
||||
- Tag and build new package versions.
|
||||
|
||||
When creating a new branch, the maintainer ensure it uses the correct naming,
|
||||
e.g. rhel-8.6, centos-9 or fedora-36. Also, before pushing the new branch, the
|
||||
maintainer should execute `cd redhat && make <distro>`; this ensure the proper
|
||||
vars are used for the RPM package generation.
|
||||
|
||||
Before merging any contribution, the maintainer should check that MRs and
|
||||
commits follow the guidelines outlined in the 'Contributor Workflow' section;
|
||||
the maintainer should also check CI results are PASS.
|
||||
|
||||
Finally, to tag and build a new package version, the maintainer should use the
|
||||
following command:
|
||||
|
||||
`cd redhat && make`
|
||||
|
||||
This command performs a series of operations detailed below in the 'How does cd
|
||||
redhat && make works?' section, and ends printing the iproute dist-git repository
|
||||
path in the /tmp directory.
|
||||
|
||||
The maintainer is expected to cd into this directory, look at the changes,
|
||||
inspect the diff file, perform a test build, and generally to check everything
|
||||
is fine with the package. If this is the case, a new release can be finalized:
|
||||
|
||||
1) Commit the already added changes, using the 'changelog' file as commit
|
||||
message (it lists the BZ IDs as well, so the Git server hooks can validate if
|
||||
the changes are allowed or not).
|
||||
2) Push the new commit.
|
||||
3) Proceed with the regular release process, i.e. triggering a brew/koji build,
|
||||
updating the resolved BZ tickets and the errata.
|
||||
|
||||
To rebase the package to a new version, the BUILD variable in the distro.mk
|
||||
file should be moved back to 1. In this case the build process will ask for
|
||||
the rebase bugzilla number, and will output a single-entry changelog detailing
|
||||
the new version. All old patches will be removed and a new tarball will be
|
||||
downloaded from upstream, ready for distro packager upload.
|
||||
|
||||
|
||||
iproute2 package CI
|
||||
-------------------
|
||||
|
||||
A minimal CI pipeline is included in the .gitlab-ci.yml file. The purpose of
|
||||
this pipeline is to perform some basic tests (e.g. build the source and the rpm
|
||||
package) and ensure the code is ok to be released. If the RPM package build
|
||||
ends successfully, x86_64 packages will be stored as an artifact.
|
||||
|
||||
Contributors interested in testing changes not yet committed upstream can use a
|
||||
"Draft" MR on the devel branch to trigger the pipeline and have an RPM package
|
||||
built for them, ready to be tested by QE or anyone.
|
||||
|
||||
A nightly CI build rebases upstream and upstream-next branches to the latest
|
||||
upstream, and builds an RPM package ready to be used by anyone for testing
|
||||
purposes.
|
||||
|
||||
|
||||
How does 'cd redhat && make' works?
|
||||
-----------------------------------
|
||||
|
||||
Calling make inside the redhat/ subdirectory is the way produce a new iproute2
|
||||
release for a given distro, be it RHEL, Fedora or CentOS. Obviously, the
|
||||
correct distro packager should be installed to make this possible (i.e. rhpkg,
|
||||
fedpkg or centpkg), and the user should have a valid kerberos ticket.
|
||||
|
||||
This is what happens when make is called:
|
||||
|
||||
1) Release preparations are performed:
|
||||
a) Incrementing the BUILD variable in redhat/distro.mk
|
||||
b) Copying the specfile template to redhat/rpm/SOURCES/iproute.spec and
|
||||
updating it's changelog (basically a list of subjects, but with BZ ID
|
||||
added).
|
||||
c) Copying redhat/rpm/SOURCES/iproute.spec to redhat/rpm/SPECS/
|
||||
d) Copying additional files to redhat/rpm/SOURCES/
|
||||
e) Fetching the updated changelog back from redhat/rpm/SPECS/iproute.spec to
|
||||
the template file
|
||||
|
||||
2) A new release is created, which includes:
|
||||
a) Committing the updated redhat/distro.mk and redhat/iproute.spec.template as
|
||||
the final release commit
|
||||
b) Finally, an annotated tag is created. This will serve as the base reference
|
||||
for the next release, e.g. when creating changelog entries.
|
||||
|
||||
3) The dist-git repository is cloned and prepared for committing:
|
||||
a) A config for customization of this step is read from redhat/distro.mk
|
||||
b) The relevant tree is cloned to a temporary directory
|
||||
c) The right branch is checked out
|
||||
d) Files from redhat/rpm/SOURCES/ are copied into the clone and added
|
||||
e) A diff is created for review (should be empty)
|
||||
f) A changelog file is created, which will serve as template for the upcoming
|
||||
commit's message
|
||||
|
||||
Finally, the process ends printing the path of the dist-git repository,
|
||||
tipically in the /tmp directory.
|
||||
|
||||
22
iproute.spec
22
iproute.spec
@ -1,7 +1,7 @@
|
||||
Summary: Advanced IP routing and network device configuration tools
|
||||
Name: iproute
|
||||
Version: 5.18.0
|
||||
Release: 1%{?dist}%{?buildid}
|
||||
Version: 6.2.0
|
||||
Release: 1.el8
|
||||
%if 0%{?rhel}
|
||||
Group: Applications/System
|
||||
%endif
|
||||
@ -9,7 +9,7 @@ URL: https://kernel.org/pub/linux/utils/net/%{name}2/
|
||||
Source0: https://kernel.org/pub/linux/utils/net/%{name}2/%{name}2-%{version}.tar.xz
|
||||
Source1: rt_dsfield.deprecated
|
||||
|
||||
License: GPLv2+ and Public Domain
|
||||
License: GPL-2.0-or-later AND NIST-PD
|
||||
BuildRequires: bison
|
||||
BuildRequires: elfutils-libelf-devel
|
||||
BuildRequires: flex
|
||||
@ -41,7 +41,7 @@ Summary: Linux Traffic Control utility
|
||||
%if 0%{?rhel}
|
||||
Group: Applications/System
|
||||
%endif
|
||||
License: GPLv2+
|
||||
License: GPL-2.0-or-later
|
||||
Requires: %{name}%{?_isa} = %{version}-%{release}
|
||||
Provides: /sbin/tc
|
||||
|
||||
@ -56,7 +56,7 @@ Summary: Documentation for iproute2 utilities with examples
|
||||
%if 0%{?rhel}
|
||||
Group: Applications/System
|
||||
%endif
|
||||
License: GPLv2+
|
||||
License: GPL-2.0-or-later
|
||||
Requires: %{name} = %{version}-%{release}
|
||||
|
||||
%description doc
|
||||
@ -68,7 +68,7 @@ Summary: iproute development files
|
||||
%if 0%{?rhel}
|
||||
Group: Development/Libraries
|
||||
%endif
|
||||
License: GPLv2+
|
||||
License: GPL-2.0-or-later
|
||||
Requires: %{name} = %{version}-%{release}
|
||||
Provides: iproute-static = %{version}-%{release}
|
||||
|
||||
@ -79,12 +79,11 @@ The libnetlink static library.
|
||||
%autosetup -p1 -n %{name}2-%{version}
|
||||
|
||||
%build
|
||||
%configure
|
||||
%configure --libdir %{_libdir}
|
||||
echo -e "\nPREFIX=%{_prefix}\nCONFDIR:=%{_sysconfdir}/iproute2\nSBINDIR=%{_sbindir}" >> config.mk
|
||||
%make_build
|
||||
|
||||
%install
|
||||
export SBINDIR='%{_sbindir}'
|
||||
export LIBDIR='%{_libdir}'
|
||||
%make_install
|
||||
|
||||
echo '.so man8/tc-cbq.8' > %{buildroot}%{_mandir}/man8/cbq.8
|
||||
@ -97,7 +96,7 @@ install -D -m644 lib/libnetlink.a %{buildroot}%{_libdir}/libnetlink.a
|
||||
rm -rf '%{buildroot}%{_docdir}'
|
||||
|
||||
# append deprecated values to rt_dsfield for compatibility reasons
|
||||
%if ! 0%{?fedora}
|
||||
%if 0%{?rhel} && ! 0%{?eln}
|
||||
cat %{SOURCE1} >>%{buildroot}%{_sysconfdir}/iproute2/rt_dsfield
|
||||
%endif
|
||||
|
||||
@ -140,6 +139,9 @@ cat %{SOURCE1} >>%{buildroot}%{_sysconfdir}/iproute2/rt_dsfield
|
||||
%{_includedir}/iproute2/bpf_elf.h
|
||||
|
||||
%changelog
|
||||
* Wed Apr 26 2023 Andrea Claudi <aclaudi@redhat.com> - 6.2.0-1.el8
|
||||
- New version 6.2.0 (Andrea Claudi) [RHEL-424]
|
||||
|
||||
* Wed Jun 08 2022 Wen Liang <wenliang@redhat.com> - 5.18.0-1.el8
|
||||
- New version 5.18.0 [2074607]
|
||||
|
||||
|
||||
1
sources
1
sources
@ -1 +1,2 @@
|
||||
SHA512 (iproute2-5.18.0.tar.xz) = 7b43c89741a8ffe8fd529ac4ee19c8eab7dce2f064de494c160c75456ffb960fb5f1e78c868ab98360dafde28d5e2c4d58177135b6d380e80e06eba9e3eaf068
|
||||
SHA512 (iproute2-6.2.0.tar.xz) = b24e0fdd0f51b8b78bc3bb681e3829af47d3011e93f3892289eb070b336709a6883728ecc7627ca37f6449720f8ed1349af321c0d04454894a7175b82f7de151
|
||||
|
||||
Loading…
Reference in New Issue
Block a user