feat: update tuned to 2.24.1

daemon for monitoring and adaptive tuning of system devices

Issue: deepin-community/sig-deepin-sysdev-team#558
Log: update repo

.fmf/version

@@ -0,0 +1 @@
+1

.packit.yaml

@@ -0,0 +1,21 @@
+srpm_build_deps: []
+upstream_tag_template: v{version}
+jobs:
+- job: copr_build
+  trigger: pull_request
+  targets:
+  - fedora-all
+  - epel-7-x86_64
+  - epel-8-x86_64
+  - centos-stream-9-x86_64
+- job: tests
+  trigger: pull_request
+  targets:
+  - fedora-all
+  - epel-7-x86_64
+  - epel-8-x86_64
+  - centos-stream-9-x86_64
+
+files_to_sync:
+- tuned.spec
+- .packit.yaml

00_tuned

@@ -0,0 +1,29 @@
+#! /bin/sh
+set -e
+
+# grub-mkconfig helper script.
+# Copyright (C) 2014 Red Hat, Inc
+# Author: Jaroslav Škarvada <[email protected]>
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+#
+
+tunedcfgdir=/etc/tuned
+tuned_bootcmdline_file=$tunedcfgdir/bootcmdline
+
+. $tuned_bootcmdline_file
+
+echo "set tuned_params=\"$TUNED_BOOT_CMDLINE\""
+echo "set tuned_initrd=\"$TUNED_BOOT_INITRD_ADD\""

92-tuned.install

@@ -0,0 +1,49 @@
+#!/bin/bash
+
+COMMAND="$1"
+KERNEL_VERSION="$2"
+BOOT_DIR_ABS="$3"
+KERNEL_IMAGE="$4"
+
+if ! [[ $KERNEL_INSTALL_MACHINE_ID ]]; then
+  exit 0
+fi
+
+MACHINE_ID=$KERNEL_INSTALL_MACHINE_ID
+
+# with grub2 always /boot
+BOOT_ROOT="/boot"
+LOADER_ENTRIES="$BOOT_ROOT/loader/entries"
+
+[ -d "$LOADER_ENTRIES" ] || exit 0
+
+[ "$COMMAND" = "add" ] || exit 0
+
+ARCH=`uname -m`
+
+pushd "$LOADER_ENTRIES" &> /dev/null
+for f in `basename "$MACHINE_ID"`-*.conf; do
+  # Skip non-files and rescue entries
+  if [ ! -f "$f" -o "${f: -12}" == "-rescue.conf" ]; then
+    continue
+  fi
+  # Skip boom managed entries
+  if [[ "$f" =~ \w*-[0-9a-f]{7,}-.*-.*.conf ]]; then
+    continue
+  fi
+
+  if [ "${ARCH:0:4}" = "s390" ]; then
+    # On s390(x), the zipl bootloader doesn't support variables,
+    # unpatch TuneD variables which could be there from the previous TuneD
+    # versions
+    grep -q '^\s*options\s\+.*\$tuned_params' "$f" && sed -i '/^\s*options\s\+/ s/\s\+\$tuned_params\b//g' "$f"
+    grep -q '^\s*initrd\s\+.*\$tuned_initrd' "$f" && sed -i '/^\s*initrd\s\+/ s/\s\+\$tuned_initrd\b//g' "$f"
+  else
+    # Not on s390(x), add TuneD variables if they are not there
+    grep -q '^\s*options\s\+.*\$tuned_params' "$f" || sed -i '/^\s*options\s\+/ s/\(.*\)/\1 \$tuned_params/' "$f"
+    grep -q '^\s*initrd\s\+.*\$tuned_initrd' "$f" || sed -i '/^\s*initrd\s\+/ s/\(.*\)/\1 \$tuned_initrd/' "$f"
+  fi
+done
+popd &> /dev/null
+
+exit 0

AUTHORS

@@ -0,0 +1,20 @@
+Maintainers:
+- Jaroslav Škarvada <[email protected]>
+
+Based on old tuned/ktune code by:
+- Philip Knirsch
+- Thomas Woerner
+
+Significant contributors:
+- Jan Včelák
+- Jan Kaluža
+
+Other contributors:
+- Petr Lautrbach
+- Marcela Mašláňová
+- Jarod Wilson
+- Jan Hutař
+- Arnaldo Carvalho de Melo <[email protected]> - perf code for plugin_scheduler
+
+Icon:
+- Mariia Leonova <[email protected]>

CONTRIBUTING.md

@@ -0,0 +1,66 @@
+Contributing to TuneD
+=====================
+
+Submitting patches
+------------------
+
+All patches should be based on the most recent revision of TuneD, which is
+available on [GitHub](https://github.com/redhat-performance/tuned).
+
+Patches should be created using `git` and the commit message should generally
+consist of three parts:
+1. The first line, which briefly describes the change that you are making.
+2. A detailed description of the change. This should include information
+   about the purpose of the change, i.e. why you are making the change in
+   the first place. For example, if your patch addresses a bug, give
+   a description of the bug and a way to reproduce it, if possible. If your
+   patch adds a new feature, describe how it can be used and what it can be
+   used for.
+
+   Think about the impact that your change can have on the users. If your
+   patch changes the behavior in a user-visible way, you should mention it
+   and justify why the change should be made anyway.
+
+   You should also describe any non-trivial design decisions that were made
+   in making of the patch. Write down any gotchas that could be useful for
+   future readers of the code, any hints that could be useful to determine
+   why the change was made in a particular way.
+
+   You can also provide links, for example links to any documentation that
+   could be useful for reviewers of the patch, or links to discussions about
+   a bug that your patch addresses. If your patch resolves a bug in the Red Hat
+   Bugzilla, you can link to it using the following tag:
+
+   `Resolves: rhbz#1592743`
+
+   If your patch addresses an issue in the GitHub repository, you can use
+   the following notation:
+
+   `Fixes #95`
+3. Your sign-off. Every commit needs to have a `Signed-off-by` tag at the end
+   of the commit message, indicating that the contributor of the patch agrees
+   with the [Developer Certificate of Origin](/DCO). The tag should have the
+   following format and it must include the real name and email address of
+   the contributor:
+
+   `Signed-off-by: John Doe <[email protected]>`
+
+   If you use `git commit -s`, `git` will add the tag for you.
+
+Every patch should represent a single logical change. On the one hand, each
+patch should be complete enough so that after applying it, the TuneD repository
+remains in a consistent state and TuneD remains, to the best of the
+contributor's knowledge, completely functional (a corollary of this is that
+when making fixes to your pull request on GitHub, you should include the fixes
+in the commits where they logically belong rather than appending new commits).
+
+On the other hand, a patch should not make multiple changes which could be
+separated into individual ones.
+
+Patches can either be submitted in the form of pull requests to the GitHub
+repository, sent to the power-management (at) lists.fedoraproject.org mailing
+list, or sent directly to the maintainers of the TuneD project.
+
+These guidelines were inspired by the [contribution guidelines of the Linux
+Kernel](https://www.kernel.org/doc/html/latest/process/submitting-patches.html).
+You can find more rationale for TuneD's guidelines in that document.