Giter VIP home page Giter VIP logo

dnf-plugins-core's Introduction

Core DNF Plugins

Core plugins to use with DNF package manager.

Installation

RPM packages are available in official Fedora repositories:

dnf install dnf-plugins-core

Nigthly builds can be installed from copr repository.

Building from source

From the DNF git checkout directory:

mkdir build;
pushd build;
cmake .. && make;
popd;

CMake optional switches:

-DWITHOUT_LOCAL:str=1
    Different string value than "0" disables installing a local plugin.

-DWITHOUT_DEBUG:str=1
    Different string value than "0" disables installing a debug plugin.

Then to run DNF:

PYTHONPATH=`readlink -f .` bin/dnf <arguments>

Running tests

From the DNF git checkout directory:

mkdir build;
pushd build;
cmake .. && make ARGS="-V" test;
popd;

Contribution

Here's the most direct way to get your work merged into the project.

  1. Fork the project

  2. Clone down your fork

  3. Implement your feature or bug fix and commit changes

  4. If the change fixes a bug at Red Hat bugzilla, or if it is important to the end user, add the following block to the commit message:

    = changelog =
    msg:           message to be included in the changelog
    type:          one of: bugfix/enhancement/security (this field is required when message is present)
    resolves:      URLs to bugs or issues resolved by this commit (can be specified multiple times)
    related:       URLs to any related bugs or issues (can be specified multiple times)
    
    • For example:

      = changelog =
      msg: [download] Respect repo priority
      type: bugfix
      resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1800342
      
    • For your convenience, you can also use git commit template by running the following command in the top-level directory of this project:

      git config commit.template ./.git-commit-template
      
  5. In a separate commit, add your name and email under DNF-PLUGINS-CORE CONTRIBUTORS section in the authors file as a reward for your generosity

  6. Push the branch up to your fork

  7. Send a pull request for your branch

Please do not create pull requests with translation (.po) file improvements. Fix the translation on Fedora Weblate instead.

Documentation

The DNF-PLUGINS-CORE package distribution contains man pages dnf.plugin.*(8). It is also possible to read the DNF-PLUGINS-CORE documentation online.

Bug reporting etc.

Please report discovered bugs to the Red Hat bugzilla following this guide. If you planned to propose the patch in the report, consider contribution instead.

Freenode's irc channel #yum is meant for discussions related to both Yum and DNF. Questions should be asked there, issues discussed. Remember: #yum is not a support channel and prior research is expected from the questioner.

dnf-plugins-core's People

Contributors

andersblomdell avatar atodorov avatar cam-rod avatar conan-kudo avatar dhgutteridge avatar dmnks avatar dturecek avatar dustymabe avatar evan-goode avatar frostyx avatar ignatenkobrain avatar inknos avatar j-mracek avatar jan-kolarik avatar jrohel avatar kontura avatar m-blaha avatar max9631 avatar maxamillion avatar michaelmraka avatar mluscon avatar pghmcfc avatar pkratoch avatar pnemade avatar ppisar avatar praiskup avatar pspacek avatar radekholy24 avatar schlupov avatar xsuchy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dnf-plugins-core's Issues

Failed loading plugin "debuginfo-install": module 'dnf' has no attribute 'cli'

dnfdaemon is throwing me out the following error:
Failed loading plugin "debuginfo-install": module 'dnf' has no attribute 'cli'

I've looked at the code of debuginfo-install.py and found only:
import dnf
line.

Considering 'cli' module resides in its own subdirectory, shouldn't there be also a line:
import dnf.cli
there? Or, any 'cli' being referenced as 'dnf.cli' (and not just 'cli')?

I've manually added this import line, and it seems to resolve the issue (that error is not logged anymore at least).

Caching local plugin repo data prevents use of locally stored packages when used in back to back updates

Pardon the convoluted title.

Expected behavior:

  1. dnf update downloads to be updated packages, local plugin maintains a copy of downloaded package, and downloaded packages are installed on host 0
  2. Subsequent "dnf update" on hosts 1-n, after step 1 will not download updated packages but instead use copies maintained by local plugin

Actual behavior:

  1. Same as step 1 above
  2. Subsequent "dnf update" on hosts 1-n, when done shortly (O(minutes)) after step 1 will download updated packages again because, presumably, of cached data in /var/cache/dnf/_dnf_local*

