It's been six months, and like clockwork, we release Fedora 30 today!
Thank you to the thousands of people who worked to bring this release together. Fedora doesn't happen by magic: it happens because of you!
Read the official announcement at:
* https://fedoramagazine.org/announcing-fedora-30/
or just go ahead and grab it from:
Hi,
On Tue, Apr 30, 2019 at 4:01 PM Matthew Miller mattdm@fedoraproject.org wrote:
It's been six months, and like clockwork, we release Fedora 30 today!
Congratulations! I have done in-place upgrades since Fedora 15 and I was never let down. This time I even had scheduled a set of offline tasks to do while my laptop would be unavailable but couldn't complete half of them before noticing the system upgrade had completed. No hard numbers but I'm pretty sure it went much faster than my upgrade to f29.
That is a bit irrelevant but I disabled the modular repository after upgrading to f29, so I can't comment on my upgrade experience in this regard.
Thank you to the thousands of people who worked to bring this release together. Fedora doesn't happen by magic: it happens because of you!
I'd like to break the spell a bit. Although the system upgrade always goes smoothly (and yet I'm always worried) the download and verification part rarely does on the first try.
Here I had to remove the following packages (and they took some of their dependencies away with them) beforehand:
- python2-hawkey-0.31.0-2.fc29.x86_64 - python2-libdnf-0.31.0-2.fc29.x86_64 - python2-migrate-0.11.0-9.fc29.noarch
Looking at my f30 setup I find this:
$ rpm -q --obsoletes fedora-obsolete-packages |
grep -E 'python2-(hawkey|libdnf|migrate)'
python2-hawkey < 0.30-1 python2-libdnf < 0.30-1
So apparently python2-hawkey and python2-libdnf were updated on f29 after being obsoleted on f30 with no further coordination on the fedora-obsolete-packages side. I'm not trying to blame anyone, it is easy to forget about something that was supposed to be done.
Maybe we should change the %{release} tag to look like %{?dist}X instead of X%{?dist}. That would allow something like:
Obsoletes: $PKG < $VERSION-f30
Since the %{release} comes after the %{version} that would still not prevent the accident I ran into with python2-{hawkey,libdnf} and there has already been solid cases against Epoch for this use case.
In hindsight, it's possibly the mast removal of python2 packages that sped up the upgrade.
I have no idea why or how python2-migrate landed on my system, and didn't actively need that one. According to DNF nothing obsoletes this package today.
Then I had to remove libxslt-devel.i686 because the upgrade selected both i686 and x86_64 packages and they conflict. No idea why. Trying to reinstall libxslt-devel.i686 afterwards worked fine.
Then I realized that getdns-stubby was gone after the upgrade. I suspect this happened because there was previously no such sub-package. I have no idea how to deal with that kind of split.
Finally, on the first f30 right after the system upgrade I tried a DNF upgrade and fedora-obsolete-packages was available. It was _after_ that last upgrade that I inspected its obsoleted packages with the grep command above.
So besides those unfortunate hiccups I'm now writing the devel list on a Fedora 30 system, happy that you chose to release it right before a bank holiday where I live, giving me the luxury to say goodbye to Fedora N-1 faster than usual.
Cheers, Dridi
PS. does the wallpaper have some sort of easter egg?
On 5/1/19 8:16 AM, Dridi Boukelmoune wrote:
Here I had to remove the following packages (and they took some of their dependencies away with them) beforehand:
- python2-hawkey-0.31.0-2.fc29.x86_64
- python2-libdnf-0.31.0-2.fc29.x86_64
- python2-migrate-0.11.0-9.fc29.noarch
Didn't the upgrade process suggest that you use --allowerasing? That would most likely have solved the problem for you. No need to manually remove them before the upgrade.
On Thu, May 2, 2019 at 8:30 AM Samuel Sieb samuel@sieb.net wrote:
On 5/1/19 8:16 AM, Dridi Boukelmoune wrote:
Here I had to remove the following packages (and they took some of their dependencies away with them) beforehand:
- python2-hawkey-0.31.0-2.fc29.x86_64
- python2-libdnf-0.31.0-2.fc29.x86_64
- python2-migrate-0.11.0-9.fc29.noarch
Didn't the upgrade process suggest that you use --allowerasing? That would most likely have solved the problem for you. No need to manually remove them before the upgrade.
It did but the transaction summary is so long that figuring out the consequences of removing packages automatically is not an easy task. I can usually follow --allowerasing on a simple dnf upgrade, but that rarely happens on a stable release.
So I preferred to remove them one by one manually just to see what they would take with them. I know we still have packages that couldn't move away from Python 2 entirely but I don't know the specifics.
No in-place upgrade problem since f15 doesn't mean I engage system upgrades without fearing of blowing up my setup :)
Dridi
On 5/1/19 11:46 PM, Dridi Boukelmoune wrote:
On Thu, May 2, 2019 at 8:30 AM Samuel Sieb samuel@sieb.net wrote:
On 5/1/19 8:16 AM, Dridi Boukelmoune wrote:
Here I had to remove the following packages (and they took some of their dependencies away with them) beforehand:
- python2-hawkey-0.31.0-2.fc29.x86_64
- python2-libdnf-0.31.0-2.fc29.x86_64
- python2-migrate-0.11.0-9.fc29.noarch
Didn't the upgrade process suggest that you use --allowerasing? That would most likely have solved the problem for you. No need to manually remove them before the upgrade.
It did but the transaction summary is so long that figuring out the consequences of removing packages automatically is not an easy task. I can usually follow --allowerasing on a simple dnf upgrade, but that rarely happens on a stable release.
dnf is really good about it. Removes are at the end, right before the downgrades list. That's all you need to look at to find out what will happen.
Dne 02. 05. 19 v 8:29 Samuel Sieb napsal(a):
Didn't the upgrade process suggest that you use --allowerasing?
Yes, it does. I tried to use it for few past realeases and ... I cannot personally recommend it. Sometimes it works, sometimes it is trying to remove crucial packages like rpm or dnf. It really depend your local set of packages.
It is really better to *not* use --allowerasing and manually remove the packages which cause problems and then try again.
#mytwocents
Miroslav
On 5/1/19 11:50 PM, Miroslav Suchý wrote:
Dne 02. 05. 19 v 8:29 Samuel Sieb napsal(a):
Didn't the upgrade process suggest that you use --allowerasing?
Yes, it does. I tried to use it for few past realeases and ... I cannot personally recommend it. Sometimes it works, sometimes it is trying to remove crucial packages like rpm or dnf. It really depend your local set of packages.
In that case, you already have a really messed up system.
It is really better to *not* use --allowerasing and manually remove the packages which cause problems and then try again.
I have never had a problem with using --allowerasing on the probably hundreds of system upgrades I've done. The only time that has been a problem is if I'm trying to recover from someone losing power during the upgrade.
On 01. 05. 19 17:16, Dridi Boukelmoune wrote:> Here I had to remove the following packages (and they took some of
their dependencies away with them) beforehand:
- python2-hawkey-0.31.0-2.fc29.x86_64
- python2-libdnf-0.31.0-2.fc29.x86_64
- python2-migrate-0.11.0-9.fc29.noarch
Looking at my f30 setup I find this:
$ rpm -q --obsoletes fedora-obsolete-packages |
grep -E 'python2-(hawkey|libdnf|migrate)'
python2-hawkey < 0.30-1 python2-libdnf < 0.30-1
So apparently python2-hawkey and python2-libdnf were updated on f29 after being obsoleted on f30 with no further coordination on the fedora-obsolete-packages side. I'm not trying to blame anyone, it is easy to forget about something that was supposed to be done.
Have you reported this to the dnf maintainers via bugzilla?
On 02. 05. 19 12:14, Dridi Boukelmoune wrote:
Have you reported this to the dnf maintainers via bugzilla?
Not yet, I dumped my upgrade notes here and then browsed bugzilla for error messages happening during my first f30 boot (turns out there's already a ticket for all of them) and then time ran out.
https://bugzilla.redhat.com/show_bug.cgi?id=1705493
-
Dridi Boukelmoune -
Matthew Miller -
Miro Hrončok -
Miroslav Suchý -
Samuel Sieb