rpm-software-management / dnf-plugins-extras Goto Github PK
View Code? Open in Web Editor NEWrepository for DNF community plugins
License: GNU General Public License v2.0
repository for DNF community plugins
License: GNU General Public License v2.0
An upgrade from F29 to rawhide fails because it tries to pull a repo that doesn't exist:
upgrade.txt
Pulling the metalink manually reveals that while the upgrade looks for fedora-modular-rawhide
it likely should be looking for rawhide-modular
instead.
Currently, when "dnf upgrade" is run on a system on which packages have previously been upgraded since the last reboot and there are no new upgrades to install the output of tracer is not displayed. This is particularly suboptimal on systems where dnf-automatic is being run.
Hello,
I want to ask you, if it would be possible to continue building rpm packages for Fedora 21.
One thing is that latest version of package dnf-plugins-extras-tracer
in the repository is basically broken. It throws traceback every time. In the next commit, you fixed it by yourself, @ignatenkobrain and for F22 it works, but there are missing builds for F21.
Moreover, Tracer is my thesis and I will probably hand it over to my opponent in a few weeks and it would be nice if he gets the latest version. Ofc I don't know what version of Fedora he will use, but F21 is current stable, so I guess that will be it.
Thank you,
FrostyX
(was rpm-software-management/dnf-plugin-system-upgrade#60)
I installed fedora 35 as a WSL distribution following this guide: https://dev.to/bowmanjd/install-fedora-on-windows-subsystem-for-linux-wsl-4b26
Then, I tried to follow these instructions to upgrade to 36: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
Here is the error I encountered:
$ sudo dnf system-upgrade download --releasever=36
$ sudo dnf system-upgrade reboot
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
I found the system-upgrade upgrade
command, ran it, and that seemed to work. Is this expected behavior?
Over the past two years, I've been working on a new version of pykickstart that cleans up a bunch of stuff and corrects some inherent flaws, as well as stops using certain deprecated python modules. The result is that there are some incompatibilities between v2 and v3. The projects that are most affected are the ones that really dig in and do a lot of custom stuff. It's been in the works a long time now and with anaconda starting to adapt, I feel like it's probably time to get rid of pykickstart-2 and use pykickstart-3 in Fedora.
There is a copr with the new version here: https://copr.fedorainfracloud.org/coprs/clumens/pykickstart-3/, and there's a document describing the changes here: https://github.com/rhinstaller/pykickstart/blob/master/docs/2to3.
I've looked at dnf-plugin-kickstart.py and it doesn't look like there's anything that actually needs to change, however it would be worth double checking. If there's any specific tests that can be run, I'd be happy to try them out and develop any patches required. Any thoughts on this?
yum produced a nice neat log file which simply listed the dates and times for each package added, updated, and removed. This is extremely helpful for many purposes, such as:
An example of each type of entry in yum.log:
Apr 06 03:19:09 Updated: yum-3.2.29-81.el6.centos.noarch
May 25 20:10:54 Erased: postfix
Jul 12 05:59:27 Installed: kernel-2.6.32-696.3.2.el6.x86_64
Could this please be added to dnf?
Also, sorry if I've filed this in the wrong place -- it seems most of the dnf components don't allow reporting bugs / enhancement requests?
Description of problem:
DNF doesn't include an equivalent of the copr command to manage Open Build Service repositories (either on private OBS instances or on build.opensuse.org). It's rather irritating to manually add repositories, and having them managed through a plugin makes it easier to work with.
Version-Release number of selected component (if applicable):
dnf-plugins-core-0.1.10-1.fc22
dnf-plugins-extras-0.0.9-1.fc22
Extra notes:
I don't mind if this is an extras plugin instead of a core one, but it would be pretty nice if it was easier to list/add/remove OBS repos from a manageability perspective. Obviously, since OBS serves a number of RPM-based distros (Fedora, RHEL, CentOS, OpenSUSE, SLE, and Mageia), it would make sense for this plugin to be somewhat configurable to be able to support whatever naming/versioning scheme is used by these distributions.
via @Conan-Kudo from https://bugzilla.redhat.com/show_bug.cgi?id=1251959
With snapper you can set --userdata important=yes
when creating a snapshot which will make automatic cleanups more conservative by merit of supposedly being fewer and being counted separately. By default:
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"
meaning that for snapshots marked for the "number" cleanup algorithm, it will keep the last 50 normal snapshots and the last 10 important snapshots. So even if the 10th oldest important snapshot is older than the 50th oldest snapshot, it gets preserved.
On openSUSE, zypper
transactions are marked important, but snapper-boot.timer
snapshots and YaST commands (which create pre-post snapshots) are not. It would seem prudent to mimic them in this, and mark DNF snapshots important. Even if we don't have YaST, we do have snapper-boot.timer
and we do have snapper create --command
which can wrap any command in a pre-post snapshot. It would be useful for DNF upgrades to be preserved more conservatively than those uses.
I'm not clear on what happens to "important" snapshots that are older than NUMBER_LIMIT_IMPORTANT
but younger than NUMBER_LIMIT
; do they get deleted before unimportant snapshots or do they get demoted to unimportant and kept until that limit is reached? Either way the idea seems to be that important snapshots are much rarer, and so take longer to reach the limits. That's understandable on openSUSE which wraps every YaST command in a pre-post snapshot, but it's less likely to be the case on a Fedora system unless you use snapper create --cleanup-algorithm number --command {cmd}
liberally. But only by marking DNF snapshots important do we enable this use case, so it could be worth it. You can also adjust NUMBER_LIMIT_IMPORTANT
if you find that only keeping 10 as opposed to 50 DNF snapshots isn't enough for you. The main point is that they're kept up to that limit regardless of how many other "number" snapshots you create for other purposes.
Hi,
The local plugin does not create it's repository directory on my Fedora 22 computer.
Dnf-commands output the message "local: '/var/lib/dnf/plugins/local' is not a directory".
Claes
Problem: Fedora creates a rescue kernel and initramfs pair at initial installation, which are never updated.
This pair is created by /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh found in dracut-config-rescue-046-5.fc27.x86_64 which is part of the dracut package, and only happens if the rescue items are missing, which most typically is only at initial installation.
Solution: Delete the two rescue files before new major version kernel RPMs are installed. This will ensure replacement rescue kernel and initramfs are automatically generated.
When building dnf-plugins-extras in Mageia Cauldron, the tests bombed out on the repoclosure, repograph, and repomanage plugins.
Based on the error, it appears to be caused by libdnf. The version of libdnf in Mageia Cauldron is libdnf-0.7.0-0.2.git20161125.2d8ba15.mga6, which corresponds to rpm-software-management/libdnf@2d8ba15.
It last worked with rpm-software-management/libdnf@248dc84 + rpm-software-management/libdnf#213 on top in my dnf2-mga COPR.
The full build log is available for further analysis.
dnf-3.6.1-1.fc29.noarch
`dnf-plugins-core-3.0.4-1.fc29.noarch
Fedora 29
[dvitali@pixelc ~]$ sudo dnf system-upgrade download --refresh --releasever=rawhide
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Traceback (most recent call last):
File "/usr/bin/dnf", line 58, in <module>
main.user_main(sys.argv[1:], exit_code=True)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main
errcode = main(args)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 95, in _main
cli.configure(list(map(ucd, args)), option_parser())
File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 910, in configure
self.command.configure()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 318, in configure
self._call_sub("configure")
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 330, in _call_sub
subfunc()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 375, in configure_download
self.base.conf.tsflags += ["test"]
TypeError: can only concatenate tuple (not "list") to tuple
The way that this is currently packaged in fedora, there are only man pages included in the package
$ rpm -ql dnf-plugins-extras
/usr/share/man/man8/dnf.plugin.debug.8.gz
/usr/share/man/man8/dnf.plugin.kickstart.8.gz
/usr/share/man/man8/dnf.plugin.leaves.8.gz
/usr/share/man/man8/dnf.plugin.local.8.gz
/usr/share/man/man8/dnf.plugin.migrate.8.gz
/usr/share/man/man8/dnf.plugin.repoclosure.8.gz
/usr/share/man/man8/dnf.plugin.repograph.8.gz
/usr/share/man/man8/dnf.plugin.repomanage.8.gz
/usr/share/man/man8/dnf.plugin.rpmconf.8.gz
/usr/share/man/man8/dnf.plugin.show-leaves.8.gz
/usr/share/man/man8/dnf.plugin.snapper.8.gz
/usr/share/man/man8/dnf.plugin.tracer.8.gz
/usr/share/man/man8/dnf.plugin.versionlock.8.gz
Nor does it have any dependencies on the actual packages....
I suspect that all of these have been broken into their own packages as that what seems to be revealed by my quick package search for dnf plugins
- but that can be quite confusing too because there are both python
and python3
versions for each. From a user perspective it's getting increasingly confusing...
Why not either remove the dnf-plugins-extras
package, or better yet, make it into a meta package that installs the valid set of plugins as dependencies? (the set that it currently has mans for)
This way a user could install dnf-plugins-extras
again and have all of them at once.
Otherwise, I fail to see why the package is even left behind to confuse people.
Edit: additionally, the package description in the spec is a "lie":
Available Packages
Name : dnf-plugins-extras
Arch : noarch
Epoch : 0
Version : 0.0.12
Release : 4.fc25
Size : 29 k
Repo : fedora
Summary : Extras Plugins for DNF
URL : https://github.com/rpm-software-management/dnf-plugins-extras
License : GPLv2+
Description : Extras Plugins for DNF.
So... went to do an upgrade to Fedora 35 and found that I was lacking room for the downloads. I have /home set up on a separate drive, so I did the following:
dnf system-upgrade download --downloaddir=/home --releasever=35
The upgrade went well, except when I rebooted into F35 I couldn't log into my home directory. So I rebooted and logged into a console session. When I did, I got an error message stating that /home/ was missing. ls /home showed me that all my home directories are missing.
I'm guessing that dnf downloaded all the packages for the upgrade to /home and then did a rm -rf * on them, taking out my home directories in the process.
Just confirmed the dnf system-upgrade probably does a rm-rf on the "download" dir.
From dnf-plugins-extras/plugins/system_upgrade.py:
=======================================================================
def clear_dir(path):
if not os.path.isdir(path):
return
for entry in os.listdir(path):
fullpath = os.path.join(path, entry)
try:
if os.path.isdir(fullpath):
dnf.util.rm_rf(fullpath)
else:
os.unlink(fullpath)
except OSError:
pass
========================================================================
I'm guessing that dnf.util.rm_rf does a #rm -rf ! Which explains where my home directories went !
I am beyond angry that this happened.
This is crazy coding ? If the developer wanted to delete only dnf created files, s/he could have easily grouped them by creating a sub directory within the --downloaddir, downloaded the files there and then did an rm -rf from within that directory.
I just lost a couple months worth of work.
PR here https://src.fedoraproject.org/fork/mattdm/rpms/dnf-plugins-extras/c/d24b2e09de9afd1021a4e31f9e777d7de936caa5 already applied in Fedora dist-git but mentioning it here so it doesn't get lost. Simply needs
Provides: dnf-command(offline-upgrade)
Provides: dnf-command(offline-distrosync)
added to the python3-dnf-plugin-system-upgrade
subpackage.
In rpmconf plugin documentation IMO should be better described things as .rpmnew/.rpmsave or original config file deletion and how merge function works.
Also, doc says: "For list of valid frontends see rpmconf(8)." - but on rpmconf man page is no list of them.
The tracer plugin can take a very long time to perform its scans, especially when a large update transaction has just completed. Today I upgraded some 400+ packages in the first dnf
run on that system in nearly a month, and dnf
took more than ten minutes to complete its post-transaction housekeeping. The majority of that time, as always after big jobs, was the tracker scan.
During that entire time, absolutely nothing is output on the terminal by dnf
. A user could be forgiven if they assumed the process was hung or stuck in a busy loop.
Two things would be great to have:
At least a "Starting tracker scans (this may take a while)..."-style message displayed when the plugin begins executing. Perhaps even a line of output when each plugin starts executing.1
To whatever extent is reasonably possible, some sort of visibility into the scan progress for the tracker plugin, specifically. (As it's by far the biggest contributor to post-transaction delays, especially for larger transactions.)
Whether that means a simple horizontal progress bar, a scrolling list of items being scanned as it works through them2, or some other display... heck, even just an ASCII spinner would be something, and it would at least provide reassurance that the dnf
process is still working and not completely hung.
If they're run serially, then absolutely: every plugin, even if most finish in mere milliseconds. If the plugins run in parallel, then maybe it's better if only the slower plugins output a message. That way they don't all talk over each other.
Displaying progress as a transaction list, in the manner of the package actions themselves, could work nicely if tracker's scans are done on a package-by-package basis.
OTOH, if its scans were done, say, by walking the system's process table, then reporting progress in list form probably won't fly. I imagine there are plenty of users who would consider it imprudent of dnf
to suddenly start listing out of the entire process table. To say that's not an expected consequence of updating software would be an understatement.
Each run of the test suite, for example as part of fedpkg local
, leaves around two dozen mostly empty /tmp/system_upgrade_test_installroot-*
directories behind.
This should probably be fixed by amending /tmp/system_upgrade_test_installroot-*
's CommandTestCaseBase.tearDown()
to do shutil.rmtree(self.installroot)
as well, but in earlier versions self.cli.base.conf.installroot
was set to /
, so an appropriate amount of caution should be applied. (Maybe set self.installroot
to the result of a tempfile.TemporaryDirectory()
call, self.cli.base.conf.installroot
to self.installroot.name
, and call self.installroot.cleanup()
in CommandTestCaseBase.tearDown()
.)
Maybe it would be an idea to make a main dnf-plugins-extras an then put each plugin in a sub packages, to reduse the number of dependecies dragged in if I only what to install a single plugin and dont care about the rest.
Not a problem now when there is only one plugins, but in the future the where can be very specialized plugins with more complex dependecies.
there is no way to diasable a plugin permernant like there is with yum plugins, so it is not a good idea to install a big blob of comunity plugins, if you only uses one
https://bugzilla.redhat.com/show_bug.cgi?id=1220182
We're just looking for the ability to configure arbitrary commands to run after certain packages are acted on.
For yum this was implemented in yum-plugin-post-transaction-actions ... if this were re-implemented for dnf, I think everyone would be happy, but I doubt anyone needs it to be implemented in exactly the same way (particularly because it doesn't seem to be very well documented), so long as it can accomplish the same thing.
Here's the description of yum-plugin-post-transaction-actions:
Yum plugin to run arbitrary commands when certain pkgs are acted on
This plugin allows the user to run arbitrary actions immediately following a transaction when specified packages are changed.
My understanding is that it creates a directory at /etc/yum/post-actions ... in that directory, a user could place "action" files for each package the user wishes to have post transaction actions apply to (e.g., the user could create a file named kernel.action if they want to run a command after the kernel is updated (actually, I don't think it matters what the file name is, as long as it ends in ".action", since the package name must be specified inside the file)) ... inside the file the user would enter the package name, an action (e.g. install or update), and the path to a script to run, like follows ...
kernel:update:/path-to/script-to-run.sh
In this case, the script will run any time the kernel package is updated.
You can also pass variables such as the package version to the script, like follows ...
kernel:update:/path-to/script-to-run.sh $ver $rel $arch
As I understand, this plugin has replaced fedup
, but there's an important functional still missing: fedup could upgrade from an ISO (both mounted and raw), whereas this plugin can't.
This functional allows one to upgrade the system when there's a scarce of free disk space. Currently such systems can not be upgraded, because the only way one could try it is by setting up a local repository, and then following this instruction. But then there's a hitch: this still requires one to download all packages to be locally (which would mean trying to copy packages from an ISO to the system partition), which one can't do (low disk space).
Currently the system-upgrade plugin downloads all packages and the waits for a reboot to install them.
With thousands of packages and each needing the install, verify and clean cycles, this can take a while, making the machine unavailable while it's doing that.
While I have done "in place" (i.e. {urpmi
|apt-get
|yum
|dnf
|etc.} upgrade while the system runs) for decades, I won't debate the reasoning for wanting to do the upgrades in a minimal, quiescent system, achieved through a reboot the way the system-upgrade plugin does.
I want to suggest an alternative to attaining that quiescent state however. On systems where the filesystem(s) are build on LVM, or where filesystems supporting bootable, writable snapshots (forking), the upgrade could be done in a snapshot, which is then configured to boot when done and a system reboot is done then. Since the full upgrade was done in the snapshot, the reboot is only as long as it takes to reboot the system.
Once rebooted on the snapshot, the user can decide to archive the origin, delete it, etc.
This would not be unlike what I actually currently do before I do an upgrade which is to take an LVM snapshot of my /
, /usr
, /var
, and /opt
filesystems. In such a case where I am unhappy with the upgraded system, I can easily fall back to my pre-upgrade state by reconfiguring my system to boot from the snapshots (i.e. point grub at the /
snapshot and edit the /etc/fstab
in the /
snapshot to mount the /usr
, /var
, and /opt
snapshots) and rebooting again.
The system-upgrade
plugin could actually formalize this being able to fall-back to the previous system by doing all of the above, and adding an entry to the grub menu for the pre-upgraded system.
python3-dnf-plugin-torproxy
But how to use this plugin correctly, because you don't have to specify much about its use!!!
The following alert is currently shown in Fedora Weblate:
Repository outdated.
The VCS repository is not up to date with the upstream one. Please merge changes manually or set up hooks to automate this.
[Documentation]
Can you please set up a webhook, so the translation strings are continuously updated?
Traceback (most recent call last):
File "/usr/bin/dnf", line 58, in
main.user_main(sys.argv[1:], exit_code=True)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main
errcode = main(args)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run
cli.run()
File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1055, in run
return self.command.run()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 322, in run
self._call_sub("run")
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 330, in _call_sub
subfunc()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 465, in run_download
state.destdir = self.base.conf.destdir
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 135, in exit
self.write()
File "/usr/lib/python3.7/site-packages/dnf-plugins/system_upgrade.py", line 123, in write
json.dump(self._data, outf)
File "/usr/lib64/python3.7/json/init.py", line 179, in dump
for chunk in iterable:
File "/usr/lib64/python3.7/json/encoder.py", line 431, in _iterencode
yield from _iterencode_dict(o, _current_indent_level)
File "/usr/lib64/python3.7/json/encoder.py", line 405, in _iterencode_dict
yield from chunks
File "/usr/lib64/python3.7/json/encoder.py", line 438, in _iterencode
o = _default(o)
File "/usr/lib64/python3.7/json/encoder.py", line 179, in default
raise TypeError(f'Object of type {o.class.name} '
TypeError: Object of type VectorString is not JSON serializable
On a non btrfs/ext4/LVM system, where snapshots aren't required during yum/dnf install, the snapper plugin is still being called to snapshot and it errors out as below..
Reproducer:
After installing the dnf snapper plugin
Run
dnf install
::
snapper: creating pre_snapshot failed: error.unknown_config: org.freedesktop.DBus.Error.Failed
::
dbus[23850]: arguments to dbus_connection_close() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2936.
This is normally a bug in some application using the D-Bus library.
When dnf system-upgrade download runs into conflicts, adding --debug-solver products an empty debugdata directory, so it's much harder to troubleshoot what the source of the problem is in the conflicting packages.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.