The fact that the local plugin relies on cached repo data and therefore ignoring just downloaded updates seems to defeat the purpose of the local plugin if used to update multiple hosts at or around the same time.
If the cache is allowed to expire, is explicitly ignored with dnf command line options, or if the cached data is explicitly deleted before subsequent updates (e.g., rm -fr /var/cache/dnf/_dnf_local*) then the local plugin behaves as expected.

Syntax of `dnf config-manager --setopt`

The docs says:

dnf config-manager [options] <section>...
...
<section>
This argument can be used to explicitly select the configuration sections to manage. A section can either be main or a repoid. If not specified, the program will select the main section and each repoid used within any --setopt options. A repoid can be specified using globs.
...
--setopt=<option>=<value>
Set a configuration option. To set configuration options for repositories, use repoid.option for the <option>. Globs are supported in repoid.
..
dnf config-manager --save --setopt=*.proxy=http://proxy.example.com:3128/ <repo1> <repo2>
Update proxy setting in repositories with repoid and and make the change permanent.

And this brings to my mind the following questions:
What is the difference between dnf config-manager --save --setopt=test.proxy=example.com and dnf config-manager --save --setop=proxy=example.com test?

If " If not specified, the program will select the main section and each repoid used within any --setopt options. A repoid can be specified using globs." is true, does dnf config-manager --save --setopt=*.proxy=http://proxy.example.com:3128/ <repo1> <repo2> will change repo1, repo2 and main confs?

`dnf offline-upgrade --poweroff reboot` causes a post-upgrade reboot instead of the intended shutdown

I originally asked about this on the Fedora forums, where Chris Williams explains the cause of the problem in one of his posts in that thread. The short version is that after the upgrade has finished, systemd kills dnf-system-upgrade.service with SIGTERM, which is interpreted as a failure because it is a oneshot type service. This failure then triggers a reboot instead of the expected shutdown.

I'm on Fedora 39 and dnf-plugins-core version 4.5.0.

Flag --poweroff does not poweroff my F38 system after a successful upgrade

Running dnf system-upgrade reboot --poweroff on my system does not poweroff the system, and is equivalent to running dnf system-upgrade reboot alone without providing the --poweroff flag.

Expected behavior: the system powers off after performing the upgrade
Actual behavior on my machine: the system boots to GUI (gdm)

These are my system info

inxi -v 4
System:
  Host: Helios Kernel: 6.4.15-200.fc38.x86_64 arch: x86_64 bits: 64
    compiler: gcc v: 2.39-9.fc38 Desktop: GNOME v: 44.5 Distro: Fedora release
    38 (Thirty Eight)
Machine:
  Type: Laptop System: HP product: HP Pavilion Laptop 14-dv0xxx
    v: Type1ProductConfigId serial: <superuser required>
  Mobo: HP model: 87C9 v: 34.27 serial: <superuser required> UEFI: Insyde
    v: F.14 date: 05/06/2021
Battery:
  ID-1: BAT0 charge: 33.1 Wh (88.7%) condition: 37.3/37.3 Wh (100.0%)
    volts: 12.9 min: 11.6 model: HP Primary status: charging
  Device-1: hid-f4:73:35:85:6b:75-battery model: Keyboard K380 charge: N/A
    status: discharging
CPU:
  Info: quad core model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP
    arch: Tiger Lake rev: 1 cache: L1: 320 KiB L2: 5 MiB L3: 12 MiB
  Speed (MHz): avg: 1686 high: 2800 min/max: 400/4700 cores: 1: 854 2: 799
    3: 1146 4: 2800 5: 2800 6: 1243 7: 2800 8: 1047 bogomips: 44851
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] vendor: Hewlett-Packard
    driver: i915 v: kernel arch: Gen-12.1 bus-ID: 0000:00:02.0
  Device-2: Luxvisions Innotech HP Wide Vision HD Camera driver: uvcvideo
    type: USB bus-ID: 3-3:3
  Display: wayland server: X.Org v: 22.1.9 with: Xwayland v: 22.1.9
    compositor: gnome-shell driver: dri: iris gpu: i915
    resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 23.1.7 renderer: Mesa Intel Xe Graphics (TGL GT2)
    direct-render: Yes
Network:
  Device-1: Intel Wi-Fi 6 AX201 driver: iwlwifi v: kernel bus-ID: 0000:00:14.3
  IF: wlp0s20f3 state: up mac: 18:26:49:e0:4d:5e
