|
| 1 | +2020-04-04 Neal Gompa <ngompa13@gmail.com> |
| 2 | + |
| 3 | +* dnfdaemon.spec: Bump spec for 0.3.20 release |
| 4 | + |
| 5 | +2020-04-04 Neal Gompa <ngompa13@gmail.com> |
| 6 | + |
| 7 | +* dnfdaemon.spec: Raise minimum version of DNF to 4.2.6 and drop |
| 8 | +conflicts The minimum verified version this worked with was DNF |
| 9 | +4.2.6 but there is no longer an expectation that the Python API |
| 10 | +should significantly break with new major versions. Also, we're |
| 11 | +removing conflicts to upcoming major versions. If it becomes a |
| 12 | +problem, we can re-add them... |
| 13 | + |
| 14 | +2020-04-04 Neal Gompa <ngompa13@gmail.com> |
| 15 | + |
| 16 | +* Makefile, dnfdaemon.spec, python/dnfdaemon/Makefile, |
| 17 | +python/dnfdaemon/client/Makefile: Remove Python 2 support from |
| 18 | +dnfdaemon Python 2 is dead in Fedora and other Linux distributions |
| 19 | +as Python 2 is now EOL per the CPython developers. Thus, we no |
| 20 | +longer will support Python 2 dnfdaemon clients. Reference: |
| 21 | +https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal |
| 22 | + |
| 23 | + |
| 24 | +2020-03-01 Angelo Naselli <anaselli@linux.it> |
| 25 | + |
| 26 | +* daemon/dnfdaemon-system.py: With a hugh transaction, number of |
| 27 | +bytes to dowload could be greater than Int32, moreover byte number |
| 28 | +should be more than 0 so let's use Unsigend to avoid crashes |
| 29 | + |
| 30 | +2020-01-06 Angelo Naselli <anaselli@linux.it> |
| 31 | + |
| 32 | +* python/dnfdaemon/server/__init__.py: Fix GetRepo crash for |
| 33 | +Atrribute error |
| 34 | + |
| 35 | +2019-12-28 Angelo Naselli <anaselli@linux.it> |
| 36 | + |
| 37 | +* python/dnfdaemon/server/backend.py: imported code from "dnf clean |
| 38 | +metadata" command |
| 39 | + |
| 40 | +2019-10-15 Adam Williamson <awilliam@redhat.com> |
| 41 | + |
| 42 | +* daemon/dnfdaemon-session.py, daemon/dnfdaemon-system.py: |
| 43 | +check_lock: treat 'locked by other' differently to 'not locked' |
| 44 | +check_lock currently claims the daemon is locked by another app even |
| 45 | +if the problem is actually that it *isn't locked at all*. We should |
| 46 | +distinguish these two cases. Also, here and in a few other places |
| 47 | +we refer to this as either a 'dnf lock' or a 'yum lock'. AFAICT it |
| 48 | +is not either of those things, it is a lock that is internal to the |
| 49 | +daemon. You can happily perform operations with dnf *directly* while |
| 50 | +this lock is held. It's confusing to describe this as a 'dnf lock' |
| 51 | +when that isn't what it is, so this changes the description to |
| 52 | +'dnfdaemon lock' in a few places. Signed-off-by: Adam Williamson |
| 53 | +<awilliam@redhat.com> |
| 54 | + |
| 55 | +2018-09-17 Adam Williamson <awilliam@redhat.com> |
| 56 | + |
| 57 | +* python/dnfdaemon/server/__init__.py: Handle additional DNF |
| 58 | +transaction callback actions in DNF 3 See |
| 59 | +https://bugzilla.redhat.com/show_bug.cgi?id=1624652 and |
| 60 | +https://bugzilla.redhat.com/show_bug.cgi?id=1630113 . It seems that |
| 61 | +a change in DNF 3 causes transaction callbacks to use actions that |
| 62 | +aren't included in the callback API definition or docs. Because |
| 63 | +dnfdaemon/dnfdragora currently kinda assume they know all *possible* |
| 64 | +callback actions, this winds up causing dnfdragora to crash if it |
| 65 | +tries to handle a callback with one of these unknown actions. This |
| 66 | +commit adds the extra actions to the const <-> string dict in |
| 67 | +dnfdaemon's TransactionProgress callback, so that in the dbus |
| 68 | +RPMProgress message it sends out, the action will be a string, as |
| 69 | +dnfdragora's handler for the message expects. A companion commit for |
| 70 | +dnfdragora will add handling for the new string values, and also |
| 71 | +make it not crash if an unexpected action shows up. Signed-off-by: |
| 72 | +Adam Williamson <awilliam@redhat.com> |
| 73 | + |
| 74 | +2018-09-17 Adam Williamson <awilliam@redhat.com> |
| 75 | + |
| 76 | +* python/dnfdaemon/server/backend.py: Handle removal of |
| 77 | +dnf.repo._md_expire_cache() in DNF 3.4 DNF 3.4 removed |
| 78 | +_md_expire_cache(), which we were still using. Let's follow how |
| 79 | +upstream replaced it, by using the expire() method of the underlying |
| 80 | +librepo repo object...unfortunately this is still using private |
| 81 | +interfaces, but I don't see a way to do it using public ones. |
| 82 | +Signed-off-by: Adam Williamson <awilliam@redhat.com> |
| 83 | + |
| 84 | +2018-07-22 Neal Gompa <ngompa13@gmail.com> |
| 85 | + |
| 86 | +* Makefile, python/dnfdaemon/Makefile, |
| 87 | +python/dnfdaemon/client/Makefile: Enforce usage of versioned Python |
| 88 | +interpreter in Makefiles The Makefiles for dnfdaemon previously |
| 89 | +assumed that '/usr/bin/python' pointed to Python 2. However, as |
| 90 | +support for Python 2 winds down over the next two years, this is not |
| 91 | +guaranteed to remain true. Consequently, Fedora has split out |
| 92 | +'/usr/bin/python' from the 'python2' package in order to enforce |
| 93 | +that packages do not use '/usr/bin/python' by default. Since the |
| 94 | +assumption was wrong in the Makefiles to begin with, it is better to |
| 95 | +go ahead and fix it in the Makefiles. Reference: |
| 96 | + |
| 97 | +https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package |
| 98 | + |
| 99 | +2018-06-27 Neal Gompa <ngompa13@gmail.com> |
| 100 | + |
| 101 | +* ChangeLog: Finalize 0.3.19 release |
| 102 | + |
1 | 103 | 2018-06-27 Neal Gompa <ngompa13@gmail.com> |
2 | 104 |
|
3 | 105 | * dnfdaemon.spec: Add missing %files section for selinux subpackage |
4 | 106 |
|
| 107 | + |
5 | 108 | 2018-06-23 Daniel Mach <dmach@redhat.com> |
6 | 109 |
|
7 | 110 | * dnfdaemon.spec: Spec change for 0.3.19 release. |
|