Drives:
  Local Storage: total: 476.94 GiB used: 399.46 GiB (83.8%)
  ID-1: /dev/nvme0n1 vendor: Intel model: SSDPEKNW512G8H size: 476.94 GiB
    temp: 38.9 C
Partition:
  ID-1: / size: 466.8 GiB used: 399.16 GiB (85.5%) fs: ext4 dev: /dev/dm-1
    mapped: fedora_localhost--live-root
  ID-2: /boot size: 973.4 MiB used: 291.8 MiB (30.0%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 598.8 MiB used: 17.4 MiB (2.9%) fs: vfat
    dev: /dev/nvme0n1p1
Info:
  Processes: 316 Uptime: 9m Memory: total: 16 GiB available: 15.38 GiB
  used: 3.46 GiB (22.5%) Init: systemd target: graphical (5) Compilers:
  gcc: 13.2.1 clang: 16.0.6 Packages: 70 note: see --rpm Shell: Zsh v: 5.9
  inxi: 3.3.29

Deprecate needs-restarting

The plugin needs-restarting has a naive implementation and gives users false hope that they get notified when system needs restarting. But that is not true when any dependence of running services is updated and the service needs to be restarted to load the newly updated library.

There is a much better plugin available https://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html

I propose that we deprecate needs-restarting and point users that they should use dnf-plugins-extras-tracer.

I suggest two phases:

  1. first, just print a warning that in future version this plugin will be removed.
  2. After 12 months, make this warning fatal. But the plugin will still exists.
  3. After the next 12 months, remove the plugin entirely.

[Bug/Feature?]`download` doesn't support `--skip-broken`

Running a command like:

dnf download {...} --resolve --all-deps --exclude=basesystem --skip-broken curl

ignores the --skip-broken and errors out on the missing basesystem requirement being unmet. As I understand it, the --skip-broken is explicitly supposed to prevent this type of error and allow it to continue normally.


My use case is that I would like to download a package and all it's recursive install dependencies, for an air-gapped system from another similar-but-not-exactly-the-same system. I don't want to include the portions of the dependency tree that I know in advance are already present on the air-gapped system, like basesystem.

config-manager --add-repo

Hi!

The docs says following:
--add-repo=URL
Add (and enable) the repo from the specified file or url. If it has to be added into installroot, combine it with --setopt=reposdir=/<installroot>/etc/yum.repos.d command-line option.”

So, if I understand right, --add-repo can also enable (set value of enabled 1) the spesified repo.
But, when I tested use --add-repo flag to enabling .repo file, it didn’t work 😦

Command sudo dnf config-manager --add-repo /tmp/test.repo just moves test.repo to path /etc/yum.repos.d/.

See: https://discussion.fedoraproject.org/t/how-dnfs-config-manager-plugin-technically-works/88084/16

DNF version lock for kernel version

Hi, I would like to suggest that there are an option to do soft lock for kernel version.

Means it will keep a locked version but it still do install the newest kernel to try instead that it will just ignore new kernel update (it's act like 2nd safe boot).

`dnf download` with `--debuginfo` or `--debugsource` doesn't respect `--resolve`

debuginfo packages can have dependencies.

Intended behavior: dnf download with --debuginfo --resolve downloads the requested debuginfo package with its dependencies.
Actual current behavior: Dependencies are not downloaded. Tested with package libstdc++-debuginfo which depends on gcc-debuginfo.

I believe the same to --debugsource although I'm unaware of any debugsource packages have dependencies and don't know if it exists.

Please provide better explanation of "trigger file does not exist. exiting quietly." error message

On 2022-08-12, I was trying to upgrade fully updated but EOL F33 system to something more recent, such as F35/F36. However, the upgrade failed with "trigger file does not exist. exiting quietly." error message very likely coming from here:

https://github.com/rpm-software-management/dnf-plugins-extras/blob/cef43db2014673c528a2f13eaf1c72ecef5f0734/plugins/system_upgrade.py#L534

But I am quite unsure, what it does mean and what should I do about to proceed further. Therefore could you please provide some helpful message of what is really going on? This one is useless.

`dnf copr enable` doesn't work on Fedora Rawhide

When running dnf copr enable on Fedora Rawhide, I get an error that the right chroot wasn't found, even though it definitely exists:

[root@06d693b9bfa6 /]# cat /etc/os-release 
NAME="Fedora Linux"
VERSION="39 (Container Image Prerelease)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Container Image Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
SUPPORT_END=2024-05-14
VARIANT="Container Image"
VARIANT_ID=container
[root@06d693b9bfa6 /]# dnf -y copr enable @osbuild/osbuild
 https://copr.fedorainfracloud.org/api_3/rpmrepo/@osbuild/osbuild/fedora-39/                                                                                                                           100% |   1.6 KiB/s | 929.0   B |  00m01sChroot not found in the given Copr project (fedora-39-x86_64).
You can choose one of the avaiable chroots explicitly:
 centos-stream-8-aarch64
 centos-stream-8-x86_64
 centos-stream-9-aarch64
 centos-stream-9-x86_64
 epel-8-aarch64
 epel-8-x86_64
 epel-9-aarch64
 epel-9-x86_64
 fedora-36-aarch64
 fedora-36-ppc64le
 fedora-36-s390x
 fedora-36-x86_64
 fedora-37-aarch64
 fedora-37-ppc64le
 fedora-37-s390x
 fedora-37-x86_64
 fedora-38-aarch64
 fedora-38-ppc64le
 fedora-38-s390x
 fedora-38-x86_64
 fedora-rawhide-aarch64
 fedora-rawhide-ppc64le
 fedora-rawhide-s390x
 fedora-rawhide-x86_64

Error triggered when multiple Copr repositories are specified

dnf .v: 4.16.1 | Hello.

  • Error triggered when multiple Copr repositories are specified
# dnf copr enable sunwire/ssh-audit atim/starship
Error: Bad format of optional chroot. The format is distribution-version-architecture.
  • No error triggered when a single Copr repository is specified
# dnf -qy copr enable sunwire/ssh-audit
Enabling a Copr repository. (...) owner of this repository.
# 

Improve dnf config-manager --setopt documentation

This is a follow-up to #505. We should improve the documentation regarding the --setopt option because it's currently unclear which sections will be affected, especially when using the option together with the repoid parameter selector.

copr plugin: _guess_chroot does not handle centos stream properly

I am trying to enable repo on centos stream 9 "dnf -y copr enable --hub copr.fedorainfracloud.org @sssd/pr7193"
It is incorrectly defaulting to epel-9-x86_64 instead of centos-stream-9-x86_64:

2024-03-01T11:35:55 Repository 'epel-9-x86_64' does not exist in project '@sssd/pr7193'.
2024-03-01T11:35:55 Available repositories: 'fedora-38-x86_64', 'fedora-40-x86_64', 'centos-stream-9-x86_64', 'fedora-rawhide-x86_64', 'fedora-39-x86_64'

I do not want to put there repo explicitly as I want to reuse same code on centos, fedora and rhel.

`generate_completion_cache` does not respect `--setopt=cachedir`

The cache file of the plugin is hard-coded in the code and does not respect --setopt=cachedir:

self.cache_file = "/var/cache/dnf/packages.db"

This causes problems in situations where /var/tmp isn't writable.


Also, there seem some bug in some sqlite3 connected C code called by this plugin, leading a segmentation fault in case the cache dir cannot be created. I didn't find the time to track this down, but here is the error in case you are interested in looking into this:

       > Fedora Release                                  162 MB/s |  34 MB     00:00
       > Fedora Updates                                  162 MB/s |  34 MB     00:00
       > Last metadata expiration check: 0:00:08 ago on Thu Nov 16 11:26:11 2023.
       > Fatal Python error: Segmentation fault
       >
       > Current thread 0x00007ffff7ea7740 (most recent call first):
       >   File "/nix/store/qmslfhyfafm34m6wifipbwnscd1wl2vb-python3.11-dnf-plugins-core-4.4.3/lib/python3.11/site-packages/dnf-plugins/generate_completion_cache.py", line 54 in sack
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/plugin.py", line 107 in _caller
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/plugin.py", line 158 in run_sack
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/base.py", line 437 in fill_sack
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/cli.py", line 741 in _process_demands
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/cli.py", line 1040 in run
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 122 in cli_run
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 106 in _main
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 67 in main
       >   File "/nix/store/ilqbyzl64hy2wfzyg7zp8vir5kwzwq8a-python3.11-dnf4-unwrapped-4.18.1-py/lib/python3.11/site-packages/dnf/cli/main.py", line 201 in user_main
       >   File "/nix/store/m0pla3gf4jx047iyskj96qh4mv04g1li-dnf4-with-plugins/bin/.dnf4-wrapped", line 63 in <module>

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.