This is weird. Software Updates on the Control Panel says that there are 39 updates available But when I run dnf update it says "Nothing to do". What gives?
JP
Ok, just did a dnf clean all , and the dnf update and the updates showed up
Weird.
JP
On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepebuho@gmail.com wrote:
This is weird. Software Updates on the Control Panel says that there are 39 updates available But when I run dnf update it says "Nothing to do". What gives?
JP
--
/_/\ |O O| pepebuho@gmail.com
~~~~ While the night runs ~~~~ toward the day... m m Pepebuho watches from his high perch.
On 19. 7. 2015 at 20:39:36, Javier Perez wrote:
Ok, just did a dnf clean all , and the dnf update and the updates showed up
Weird.
JP
On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepebuho@gmail.com wrote:
This is weird. Software Updates on the Control Panel says that there are 39 updates available But when I run dnf update it says "Nothing to do". What gives?
JP
IIRC the Software Updates widget does not use dnf to check for updates, therefore it's likely it has a different set of metadata at its disposal. As you figured out, cleaning the MD cache helps.
Thanks Jan
On Mon, Jul 20, 2015 at 09:00:16AM +0200, Jan Zelený wrote:
On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepebuho@gmail.com wrote:
This is weird. Software Updates on the Control Panel says that there are 39 updates available But when I run dnf update it says "Nothing to do". What gives?
IIRC the Software Updates widget does not use dnf to check for updates, therefore it's likely it has a different set of metadata at its disposal. As you figured out, cleaning the MD cache helps.
I'm getting a bit confused lately. How many package managers does Fedora have these days? IIRC, until a year or two back, it was the same backend (yum), but many front ends (yumex, all the packagekit based frontends for the different desktops). Did packagekit start doing the backend bits itself?
From your message I understand that there are at least two different
package managers, both are "Official" to some capacity. For cli users like myself, it's dnf, for gui users it's something packagekit based.
Am I mistaken?
On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
Ok, just did a dnf clean all , and the dnf update and the updates showed up
Weird.
Just some hours before your post I had sent this: https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
On Mon, 20 Jul 2015 10:01:37 +0200 Michael Schwendt mschwendt@gmail.com wrote:
On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
Ok, just did a dnf clean all , and the dnf update and the updates showed up
Weird.
Just some hours before your post I had sent this: https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
Michael is right: all we are a mass of lame I have shamed very much reading his answer to me; I have posted w/out RTFM and who do not RTFM should be banned like in old good irc times
-m
On 20. 7. 2015 at 09:43:45, Suvayu Ali wrote:
On Mon, Jul 20, 2015 at 09:00:16AM +0200, Jan Zelený wrote:
On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepebuho@gmail.com
wrote:
This is weird. Software Updates on the Control Panel says that there are 39 updates available But when I run dnf update it says "Nothing to do". What gives?
IIRC the Software Updates widget does not use dnf to check for updates, therefore it's likely it has a different set of metadata at its disposal. As you figured out, cleaning the MD cache helps.
I'm getting a bit confused lately. How many package managers does Fedora have these days? IIRC, until a year or two back, it was the same backend (yum), but many front ends (yumex, all the packagekit based frontends for the different desktops). Did packagekit start doing the backend bits itself?
From your message I understand that there are at least two different package managers, both are "Official" to some capacity. For cli users like myself, it's dnf, for gui users it's something packagekit based.
Am I mistaken?
You are not, that's pretty much it. We have had two independent software management stacks since F21 where PackageKit (PK) switched from yum backend to libhif.
At the moment PK and dnf share libraries for depsolving and downloading stuff but other than that the code is independent. IIRC the reason is that dnf is written in Python and that is not acceptable for PackageKit because of the new Gnome Software front end. It is likely that PK and dnf will share more code in the future but that's more of a very long term plan.
Thanks Jan
On Mon, Jul 20, 2015 at 10:36:01AM +0200, Maurizio Marini wrote:
On Mon, 20 Jul 2015 10:01:37 +0200 Michael Schwendt mschwendt@gmail.com wrote:
On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
Ok, just did a dnf clean all , and the dnf update and the updates showed up
Weird.
Just some hours before your post I had sent this: https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
Michael is right: all we are a mass of lame I have shamed very much reading his answer to me; I have posted w/out RTFM and who do not RTFM should be banned like in old good irc times
Unfortunately Michael, this `yum/dnf clean all' business will never go away. I remember there was a time on this list, when everytime someone suggested that, they got corrected. But all the people who used to do the correction are tired of repeating themselves, myself included. It's a lost cause.
On Mon, Jul 20, 2015 at 10:44:52AM +0200, Jan Zelený wrote:
On 20. 7. 2015 at 09:43:45, Suvayu Ali wrote:
On Mon, Jul 20, 2015 at 09:00:16AM +0200, Jan Zelený wrote:
On Sun, Jul 19, 2015 at 8:32 PM, Javier Perez pepebuho@gmail.com
wrote:
This is weird. Software Updates on the Control Panel says that there are 39 updates available But when I run dnf update it says "Nothing to do". What gives?
IIRC the Software Updates widget does not use dnf to check for updates, therefore it's likely it has a different set of metadata at its disposal. As you figured out, cleaning the MD cache helps.
I'm getting a bit confused lately. How many package managers does Fedora have these days? IIRC, until a year or two back, it was the same backend (yum), but many front ends (yumex, all the packagekit based frontends for the different desktops). Did packagekit start doing the backend bits itself?
From your message I understand that there are at least two different package managers, both are "Official" to some capacity. For cli users like myself, it's dnf, for gui users it's something packagekit based.
Am I mistaken?
You are not, that's pretty much it. We have had two independent software management stacks since F21 where PackageKit (PK) switched from yum backend to libhif.
At the moment PK and dnf share libraries for depsolving and downloading stuff but other than that the code is independent. IIRC the reason is that dnf is written in Python and that is not acceptable for PackageKit because of the new Gnome Software front end. It is likely that PK and dnf will share more code in the future but that's more of a very long term plan.
It seems a bit strange when frontends can dictate backend requirements. Also seems like a lot of duplicated effort, increased chances of bugs, and what not.
Anyway, thanks for your confirmation.
Cheers,
----- Original Message -----
From: "Suvayu Ali" fatkasuvayu+linux@gmail.com To: users@lists.fedoraproject.org Sent: Monday, July 20, 2015 10:58:05 AM Subject: Re: dnf update vs Software Udpates
On Mon, Jul 20, 2015 at 10:36:01AM +0200, Maurizio Marini wrote:
On Mon, 20 Jul 2015 10:01:37 +0200 Michael Schwendt mschwendt@gmail.com wrote:
On Sun, 19 Jul 2015 20:39:36 -0500, Javier Perez wrote:
Ok, just did a dnf clean all , and the dnf update and the updates showed up
Weird.
Just some hours before your post I had sent this: https://lists.fedoraproject.org/pipermail/users/2015-July/463183.html
Michael is right: all we are a mass of lame I have shamed very much reading his answer to me; I have posted w/out RTFM and who do not RTFM should be banned like in old good irc times
Unfortunately Michael, this `yum/dnf clean all' business will never go away. I remember there was a time on this list, when everytime someone suggested that, they got corrected. But all the people who used to do the correction are tired of repeating themselves, myself included. It's a lost cause. -- Suvayu
Open source is the future. It sets us free.
IIUUC, this is not completely true. I believe that once both PackageKit and DNF are integrated with the new CAShe [1], we will *be able* to improve this situation [2].
[1] https://github.com/james-antill/CAShe [2] If users/Fedora will be OK with downloading repomd.xml more often.
On 21.07.2015, Radek Holy wrote:
IIUUC, this is not completely true. I believe that once both PackageKit and DNF are integrated with the new CAShe [1], we will *be able* to improve this situation [2].
I hope this will be done *fast*, because I have to "clean all" *everytime* checking for updates. Otherwise, no updates are shown, even though they exist. This is a major bug.
On Tue, Jul 21, 2015 at 09:36:26PM +0200, Heinz Diehl wrote:
On 21.07.2015, Radek Holy wrote:
IIUUC, this is not completely true. I believe that once both PackageKit and DNF are integrated with the new CAShe [1], we will *be able* to improve this situation [2].
I hope this will be done *fast*, because I have to "clean all" *everytime* checking for updates. Otherwise, no updates are shown, even though they exist. This is a major bug.
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
Suvayu, Matthew, you rock guys, thanks!
On Tue, Jul 21, 2015, 21:33 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 21. 7. 2015 at 20:33:27, Matthew Miller wrote:
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
... and I believe setting metadata_expire = 0 in dnf.conf will do the same thing permanently.
Jan
On 22.07.2015, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
Ok.
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I usually update weekly (or at least once within two weeks). And since F22, I get "nothing to do" every time I do this - although there are updates waiting. Which is.. annoying. So every time I have to clean the cache to be able to update.
This was at least not how yum behaved. But if it's intended behaviour now, well...
On Wed, 2015-07-22 at 17:41 +0200, Heinz Diehl wrote:
On 22.07.2015, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
Ok.
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I usually update weekly (or at least once within two weeks). And since F22, I get "nothing to do" every time I do this - although there are updates waiting. Which is.. annoying. So every time I have to clean the cache to be able to update.
This was at least not how yum behaved. But if it's intended behaviour now, well...
I update every day, and most days there are some changes. I never clean the cache. I also never use anything except dnf.
poc
On Wed, Jul 22, 2015 at 05:41:48PM +0200, Heinz Diehl wrote:
On 22.07.2015, Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I usually update weekly (or at least once within two weeks). And since F22, I get "nothing to do" every time I do this - although there are updates waiting. Which is.. annoying. So every time I have to clean the cache to be able to update.
This is strange. I see very different behaviour. I update once every 2 days or so. Usually my metadata is a few hours old. Here are some examples:
On my laptop: # dnf check-update Last metadata expiration check performed 2:01:15 ago on Wed Jul 22 15:47:25 2015. and I have a bunch of updates waiting.
On my home server: # dnf check-update Last metadata expiration check performed 1:19:48 ago on Wed Jul 22 16:30:00 2015. with approximately similar set of updates waiting.
On an old laptop which I have not updated in some time. $ sudo dnf check-update [sudo] password for jallad: Last metadata expiration check performed 2:29:02 ago on Wed Jul 22 15:22:05 2015. a much larger set of updates awaiting.
My local time is, 2015-07-22 17:54:30. So they are all within 2-3 hours. That is why I find your case a bit puzzling. Maybe it is worthwhile to file a bugzilla. To be complete, I have no metadata related options set in dnf.conf or yum.conf. Maybe you have something like that set?
Hope this helps,
On 07/22/2015 05:41 PM, Heinz Diehl wrote:
On 22.07.2015, Suvayu Ali wrote:
I usually update weekly (or at least once within two weeks). And since F22, I get "nothing to do" every time I do this
What you describe indicates you could be victim of what I conside a massive design flaw in dnf, the dnf guys have been ignoring ever since, because they believe to know better: When dnf encounters a broken dependency, it doesn't tell you about it and ignores it.
Try "dnf --refresh --best update"
Ralf
On Tue, 21 Jul 2015 20:33:27 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
dnf --refresh upgrade does not work for me
dnf clean expire-cache does not work for me
dnf clean metadata does work instaed
-m
On 07/22/2015 09:58 AM, Ralf Corsepius wrote:
What you describe indicates you could be victim of what I conside a massive design flaw in dnf, the dnf guys have been ignoring ever since, because they believe to know better: When dnf encounters a broken dependency, it doesn't tell you about it and ignores it.
...and this is supposed to be better than yum. Why?
On 07/22/2015 10:38 AM, Maurizio Marini wrote:
On Tue, 21 Jul 2015 20:33:27 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
dnf --refresh upgrade does not work for me
dnf clean expire-cache does not work for me
dnf clean metadata does work instaed
I think that was a typo. You need:
dnf --refresh update
Running it on my machine:
[root@prophead conf]# dnf --refresh update RPM Fusion for Fedora 21 - Free - Updates 44 kB/s | 406 kB 00:09 Adobe Systems Incorporated 1.2 kB/s | 1.8 kB 00:01 RPM Fusion for Fedora 21 - Nonfree - Updates 543 kB/s | 152 kB 00:00 RPM Fusion for Fedora 21 - Free 17 kB/s | 508 kB 00:29 google-chrome 77 kB/s | 3.5 kB 00:00 RPM Fusion for Fedora 21 - Nonfree 527 kB/s | 179 kB 00:00 Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old) Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Upgrading: google-chrome-stable x86_64 44.0.2403.89-1 google-chrome 46 M
Transaction Summary ================================================================================ Upgrade 1 Package
Total download size: 46 M Is this ok [y/N]:
This was on a machine that had been fully updated yesterday. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - The problem with being poor is that it takes up all of your time - ----------------------------------------------------------------------
On 07/22/2015 10:52 AM, Rick Stevens wrote:
On 07/22/2015 10:38 AM, Maurizio Marini wrote:
On Tue, 21 Jul 2015 20:33:27 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
dnf --refresh upgrade does not work for me
dnf clean expire-cache does not work for me
dnf clean metadata does work instaed
I think that was a typo. You need:
dnf --refresh updateRunning it on my machine:
[root@prophead conf]# dnf --refresh update RPM Fusion for Fedora 21 - Free - Updates 44 kB/s | 406 kB 00:09 Adobe Systems Incorporated 1.2 kB/s | 1.8 kB 00:01 RPM Fusion for Fedora 21 - Nonfree - Updates 543 kB/s | 152 kB 00:00 RPM Fusion for Fedora 21 - Free 17 kB/s | 508 kB 00:29 google-chrome 77 kB/s | 3.5 kB 00:00 RPM Fusion for Fedora 21 - Nonfree 527 kB/s | 179 kB 00:00 Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old) Dependencies resolved. ================================================================================
Package Arch Version Repository Size ================================================================================
Upgrading: google-chrome-stable x86_64 44.0.2403.89-1 google-chrome 46 M
Transaction Summary
Upgrade 1 Package
Total download size: 46 M Is this ok [y/N]:
This was on a machine that had been fully updated yesterday.
Open mouth, insert foot. While what I did did result in the chrome update, a "dnf clean metadata;dnf update" did come up with 21 more items to update--even though it said the metadata was 45 seconds old.
dnf really needs some serious surgery. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Death is nature's way of dropping carrier - ----------------------------------------------------------------------
On Wed, Jul 22, 2015 at 10:57:39AM -0700, Rick Stevens wrote:
Open mouth, insert foot. While what I did did result in the chrome update, a "dnf clean metadata;dnf update" did come up with 21 more items to update--even though it said the metadata was 45 seconds old.
Are you sure you're not just hitting a different mirror?
Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
In fedora-updates.repo I have: metadata_expire=6h. I also have the dnf-makecache.timer 'masked'.
It's more than 6 hours since I last ran dnf but:
[root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32 2015. [root@vulcan rmyf22]#
No updates. It pulled in metadata for my private repo but not fedora-updates. So is it really telling me "how old the metadata is"? The message just refers to the last time an expiration check was performed. Does that mean the metadata was up to date as of 0:00:00 ago? Because, as we shall see, it clearly wasn't.
Let's try the --refresh option:
[root@vulcan rmyf22]# dnf --refresh check-update Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01 2015. [root@vulcan rmyf22]#
Still no updates. Time for a bigger hammer (don't try this at home or offer it as advice to newbies):
[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates* [root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - Updates 774 kB/s | 12 MB 00:16 Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02 2015.
environment-modules.x86_64 3.2.10-16.fc22 updates ...
Plus 55 other updates. What's going on?
Ron
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
Keep in mind that we only push updates once per day *anyway*.
Of course, if you're mixing in private repos or other rpm providers, there may be different policies.
Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
Keep in mind that we only push updates once per day *anyway*.
OK, but that's independent of the client being used. Both yum and dnf see the same updates, but dnf doesn't seem to be as quick to pass them on.
Of course, if you're mixing in private repos or other rpm providers, there may be different policies.
Sure, different repos have different policies but why would that affect Fedora updates? The commands I quoted clearly show that there was newer metadata that dnf ignored until I blew away the old cache.
Ron
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
Everyone seems to picked on this post for me, whereas missing on my follow-up, with actual numbers:
http://mid.gmane.org/20150722160112.GC1727@chitra.no-ip.org
In fedora-updates.repo I have: metadata_expire=6h. I also have the dnf-makecache.timer 'masked'.
In the above post, I say I do not change any of the defaults metadata related configs. From what people are posting, I have the feeling dnf relies a lot on _continuous_ network connectivity (which is true in my case). If that is true, if either the connection at the users end is intermittent, or the mirrors are unreliable, the cache probably ends up being stale more often.
Instead of bashing and complaining, I think trying to analyse why it works for me (and maybe a few others who are quiet), and not for the other participants in this thread, it would be a lot more helpful to the devs. I can't help here since it actually works for me beautifully. Users who see a problem are the ones in a position to contribute an effective bug report.
My 2¢, cheers,
On Wed, Jul 22, 2015 at 5:22 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
Everyone seems to picked on this post for me, whereas missing on my follow-up, with actual numbers:
http://mid.gmane.org/20150722160112.GC1727@chitra.no-ip.org
In fedora-updates.repo I have: metadata_expire=6h. I also have the dnf-makecache.timer 'masked'.
In the above post, I say I do not change any of the defaults metadata related configs. From what people are posting, I have the feeling dnf relies a lot on _continuous_ network connectivity (which is true in my case). If that is true, if either the connection at the users end is intermittent, or the mirrors are unreliable, the cache probably ends up being stale more often.
Instead of bashing and complaining, I think trying to analyse why it works for me (and maybe a few others who are quiet), and not for the other participants in this thread, it would be a lot more helpful to the devs. I can't help here since it actually works for me beautifully. Users who see a problem are the ones in a position to contribute an effective bug report.
My 2¢, cheers,
-- Suvayu
There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that fires ten minutes after each boot then one hour following the execution of each previous run. It triggers `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes `dnf -v makecache timer`. When that command runs, dnf will check the age of the current metadata cache and refresh it if it is older than the value of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.
So, an always-on computer should never have metadata older than 4 hours; in practical terms, I think values >2 hours are increasingly unlikely. A computer that's been off overnight and turned on in the morning should have a fresh cache within 15 minutes of boot. If you have, say, a laptop that you power down often and often install or update packages immediately after boot, you might adjust the OnBootSec value by copying dnf-makecache.timer to /etc/systemd/system/ and editing accordingly. Or, consider appending --refresh on an as-needed basis.
-- Pete
Hi Pete,
On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that fires ten minutes after each boot then one hour following the execution of each previous run. It triggers `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes `dnf -v makecache timer`. When that command runs, dnf will check the age of the current metadata cache and refresh it if it is older than the value of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.
Thank you for this clear and very nice explanation.
So, an always-on computer should never have metadata older than 4 hours; in practical terms, I think values >2 hours are increasingly unlikely. A computer that's been off overnight and turned on in the morning should have a fresh cache within 15 minutes of boot. If you have, say, a laptop that you power down often and often install or update packages immediately after boot, you might adjust the OnBootSec value by copying dnf-makecache.timer to /etc/systemd/system/ and editing accordingly. Or, consider appending --refresh on an as-needed basis.
I think this is where things go wrong. OnBootSec handles powerdowns, what about intermittent connections? In principle, it is quite possible everytime the timer triggers the makecache service, the connection is absent. In fact, the probability to hit the sweet spot is directly determined by the reliability of the connection. So a connection that is up 50% of the time, will miss 50% of the makecache jobs. Maybe the makecache jobs can reset the timer to try again in 10 mins in case of no network connectivity. I think that would make the odds more favourable.
Essentially I'm suggesting to treat no connectivity as a powercycle. Hopefully this gives the devs some ideas.
Cheers,
On 07/22/2015 04:07 PM, Suvayu Ali wrote:
I think this is where things go wrong. OnBootSec handles powerdowns, what about intermittent connections? In principle, it is quite possible everytime the timer triggers the makecache service, the connection is absent.
Which shouldn't matter. If no connection is available, metadata won't get updated until you run an interactive command that forces a refresh. Note that if you're on battery, makecache won't run, either. This is a convenience function to reduce the delay in running interactive commands, and nothing more.
On Jul 22, 2015 6:52 PM, "Gordon Messmer" gordon.messmer@gmail.com wrote:
On 07/22/2015 04:07 PM, Suvayu Ali wrote:
I think this is where things go wrong. OnBootSec handles powerdowns, what about intermittent connections? In principle, it is quite possible everytime the timer triggers the makecache service, the connection is absent.
Which shouldn't matter. If no connection is available, metadata won't
get updated until you run an interactive command that forces a refresh. Note that if you're on battery, makecache won't run, either. This is a convenience function to reduce the delay in running interactive commands, and nothing more.
--
Do you have references for the on-battery behavior? That's news to me.
--Pete
On 07/22/2015 04:57 PM, Pete Travis wrote:
Do you have references for the on-battery behavior? That's news to me.
/usr/lib/systemd/system/dnf-makecache.service: ExecStart=/usr/bin/dnf -v makecache timer
man dnf: dnf [options] makecache timer Like plain makecache but instructs DNF to be more resource-aware, meaning will not do anything if running on battery power ...
On 07/22/2015 07:39 PM, Joe Zeff wrote:
On 07/22/2015 09:58 AM, Ralf Corsepius wrote:
What you describe indicates you could be victim of what I conside a massive design flaw in dnf, the dnf guys have been ignoring ever since, because they believe to know better: When dnf encounters a broken dependency, it doesn't tell you about it and ignores it.
...and this is supposed to be better than yum. Why?
Don't ask me. I've complained about this behavior many times, but the dnf folks/RH prefer not to listen and to be non-cooperational.
Ralf
On 07/22/2015 09:58 AM, Ralf Corsepius wrote:
What you describe indicates you could be victim of what I conside a massive design flaw in dnf, the dnf guys have been ignoring ever since, because they believe to know better: When dnf encounters a broken dependency, it doesn't tell you about it and ignores it.
...and this is supposed to be better than yum. Why?
Well.... improving what is not broken :)
On 07/22/2015 09:32 PM, Ron Yorston wrote:
Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
Keep in mind that we only push updates once per day *anyway*.
OK, but that's independent of the client being used. Both yum and dnf see the same updates, but dnf doesn't seem to be as quick to pass them on.
IIRC, dnf and yum use different default intervals/timeouts.
dnf by default uses 2 days (search for "metadata_expire" in "man dnf.conf", while yum used 6 hours (search for "metadata_expire" in "man yum.conf").
Of course, if you're mixing in private repos or other rpm providers, there may be different policies.
Sure, different repos have different policies but why would that affect Fedora updates?
They affect updates when package conflicts occur. The probability to encounter them when "mixing repos" is much higher.
yum complained about them and forced users to intervene manually.
dnf by default remains silent about such conflicts and doesn't update. This lets users believe everything was "OK", while their system actually is partially outdated.
Ralf
On 07/22/2015 09:41 PM, Ralf Corsepius wrote:
On 07/22/2015 09:32 PM, Ron Yorston wrote:
Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 07:20:11PM +0100, Ron Yorston wrote:
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
Keep in mind that we only push updates once per day *anyway*.
OK, but that's independent of the client being used. Both yum and dnf see the same updates, but dnf doesn't seem to be as quick to pass them on.
IIRC, dnf and yum use different default intervals/timeouts.
dnf by default uses 2 days (search for "metadata_expire" in "man dnf.conf", while yum used 6 hours (search for "metadata_expire" in "man yum.conf").
Of course, if you're mixing in private repos or other rpm providers, there may be different policies.
Sure, different repos have different policies but why would that affect Fedora updates?
They affect updates when package conflicts occur. The probability to encounter them when "mixing repos" is much higher.
yum complained about them and forced users to intervene manually.
dnf by default remains silent about such conflicts and doesn't update. This lets users believe everything was "OK", while their system actually is partially outdated.
Is there a way to make dnf provide info instead of being silent?
David
Ralf
Gordon Messmer wrote:
Use "dnf repolist -v" to find out, in the future. It will print the date from the metadata you have, and the URL of the mirror from which it was retrieved.
OK, today 'dnf repolist -v' tells me:
fedora: using metadata from Wed Jul 22 08:38:59 2015. rmy: using metadata from Wed Jul 22 08:38:59 2015. updates: using metadata from Wed Jul 22 08:54:38 2015. Last metadata expiration check performed 21:22:45 ago on Wed Jul 22 08:54:38 2015.
Repo-id : fedora Repo-updated : Sat May 23 11:23:20 2015 Repo-expire : 172,800 second(s) (last: Wed Jul 22 08:38:59 2015)
Repo-id : rmy Repo-updated : Sat Jun 20 19:40:40 2015 Repo-expire : 172,800 second(s) (last: Wed Jul 22 08:38:59 2015)
Repo-id : updates Repo-updated : Tue Jul 21 06:47:56 2015 Repo-expire : 21,600 second(s) (last: Wed Jul 22 08:54:38 2015)
The fedora and rmy repos both have the default metadata_expire of 48 hours; updates has 6 hours, as configured in fedora-updates.repo.
fedora and rmy are still within their metadata_expire timeout; updates has expired.
Running the same commands as yesterday:
[root@vulcan rmyf22]# dnf check-update Last metadata expiration check performed 0:00:00 ago on Thu Jul 23 06:19:10 2015. [root@vulcan rmyf22]# dnf --refresh check-update Fedora 22 - x86_64 - RMY repository 78 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Thu Jul 23 06:20:06 2015. [root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates* [root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - Updates 946 kB/s | 12 MB 00:13 Last metadata expiration check performed 0:00:11 ago on Thu Jul 23 06:23:32 2015. [root@vulcan rmyf22]#
What immediately seems odd is that 'dnf --refresh check-update' pulled in a new version of the rmy metadata (which hasn't expired) but not the updates metadata (which has).
Forcibly removing the updates metadata causes a download but I get the same version as yesterday (the one from Jul 21 06:47:56 2015) so there are no new updates.
Actually, every time I run 'dnf --refresh check-update' the metadata for the rmy repo is downloaded. Maybe that's because the rmy repo has an 'ftp://' URL so dnf can't use an 'if-modified-since' request to see if it's changed. I wonder if that's confusing 'dnf --refresh'?
Ron
----- Original Message -----
From: "Ralf Corsepius" rc040203@freenet.de To: users@lists.fedoraproject.org Sent: Wednesday, July 22, 2015 6:58:49 PM Subject: Re: dnf update vs Software Udpates
On 07/22/2015 05:41 PM, Heinz Diehl wrote:
On 22.07.2015, Suvayu Ali wrote:
I usually update weekly (or at least once within two weeks). And since F22, I get "nothing to do" every time I do this
What you describe indicates you could be victim of what I conside a massive design flaw in dnf, the dnf guys have been ignoring ever since, because they believe to know better: When dnf encounters a broken dependency, it doesn't tell you about it and ignores it.
Try "dnf --refresh --best update"
Ralf
Let's admit that you ignore us as well.
As said many times, we are working on it [1].
First step is dnf-1.0.2.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1210445
----- Original Message -----
From: "Rick Stevens" ricks@alldigital.com To: "Community support for Fedora users" users@lists.fedoraproject.org Sent: Wednesday, July 22, 2015 7:52:32 PM Subject: Re: dnf update vs Software Udpates
On 07/22/2015 10:38 AM, Maurizio Marini wrote:
On Tue, 21 Jul 2015 20:33:27 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jul 22, 2015 at 02:10:10AM +0200, Suvayu Ali wrote:
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
You don't even need to do that. Just use the --refresh flag -- `dnf --refresh upgrade`.
dnf --refresh upgrade does not work for me
dnf clean expire-cache does not work for me
dnf clean metadata does work instaed
I think that was a typo. You need:
dnf --refresh update
Well, "dnf update" is a deprecated alias for "dnf upgrade" (http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).
Running it on my machine:
[root@prophead conf]# dnf --refresh update RPM Fusion for Fedora 21 - Free - Updates 44 kB/s | 406 kB 00:09 Adobe Systems Incorporated 1.2 kB/s | 1.8 kB 00:01 RPM Fusion for Fedora 21 - Nonfree - Updates 543 kB/s | 152 kB 00:00 RPM Fusion for Fedora 21 - Free 17 kB/s | 508 kB 00:29 google-chrome 77 kB/s | 3.5 kB 00:00 RPM Fusion for Fedora 21 - Nonfree 527 kB/s | 179 kB 00:00 Using metadata from Wed Jul 22 10:49:27 2015 (0:00:52 hours old) Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Upgrading: google-chrome-stable x86_64 44.0.2403.89-1 google-chrome 46 M
Transaction Summary
Upgrade 1 Package
Total download size: 46 M Is this ok [y/N]:
This was on a machine that had been fully updated yesterday.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-- The problem with being poor is that it takes up all of your time -
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
----- Original Message -----
From: "Suvayu Ali" fatkasuvayu+linux@gmail.com To: users@lists.fedoraproject.org Sent: Thursday, July 23, 2015 1:07:13 AM Subject: Re: dnf update vs Software Udpates
Hi Pete,
On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that fires ten minutes after each boot then one hour following the execution of each previous run. It triggers `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes `dnf -v makecache timer`. When that command runs, dnf will check the age of the current metadata cache and refresh it if it is older than the value of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.
Thank you for this clear and very nice explanation.
So, an always-on computer should never have metadata older than 4 hours; in practical terms, I think values >2 hours are increasingly unlikely. A computer that's been off overnight and turned on in the morning should have a fresh cache within 15 minutes of boot. If you have, say, a laptop that you power down often and often install or update packages immediately after boot, you might adjust the OnBootSec value by copying dnf-makecache.timer to /etc/systemd/system/ and editing accordingly. Or, consider appending --refresh on an as-needed basis.
I think this is where things go wrong. OnBootSec handles powerdowns, what about intermittent connections? In principle, it is quite possible everytime the timer triggers the makecache service, the connection is absent. In fact, the probability to hit the sweet spot is directly determined by the reliability of the connection. So a connection that is up 50% of the time, will miss 50% of the makecache jobs. Maybe the makecache jobs can reset the timer to try again in 10 mins in case of no network connectivity. I think that would make the odds more favourable.
Essentially I'm suggesting to treat no connectivity as a powercycle. Hopefully this gives the devs some ideas.
Cheers,
-- Suvayu
Can you please file an RFE?
Thanks
----- Original Message -----
From: "Ron Yorston" rmy@frippery.org To: users@lists.fedoraproject.org Sent: Wednesday, July 22, 2015 8:20:11 PM Subject: Re: dnf update vs Software Udpates
Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
In fedora-updates.repo I have: metadata_expire=6h. I also have the dnf-makecache.timer 'masked'.
It's more than 6 hours since I last ran dnf but:
[root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32 2015. [root@vulcan rmyf22]#
No updates. It pulled in metadata for my private repo but not fedora-updates. So is it really telling me "how old the metadata is"? The message just refers to the last time an expiration check was performed. Does that mean the metadata was up to date as of 0:00:00 ago? Because, as we shall see, it clearly wasn't.
No, precisely, it tells you the maximum of all timestamps of caches of all repositories. I mean, if the cache of "fedora" is 3 hours old, the cache of "updates" is 2 hours old and the cache of "updates-testing" is 1 hour old, the output is 1 hour.
To see all the timestamps, you should use "--debug". Maybe you can help us by filling an RFE with a suggestion of a better message?
Let's try the --refresh option:
[root@vulcan rmyf22]# dnf --refresh check-update Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01 2015. [root@vulcan rmyf22]#
Still no updates. Time for a bigger hammer (don't try this at home or offer it as advice to newbies):
[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates* [root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - Updates 774 kB/s | 12 MB 00:16 Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02 2015.
environment-modules.x86_64 3.2.10-16.fc22 updates ...
Plus 55 other updates. What's going on?
Ron
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
----- Original Message -----
From: "Radek Holy" rholy@redhat.com To: "Community support for Fedora users" users@lists.fedoraproject.org Sent: Thursday, July 23, 2015 9:01:24 AM Subject: Re: dnf update vs Software Udpates
----- Original Message -----
From: "Ron Yorston" rmy@frippery.org To: users@lists.fedoraproject.org Sent: Wednesday, July 22, 2015 8:20:11 PM Subject: Re: dnf update vs Software Udpates
Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
In fedora-updates.repo I have: metadata_expire=6h. I also have the dnf-makecache.timer 'masked'.
It's more than 6 hours since I last ran dnf but:
[root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32 2015. [root@vulcan rmyf22]#
No updates. It pulled in metadata for my private repo but not fedora-updates. So is it really telling me "how old the metadata is"? The message just refers to the last time an expiration check was performed. Does that mean the metadata was up to date as of 0:00:00 ago? Because, as we shall see, it clearly wasn't.
No, precisely, it tells you the maximum of all timestamps of caches of all repositories. I mean, if the cache of "fedora" is 3 hours old, the cache of "updates" is 2 hours old and the cache of "updates-testing" is 1 hour old, the output is 1 hour.
To see all the timestamps, you should use "--debug". Maybe you can help us by filling an RFE with a suggestion of a better message?
I mean "--verbose", sorry.
Let's try the --refresh option:
[root@vulcan rmyf22]# dnf --refresh check-update Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01 2015. [root@vulcan rmyf22]#
Still no updates. Time for a bigger hammer (don't try this at home or offer it as advice to newbies):
[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates* [root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - Updates 774 kB/s | 12 MB 00:16 Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02 2015.
environment-modules.x86_64 3.2.10-16.fc22 updates ...
Plus 55 other updates. What's going on?
Ron
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech
----- Original Message -----
From: "Radek Holy" rholy@redhat.com To: "Community support for Fedora users" users@lists.fedoraproject.org Sent: Thursday, July 23, 2015 9:01:24 AM Subject: Re: dnf update vs Software Udpates
----- Original Message -----
From: "Ron Yorston" rmy@frippery.org To: users@lists.fedoraproject.org Sent: Wednesday, July 22, 2015 8:20:11 PM Subject: Re: dnf update vs Software Udpates
Suvayu Ali wrote:
That said, I sometimes do not understand what's the harm in getting updates few hours later. dnf already tells you how old the metadata is when it starts, you can choose to get the latest metadata if it is too old. So what's the big deal?
I certainly get the impression that dnf tells me about updates less frequently than yum did. It also seems to pull in metadata less frequently.
In fedora-updates.repo I have: metadata_expire=6h. I also have the dnf-makecache.timer 'masked'.
It's more than 6 hours since I last ran dnf but:
[root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - RMY repository 131 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:38:32 2015. [root@vulcan rmyf22]#
No updates. It pulled in metadata for my private repo but not fedora-updates. So is it really telling me "how old the metadata is"? The message just refers to the last time an expiration check was performed. Does that mean the metadata was up to date as of 0:00:00 ago? Because, as we shall see, it clearly wasn't.
No, precisely, it tells you the maximum of all timestamps of caches of all repositories. I mean, if the cache of "fedora" is 3 hours old, the cache of "updates" is 2 hours old and the cache of "updates-testing" is 1 hour old, the output is 1 hour.
...which means that 1 hour ago, DNF found out that only "updates-testing" is expired (according to "metadata_expire"). I mean, there might be updates in another repositories as well but DNF is allowed to check it only after the "metadata_expire" period.
To see all the timestamps, you should use "--debug". Maybe you can help us by filling an RFE with a suggestion of a better message?
Let's try the --refresh option:
[root@vulcan rmyf22]# dnf --refresh check-update Fedora 22 - x86_64 - RMY repository 113 kB/s | 6.0 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Wed Jul 22 08:39:01 2015. [root@vulcan rmyf22]#
Still no updates. Time for a bigger hammer (don't try this at home or offer it as advice to newbies):
[root@vulcan rmyf22]# rm -rf /var/cache/dnf/x86_64/22/updates* [root@vulcan rmyf22]# dnf check-update Fedora 22 - x86_64 - Updates 774 kB/s | 12 MB 00:16 Last metadata expiration check performed 0:00:16 ago on Wed Jul 22 08:40:02 2015.
environment-modules.x86_64 3.2.10-16.fc22 updates ...
Plus 55 other updates. What's going on?
Ron
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech
Ron Yorston wrote:
What immediately seems odd is that 'dnf --refresh check-update' pulled in a new version of the rmy metadata (which hasn't expired) but not the updates metadata (which has).
Of course, today it didn't need to download new updates metadata because it hadn't changed. That wasn't the case yesterday, though.
Ron
On 07/23/15 14:30, Radek Holy wrote:
Well, "dnf update" is a deprecated alias for "dnf upgrade" (http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).
At the risk of sounding pedantic, shouldn't there then be a change to "check-upgrade" and depreciate "check-update". :-)
FWIW, I'm not having any real issues with using dnf. One just has to commit to the learning curve. :-)
On 07/23/2015 06:05 AM, Rahul Sundaram wrote:
Hi
On Wed, Jul 22, 2015 at 10:55 PM, dwoody5654 wrote:
Is there a way to make dnf provide info instead of being silent?The answer was posted earlier in the thread.
Well, the real answer would be to change dnf's behaviour.
The current behaviour is just non-helpful design flaw.
----- Original Message -----
From: "Ed Greshko" ed.greshko@greshko.com To: "Community support for Fedora users" users@lists.fedoraproject.org Sent: Thursday, July 23, 2015 11:20:05 AM Subject: Re: dnf update vs Software Udpates
On 07/23/15 14:30, Radek Holy wrote:
Well, "dnf update" is a deprecated alias for "dnf upgrade" (http://dnf.readthedocs.org/en/latest/command_ref.html#update-command).
At the risk of sounding pedantic, shouldn't there then be a change to "check-upgrade" and depreciate "check-update". :-)
FWIW, I'm not having any real issues with using dnf. One just has to commit to the learning curve. :-)
-- If I wanted a blog or social media I'd go elsewhere
Yes, sounds reasonable :)
On Thu, Jul 23, 2015 at 02:32:19AM -0400, Radek Holy wrote:
Essentially I'm suggesting to treat no connectivity as a powercycle. Hopefully this gives the devs some ideas.
Can you please file an RFE?
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1246253
Cheers,
On 07/23/2015 08:28 AM, Radek Holy wrote:
----- Original Message -----
From: "Ralf Corsepius" rc040203@freenet.de To: users@lists.fedoraproject.org Sent: Wednesday, July 22, 2015 6:58:49 PM Subject: Re: dnf update vs Software Udpates
On 07/22/2015 05:41 PM, Heinz Diehl wrote:
On 22.07.2015, Suvayu Ali wrote:
I usually update weekly (or at least once within two weeks). And since F22, I get "nothing to do" every time I do this
What you describe indicates you could be victim of what I conside a massive design flaw in dnf, the dnf guys have been ignoring ever since, because they believe to know better: When dnf encounters a broken dependency, it doesn't tell you about it and ignores it.
Try "dnf --refresh --best update"
Ralf
Let's admit that you ignore us as well.
No, I do not ignore you. I am simply tired of being confronted with this immature and broken piece of banana software called "dnf" and am tired of permanently being confronted with what I perceive as "false promises".
Ralf
Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
I hope this will be done *fast*, because I have to "clean all" *everytime* checking for updates. Otherwise, no updates are shown, even though they exist. This is a major bug.
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
In practice, there's not much of a difference between "clean all" or just "clean metadata". Because both require the update/upgrade command to download all stuff from the network and build to whole meta database from scratch, even if that wouldn't be necessary.
For the typical desktop PC, "clean metadata" is not a time-saver compared to "clean all". Just more letters to type.
"clean metadata" may make sense if you add "--disablerepo=fedora", because this really saves bandwidth and CPU for the update/upgrade.
Btw, "clean expire-cache" (or --refresh) won't do the trick to get the latest updates available. (However, it's still better than just update/upgrade without anything else.)
The design of yum/dnf is somewhat flawed. I totally understand that some caching makes sense so that metadata isn't checked, downloaded or built for every single call to yum/dnf.
However, if somebody runs "dnf upgrade" on the command shell then he clearly wants the latest updates. Right now! No caching or other magic involved. That's the whole point of running "dnf upgrade" manually, otherwise the user would have left the whole updating business to some automated background task.
That said, I sometimes do not understand what's the harm in getting updates few hours later.
Caching might be cool for automated tasks (eg, cron jobs or background processes) and also for some actions that do not require up-to-date metadata.
But if the user wants to download an update he should get the update.
This issue comes up for years. And there's always this debate about "clean all" vs. "clean metadata" which in fact isn't a big difference in the real world, and - what is much more important - both won't solve the underlying problem, so the very same issue comes up again and again.
Greetings, Andreas
Hi
On Fri, Aug 7, 2015 at 10:23 PM, Andreas M. Kirchwitz
However, if somebody runs "dnf upgrade" on the command shell then he clearly wants the latest updates. Right now! No caching or other magic involved. That's the whole point of running "dnf upgrade" manually, otherwise the user would have left the whole updating business to some automated background task.
If this is what you want, use dnf update --refresh instead
Rahul
On Fri, 7 Aug 2015 22:38:22 -0400 Rahul Sundaram metherid@gmail.com wrote:
Hi
On Fri, Aug 7, 2015 at 10:23 PM, Andreas M. Kirchwitz
However, if somebody runs "dnf upgrade" on the command shell then he clearly wants the latest updates. Right now! No caching or other magic involved. That's the whole point of running "dnf upgrade" manually, otherwise the user would have left the whole updating business to some automated background task.
If this is what you want, use dnf update --refresh instead
Rahul
Then please explain this.
[root@smicro bob]# dnf --refresh --best update RPM Fusion for Fedora 22 - Free - Updates 249 kB/s | 29 kB 00:00 ... RPM Fusion for Fedora 22 - Nonfree 876 kB/s | 170 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Sat Aug 8 09:32:41 2015. Dependencies resolved. Nothing to do. Complete!
[root@smicro bob]# dnf clean all Cleaning repos: google-earth fedora rpmfusion-free-updates fedora-HandBrake : rpmfusion-nonfree-updates local adobe-linux-x86_64 updates : rpmfusion-free rpmfusion-nonfree Cleaning up Everything
[root@smicro bob]# dnf --refresh --best update Fedora 22 - x86_64 6.9 MB/s | 41 MB 00:05 RPM Fusion for Fedora 22 - Free - Updates 253 kB/s | 29 kB 00:00 ... RPM Fusion for Fedora 22 - Nonfree 891 kB/s | 170 kB 00:00 Last metadata expiration check performed 0:00:05 ago on Sat Aug 8 09:43:16 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Upgrading: autocorr-en noarch 1:4.4.5.2-1.fc22 updates 176 k autocorr-sl noarch 1:4.4.5.2-1.fc22 updates 160 k ... zsh x86_64 5.0.8-5.fc22 updates 2.6 M
Transaction Summary ================================================================================ Upgrade 48 Packages
Total download size: 203 M Is this ok [y/N]:
BR, Bob
On Sat, Aug 08, 2015 at 02:23:34AM +0000, Andreas M. Kirchwitz wrote:
Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
I hope this will be done *fast*, because I have to "clean all" *everytime* checking for updates. Otherwise, no updates are shown, even though they exist. This is a major bug.
I'm sorry but "clean all" is not necessary at all! "clean metadata" or "clean expire-cache" should be sufficient.
In practice, there's not much of a difference between "clean all" or just "clean metadata". Because both require the update/upgrade command to download all stuff from the network and build to whole meta database from scratch, even if that wouldn't be necessary.
Sorry, that's not correct. Ever since the yum days, they have been different. The key differences are these two bits (from `man dnf'):
[...] dnf clean packages Removes any cached packages from the system.
dnf clean plugins Tells all enabled plugins to eliminate their cached data.
dnf clean all Does all of the above.
By removing packages, you are losing the ability to do offline transactions. Cleaning cached data from plugins, can do any number of things depending on the enabled plugins. So please stop repeating this obviously incorrect information.
That said, I sometimes do not understand what's the harm in getting updates few hours later.
Caching might be cool for automated tasks (eg, cron jobs or background processes) and also for some actions that do not require up-to-date metadata.
During the yum days, the most frequent complaint on this list were: why is yum so slow, I hate waiting for metadata updates, .... and so on. And now people complain, the cached metadata is out of date (please don't confuse this with actual bugs). There is no winning, you either wait for the metadata to download, or you get a responsive interface.
PS: I've no relation to the dnf team, just a user. I however think instead of complaining on the list, if any discussions here lead you to think there is a problem with dnf (as in a bug), you should file bug reports.
Rahul Sundaram metherid@gmail.com wrote:
However, if somebody runs "dnf upgrade" on the command shell then he clearly wants the latest updates. Right now! No caching or other magic involved. That's the whole point of running "dnf upgrade" manually, otherwise the user would have left the whole updating business to some automated background task.
If this is what you want, use dnf update --refresh instead
That does clearly *not* provide the latest updates. It's better than without "--refresh", but "dnf clean metadata" is required for full updates available.
Once you figured that out, you can write a script and then get what you want. All other users come here every couple of weeks and will ask the same question again: Why doesn't yum/dnf fetch all updates? And that's indeed a good question, why "dnf upgrade" called interactively on a shell does such an excessive caching so that people are wondering if it is working properly at all.
If I do "ls" on my shell prompt, I also expect the actual contents of the current directory and not some cached output six hours ago. :-)
Greetings, Andreas
On Thu, Aug 13, 2015 at 07:43:49PM +0000, Andreas M. Kirchwitz wrote:
Rahul Sundaram metherid@gmail.com wrote:
However, if somebody runs "dnf upgrade" on the command shell then he clearly wants the latest updates. Right now! No caching or other magic involved. That's the whole point of running "dnf upgrade" manually, otherwise the user would have left the whole updating business to some automated background task.
If this is what you want, use dnf update --refresh instead
That does clearly *not* provide the latest updates. It's better than without "--refresh", but "dnf clean metadata" is required for full updates available.
FWIW, this my bug report fell on deaf ears:
https://bugzilla.redhat.com/show_bug.cgi?id=1246253
I find it disheartening how it was closed without even acknowledging that the problem exists, so I decided not to pursue this further. If someone is willing to put in the effort to push for this, please reopen the bug. Or maybe a new one, specifically on --refresh not doing what it is supposed to.
Cheers,
Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
In practice, there's not much of a difference between "clean all" or just "clean metadata". Because both require the update/upgrade command to download all stuff from the network and build to whole meta database from scratch, even if that wouldn't be necessary.
Sorry, that's not correct. Ever since the yum days, they have been different. The key differences are these two bits (from `man dnf'): [...]
Sorry for any confusion I may have caused by my statement. Of course, both are not the same, but if a user of a standard Fedora system with no fancy configuration just wants to install latest updates (and rarely uses dnf for anything else), then my experience shows that there's no significant amount of cached data that "clean metadata" would have preserved over "clean all".
No matter if "dnf clean metadata" or "dnf clean all" is used, the directly following "dnf upgrade" uses the same amount of resources (traffic + CPU).
Yes, I agree, other commands may benefit a lot if "clean metadata" is used instead of "clean all". Personally, I rarely use dnf for anything but updating the system. Maybe that's why I don't see a difference.
But to be honest, that wasn't my point anyway. My point is that users should not need to use either of those (clean metadata or clean all), but there should be a way that "dnf upgrade" (especially if used interactively on command-line) provides what users expect without any fiddling with cached data.
During the yum days, the most frequent complaint on this list were: why is yum so slow, I hate waiting for metadata updates, .... and so on. And now people complain, the cached metadata is out of date (please don't confuse this with actual bugs). There is no winning, you either wait for the metadata to download, or you get a responsive interface.
For my individual needs, I run "dnf --disablerepo=fedora clean metadata" before I check for updates (actually I use a two-line script for that). The "fedora" repository uses up the most resources for downloading and rebuilding metadata. This way I still benefit from caching but also get the freshest updates.
For all other yum/dnf operations (which I rarely use) I'm fine with the default caching and happily use the default repo files provided by Fedora.
PS: I've no relation to the dnf team, just a user. I however think instead of complaining on the list, if any discussions here lead you to think there is a problem with dnf (as in a bug), you should file bug reports.
Several tickets already exist for that issue, and the answer is always the same: People should run "clean metadata" (or "clean all" if they have plenty of resources) before they update.
Technically, that might be a proper solution, but that won't get people from asking the very same question over and over again.
Maybe it would be less confusing if "--refresh" did the job (which sounds like a cool workaround for that kind of problem) but there's a difference between "--refresh" and "clean metadata". Could that be caused by "metadata_expire=6h" in fedora-updates.repo?
Greetings, Andreas
On Thu, 2015-08-13 at 20:49 +0000, Andreas M. Kirchwitz wrote:
Maybe it would be less confusing if "--refresh" did the job (which sounds like a cool workaround for that kind of problem) but there's a difference between "--refresh" and "clean metadata".
From the dnf(1) man page:
Note that in all situations the user can force synchronization of all enabled repositories with the --refresh switch.
So are you saying the documentation is wrong?
poc
Hi
On Thu, Aug 13, 2015 at 3:43 PM, Andreas M. Kirchwitz wrote:
That does clearly *not* provide the latest updates. It's better than without "--refresh", but "dnf clean metadata" is required for full updates available.
That contradicts the documentation provided. I would suggest filing a bug report. I would do it myself if I can reproduce that but I haven't run into this problem
Rahul
On Thu, 13 Aug 2015 23:05:06 -0400, Rahul Sundaram wrote:
Hi
On Thu, Aug 13, 2015 at 3:43 PM, Andreas M. Kirchwitz wrote:
That does clearly *not* provide the latest updates. It's better than without "--refresh", but "dnf clean metadata" is required for full updates available.
That contradicts the documentation provided. I would suggest filing a bug report. I would do it myself if I can reproduce that but I haven't run into this problem
From my observations so far, it seems users are mistaken in at least one case. Behaviour of running with --refresh and after "clean metadata" (or the infamous "clean all") differs, because whereas the latter forces dnf to start from scratch and download all metadata, the former only expires the metadata. It remains available in the cache for a check whether it may still be current. A similar "clean" command that doesn't remove the metadata is "clean expire-cache", but unfortunately, users always compare with "clean all" which removes too much in nearly all cases.
And here's proof of what can happen with just --refresh:
1. dnf update 2. dnf update --refresh 3. dnf update --refresh
The last run reverts to older metadata with only 50 updates available compared with earlier. Mirror manager assigning to an out-of-date mirror?
# dnf update Last metadata expiration check performed 1:19:01 ago on Fri Aug 14 11:29:15 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 72 k kernel-core x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 20 M kernel-modules x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 18 M Upgrading: automake noarch 1.15-5.fc24 rawhide 694 k boost x86_64 1.58.0-6.fc24 rawhide 43 k boost-atomic x86_64 1.58.0-6.fc24 rawhide 45 k boost-chrono x86_64 1.58.0-6.fc24 rawhide 52 k boost-container x86_64 1.58.0-6.fc24 rawhide 66 k boost-context x86_64 1.58.0-6.fc24 rawhide 58 k boost-coroutine x86_64 1.58.0-6.fc24 rawhide 59 k boost-date-time x86_64 1.58.0-6.fc24 rawhide 58 k boost-devel x86_64 1.58.0-6.fc24 rawhide 8.1 M boost-filesystem x86_64 1.58.0-6.fc24 rawhide 73 k boost-graph x86_64 1.58.0-6.fc24 rawhide 137 k boost-iostreams x86_64 1.58.0-6.fc24 rawhide 67 k boost-locale x86_64 1.58.0-6.fc24 rawhide 278 k boost-log x86_64 1.58.0-6.fc24 rawhide 478 k boost-math x86_64 1.58.0-6.fc24 rawhide 312 k boost-program-options x86_64 1.58.0-6.fc24 rawhide 165 k boost-python x86_64 1.58.0-6.fc24 rawhide 133 k boost-random x86_64 1.58.0-6.fc24 rawhide 51 k boost-regex x86_64 1.58.0-6.fc24 rawhide 296 k boost-serialization x86_64 1.58.0-6.fc24 rawhide 156 k boost-signals x86_64 1.58.0-6.fc24 rawhide 70 k boost-system x86_64 1.58.0-6.fc24 rawhide 48 k boost-test x86_64 1.58.0-6.fc24 rawhide 220 k boost-thread x86_64 1.58.0-6.fc24 rawhide 88 k boost-timer x86_64 1.58.0-6.fc24 rawhide 50 k boost-wave x86_64 1.58.0-6.fc24 rawhide 234 k crontabs noarch 1.11-11.20150630git.fc24 rawhide 23 k curl x86_64 7.44.0-1.fc24 rawhide 284 k dbus x86_64 1:1.9.20-1.fc24 rawhide 240 k dbus-devel x86_64 1:1.9.20-1.fc24 rawhide 57 k dbus-libs x86_64 1:1.9.20-1.fc24 rawhide 171 k dbus-x11 x86_64 1:1.9.20-1.fc24 rawhide 51 k dhcp-client x86_64 12:4.3.3-0.2b1.fc24 rawhide 297 k dhcp-common noarch 12:4.3.3-0.2b1.fc24 rawhide 192 k dhcp-libs x86_64 12:4.3.3-0.2b1.fc24 rawhide 136 k dracut x86_64 043-60.git20150811.fc24 rawhide 322 k dracut-config-rescue x86_64 043-60.git20150811.fc24 rawhide 44 k dracut-network x86_64 043-60.git20150811.fc24 rawhide 82 k firefox x86_64 40.0-4.fc24 rawhide 71 M fontconfig x86_64 2.11.94-3.fc24 rawhide 241 k fontconfig-devel x86_64 2.11.94-3.fc24 rawhide 136 k gnupg2 x86_64 2.1.6-1.fc24 rawhide 1.8 M hplip x86_64 3.15.7-4.fc24 rawhide 12 M hplip-common x86_64 3.15.7-4.fc24 rawhide 96 k hplip-compat-libs x86_64 3.15.7-4.fc24 rawhide 76 k hplip-libs x86_64 3.15.7-4.fc24 rawhide 185 k kernel-headers x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 1.0 M libblkid x86_64 2.27-0.2.fc24 rawhide 178 k libcacard x86_64 2:2.4.0-1.fc24 rawhide 74 k libcurl x86_64 7.44.0-1.fc24 rawhide 256 k libcurl-devel x86_64 7.44.0-1.fc24 rawhide 596 k liberation-fonts-common noarch 1:1.07.4-6.fc24 rawhide 31 k liberation-mono-fonts noarch 1:1.07.4-6.fc24 rawhide 232 k liberation-sans-fonts noarch 1:1.07.4-6.fc24 rawhide 284 k liberation-serif-fonts noarch 1:1.07.4-6.fc24 rawhide 304 k libfdisk x86_64 2.27-0.2.fc24 rawhide 219 k libmount x86_64 2.27-0.2.fc24 rawhide 195 k libsane-hpaio x86_64 3.15.7-4.fc24 rawhide 112 k libsmartcols x86_64 2.27-0.2.fc24 rawhide 137 k libuuid x86_64 2.27-0.2.fc24 rawhide 78 k netpbm x86_64 10.71.02-1.fc24 rawhide 184 k openssl x86_64 1:1.0.2d-2.fc24 rawhide 510 k openssl-devel x86_64 1:1.0.2d-2.fc24 rawhide 1.5 M openssl-libs x86_64 1:1.0.2d-2.fc24 rawhide 1.2 M pam x86_64 1.2.1-2.fc24 rawhide 729 k python3 x86_64 3.4.3-5.fc24 rawhide 53 k python3-cups x86_64 1.9.72-3.fc24 rawhide 81 k python3-libs x86_64 3.4.3-5.fc24 rawhide 6.7 M qemu-common x86_64 2:2.4.0-1.fc24 rawhide 291 k qemu-guest-agent x86_64 2:2.4.0-1.fc24 rawhide 173 k qemu-img x86_64 2:2.4.0-1.fc24 rawhide 652 k qemu-kvm x86_64 2:2.4.0-1.fc24 rawhide 55 k qemu-system-x86 x86_64 2:2.4.0-1.fc24 rawhide 4.1 M tzdata noarch 2015f-1.fc24 rawhide 406 k tzdata-java noarch 2015f-1.fc24 rawhide 176 k util-linux x86_64 2.27-0.2.fc24 rawhide 2.1 M Removing: kernel x86_64 4.2.0-0.rc5.git2.1.fc24 @System 0 kernel-core x86_64 4.2.0-0.rc5.git2.1.fc24 @System 51 M kernel-modules x86_64 4.2.0-0.rc5.git2.1.fc24 @System 17 M Skipping packages with broken dependencies: fwupd x86_64 0.1.5-1.fc24 rawhide 112 k gnome-software x86_64 3.17.3-1.fc24 rawhide 1.9 M libappstream-glib x86_64 0.5.0-1.fc24 rawhide 179 k
Transaction Summary ================================================================================ Install 3 Packages Upgrade 76 Packages Remove 3 Packages
Total download size: 159 M Is this ok [y/N]: n Operation aborted.
# dnf update --refresh Adobe Systems Incorporated 21 kB/s | 1.8 kB 00:00 Fedora - Rawhide - Developmental packages for t 1.5 MB/s | 43 MB 00:29 Last metadata expiration check performed 0:00:13 ago on Fri Aug 14 12:48:43 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 72 k kernel-core x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 20 M kernel-modules x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 18 M Upgrading: automake noarch 1.15-5.fc24 rawhide 694 k boost x86_64 1.58.0-6.fc24 rawhide 43 k boost-atomic x86_64 1.58.0-6.fc24 rawhide 45 k boost-chrono x86_64 1.58.0-6.fc24 rawhide 52 k boost-container x86_64 1.58.0-6.fc24 rawhide 66 k boost-context x86_64 1.58.0-6.fc24 rawhide 58 k boost-coroutine x86_64 1.58.0-6.fc24 rawhide 59 k boost-date-time x86_64 1.58.0-6.fc24 rawhide 58 k boost-devel x86_64 1.58.0-6.fc24 rawhide 8.1 M boost-filesystem x86_64 1.58.0-6.fc24 rawhide 73 k boost-graph x86_64 1.58.0-6.fc24 rawhide 137 k boost-iostreams x86_64 1.58.0-6.fc24 rawhide 67 k boost-locale x86_64 1.58.0-6.fc24 rawhide 278 k boost-log x86_64 1.58.0-6.fc24 rawhide 478 k boost-math x86_64 1.58.0-6.fc24 rawhide 312 k boost-program-options x86_64 1.58.0-6.fc24 rawhide 165 k boost-python x86_64 1.58.0-6.fc24 rawhide 133 k boost-random x86_64 1.58.0-6.fc24 rawhide 51 k boost-regex x86_64 1.58.0-6.fc24 rawhide 296 k boost-serialization x86_64 1.58.0-6.fc24 rawhide 156 k boost-signals x86_64 1.58.0-6.fc24 rawhide 70 k boost-system x86_64 1.58.0-6.fc24 rawhide 48 k boost-test x86_64 1.58.0-6.fc24 rawhide 220 k boost-thread x86_64 1.58.0-6.fc24 rawhide 88 k boost-timer x86_64 1.58.0-6.fc24 rawhide 50 k boost-wave x86_64 1.58.0-6.fc24 rawhide 234 k crontabs noarch 1.11-11.20150630git.fc24 rawhide 23 k curl x86_64 7.44.0-1.fc24 rawhide 284 k dbus x86_64 1:1.9.20-1.fc24 rawhide 240 k dbus-devel x86_64 1:1.9.20-1.fc24 rawhide 57 k dbus-libs x86_64 1:1.9.20-1.fc24 rawhide 171 k dbus-x11 x86_64 1:1.9.20-1.fc24 rawhide 51 k dhcp-client x86_64 12:4.3.3-0.2b1.fc24 rawhide 297 k dhcp-common noarch 12:4.3.3-0.2b1.fc24 rawhide 192 k dhcp-libs x86_64 12:4.3.3-0.2b1.fc24 rawhide 136 k dracut x86_64 043-60.git20150811.fc24 rawhide 322 k dracut-config-rescue x86_64 043-60.git20150811.fc24 rawhide 44 k dracut-network x86_64 043-60.git20150811.fc24 rawhide 82 k firefox x86_64 40.0-4.fc24 rawhide 71 M fontconfig x86_64 2.11.94-3.fc24 rawhide 241 k fontconfig-devel x86_64 2.11.94-3.fc24 rawhide 136 k gnupg2 x86_64 2.1.6-1.fc24 rawhide 1.8 M hplip x86_64 3.15.7-4.fc24 rawhide 12 M hplip-common x86_64 3.15.7-4.fc24 rawhide 96 k hplip-compat-libs x86_64 3.15.7-4.fc24 rawhide 76 k hplip-libs x86_64 3.15.7-4.fc24 rawhide 185 k kernel-headers x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 1.0 M libblkid x86_64 2.27-0.2.fc24 rawhide 178 k libcacard x86_64 2:2.4.0-1.fc24 rawhide 74 k libcurl x86_64 7.44.0-1.fc24 rawhide 256 k libcurl-devel x86_64 7.44.0-1.fc24 rawhide 596 k liberation-fonts-common noarch 1:1.07.4-6.fc24 rawhide 31 k liberation-mono-fonts noarch 1:1.07.4-6.fc24 rawhide 232 k liberation-sans-fonts noarch 1:1.07.4-6.fc24 rawhide 284 k liberation-serif-fonts noarch 1:1.07.4-6.fc24 rawhide 304 k libfdisk x86_64 2.27-0.2.fc24 rawhide 219 k libmount x86_64 2.27-0.2.fc24 rawhide 195 k libsane-hpaio x86_64 3.15.7-4.fc24 rawhide 112 k libsmartcols x86_64 2.27-0.2.fc24 rawhide 137 k libuuid x86_64 2.27-0.2.fc24 rawhide 78 k netpbm x86_64 10.71.02-1.fc24 rawhide 184 k openssl x86_64 1:1.0.2d-2.fc24 rawhide 510 k openssl-devel x86_64 1:1.0.2d-2.fc24 rawhide 1.5 M openssl-libs x86_64 1:1.0.2d-2.fc24 rawhide 1.2 M pam x86_64 1.2.1-2.fc24 rawhide 729 k python3 x86_64 3.4.3-5.fc24 rawhide 53 k python3-cups x86_64 1.9.72-3.fc24 rawhide 81 k python3-libs x86_64 3.4.3-5.fc24 rawhide 6.7 M qemu-common x86_64 2:2.4.0-1.fc24 rawhide 291 k qemu-guest-agent x86_64 2:2.4.0-1.fc24 rawhide 173 k qemu-img x86_64 2:2.4.0-1.fc24 rawhide 652 k qemu-kvm x86_64 2:2.4.0-1.fc24 rawhide 55 k qemu-system-x86 x86_64 2:2.4.0-1.fc24 rawhide 4.1 M tzdata noarch 2015f-1.fc24 rawhide 406 k tzdata-java noarch 2015f-1.fc24 rawhide 176 k util-linux x86_64 2.27-0.2.fc24 rawhide 2.1 M Removing: kernel x86_64 4.2.0-0.rc5.git2.1.fc24 @System 0 kernel-core x86_64 4.2.0-0.rc5.git2.1.fc24 @System 51 M kernel-modules x86_64 4.2.0-0.rc5.git2.1.fc24 @System 17 M Skipping packages with broken dependencies: fwupd x86_64 0.1.5-1.fc24 rawhide 112 k gnome-software x86_64 3.17.3-1.fc24 rawhide 1.9 M libappstream-glib x86_64 0.5.0-1.fc24 rawhide 179 k
Transaction Summary ================================================================================ Install 3 Packages Upgrade 76 Packages Remove 3 Packages
Total download size: 159 M Is this ok [y/N]: n Operation aborted.
# dnf update --refresh Fedora - Rawhide - Developmental packages for t 1.4 MB/s | 43 MB 00:30 Adobe Systems Incorporated 21 kB/s | 1.8 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Fri Aug 14 12:50:08 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Upgrading: boost x86_64 1.58.0-6.fc24 rawhide 43 k boost-atomic x86_64 1.58.0-6.fc24 rawhide 45 k boost-chrono x86_64 1.58.0-6.fc24 rawhide 52 k boost-container x86_64 1.58.0-6.fc24 rawhide 66 k boost-context x86_64 1.58.0-6.fc24 rawhide 58 k boost-coroutine x86_64 1.58.0-6.fc24 rawhide 59 k boost-date-time x86_64 1.58.0-6.fc24 rawhide 58 k boost-devel x86_64 1.58.0-6.fc24 rawhide 8.1 M boost-filesystem x86_64 1.58.0-6.fc24 rawhide 73 k boost-graph x86_64 1.58.0-6.fc24 rawhide 137 k boost-iostreams x86_64 1.58.0-6.fc24 rawhide 67 k boost-locale x86_64 1.58.0-6.fc24 rawhide 278 k boost-log x86_64 1.58.0-6.fc24 rawhide 478 k boost-math x86_64 1.58.0-6.fc24 rawhide 312 k boost-program-options x86_64 1.58.0-6.fc24 rawhide 165 k boost-python x86_64 1.58.0-6.fc24 rawhide 133 k boost-random x86_64 1.58.0-6.fc24 rawhide 51 k boost-regex x86_64 1.58.0-6.fc24 rawhide 296 k boost-serialization x86_64 1.58.0-6.fc24 rawhide 156 k boost-signals x86_64 1.58.0-6.fc24 rawhide 70 k boost-system x86_64 1.58.0-6.fc24 rawhide 48 k boost-test x86_64 1.58.0-6.fc24 rawhide 220 k boost-thread x86_64 1.58.0-6.fc24 rawhide 88 k boost-timer x86_64 1.58.0-6.fc24 rawhide 50 k boost-wave x86_64 1.58.0-6.fc24 rawhide 234 k dbus x86_64 1:1.9.20-1.fc24 rawhide 240 k dbus-devel x86_64 1:1.9.20-1.fc24 rawhide 57 k dbus-libs x86_64 1:1.9.20-1.fc24 rawhide 171 k dbus-x11 x86_64 1:1.9.20-1.fc24 rawhide 51 k dhcp-client x86_64 12:4.3.3-0.2b1.fc24 rawhide 297 k dhcp-common noarch 12:4.3.3-0.2b1.fc24 rawhide 192 k dhcp-libs x86_64 12:4.3.3-0.2b1.fc24 rawhide 136 k dracut x86_64 043-60.git20150811.fc24 rawhide 322 k dracut-config-rescue x86_64 043-60.git20150811.fc24 rawhide 44 k dracut-network x86_64 043-60.git20150811.fc24 rawhide 82 k firefox x86_64 40.0-3.fc24 rawhide 71 M gnupg2 x86_64 2.1.6-1.fc24 rawhide 1.8 M hplip x86_64 3.15.7-4.fc24 rawhide 12 M hplip-common x86_64 3.15.7-4.fc24 rawhide 96 k hplip-compat-libs x86_64 3.15.7-4.fc24 rawhide 76 k hplip-libs x86_64 3.15.7-4.fc24 rawhide 185 k libcacard x86_64 2:2.4.0-1.fc24 rawhide 74 k libsane-hpaio x86_64 3.15.7-4.fc24 rawhide 112 k netpbm x86_64 10.71.02-1.fc24 rawhide 184 k python3-cups x86_64 1.9.72-3.fc24 rawhide 81 k qemu-common x86_64 2:2.4.0-1.fc24 rawhide 291 k qemu-guest-agent x86_64 2:2.4.0-1.fc24 rawhide 173 k qemu-img x86_64 2:2.4.0-1.fc24 rawhide 652 k qemu-kvm x86_64 2:2.4.0-1.fc24 rawhide 55 k qemu-system-x86 x86_64 2:2.4.0-1.fc24 rawhide 4.1 M
Transaction Summary ================================================================================ Upgrade 50 Packages
Total download size: 104 M Is this ok [y/N]: n Operation aborted.
# rpm -q dnf dnf-1.1.0-2.fc24.noarch
On Fri, 2015-08-14 at 12:47 +0200, Michael Schwendt wrote:
Behaviour of running with --refresh and after "clean metadata" (or the infamous "clean all") differs, because whereas the latter forces dnf to start from scratch and download all metadata, the former only expires the metadata. It remains available in the cache for a check whether it may still be current.
If the metadata is expired, why is it being checked for currency?
poc
On Fri, 14 Aug 2015 11:59:48 +0100, Patrick O'Callaghan wrote:
If the metadata is expired, why is it being checked for currency?
User tells the tool the metadata are expired. Whether that is true, remains to be seen. They are still in the local cache, and the mirroring system may tell that there are no different metadata. Then there's no need to redownload them.
If the documentation is not accurate, and if --refresh removes the cached metadata always, then the developers ought to make that clear.
--refresh set metadata as expired before running the command
dnf clean expire-cache Removes local cookie files saying when the metadata and mir‐ rorlists were downloaded for each repo. DNF will re-validate the cache for each repo the next time it is used.
dnf clean metadata Removes repository metadata. Those are the files which DNF uses to determine the remote availability of packages. Using this option will make DNF download all the metadata the next time it is run.
And here's proof of what can happen with just --refresh:
- dnf update
- dnf update --refresh
- dnf update --refresh
The last run reverts to older metadata with only 50 updates available compared with earlier. Mirror manager assigning to an out-of-date mirror?
A day later, no matter how often I run "dnf update --refresh", it never gets access to the newer metadata from yesterday again. Not the 76 packages as shown earlier in this thread, only the older 50.
So, indeed, there's something seriously wrong here, and I assume it can only be fixed if the developers of mirror manager and dnf come together and look into it.
After giving the "dnf clean expire-cache" option another try, too, and then the hammer "dnf clean metadata", there has been a fresh download of even newer metadata compared with yesterday:
[...] Install 4 Packages Upgrade 111 Packages Remove 3 Packages
Total download size: 211 M [...]
# rpm -q dnf dnf-1.1.0-2.fc24.noarch
On 15.08.2015, Michael Schwendt wrote:
A day later, no matter how often I run "dnf update --refresh", it never gets access to the newer metadata from yesterday again. Not the 76 packages as shown earlier in this thread, only the older 50.
Jupp! It's exactly what I'm encountering since moving to F22, as shown several times in this list.
So, indeed, there's something seriously wrong here, and I assume it can only be fixed if the developers of mirror manager and dnf come together and look into it.
Indeed.
On Sat, 2015-08-15 at 13:21 +0200, Michael Schwendt wrote:
So, indeed, there's something seriously wrong here, and I assume it can only be fixed if the developers of mirror manager and dnf come together and look into it.
Worth a BZ report surely?
I have no special insight into this, but often at the root of this type of problem there is a failure to clearly specify what each of the components is supposed to do, resulting in a mismatch between reality and expectation on either side.
poc
On Sat, 15 Aug 2015 13:40:04 +0100, Patrick O'Callaghan wrote:
Worth a BZ report surely?
Not from me this time. It is my understanding that there have been multiple reports before.
A few hours have passed, and meanwhile there are even newer metadata. However, a subsequent run of "dnf update --refresh" reverted to older metadata. See bottom.
I have no special insight into this, but often at the root of this type of problem there is a failure to clearly specify what each of the components is supposed to do, resulting in a mismatch between reality and expectation on either side.
Or using ambiguous terminology. I've seen that occasionally.
"dnf update --refresh" currently redownloads the 43 MB metadata *always*. The manual page says:
--refresh set metadata as expired before running the command
Apparently, it doesn't try to verify/confirm whether the cache matches what the server offers. It seems to be less than "clean expire-cache" and more like "clean metadata".
It would need somebody with intimate knowledge of what mirror manager supports. To tell whether the package tool can decide which metadata are the latest. Perhaps timezones are not considered? Or why else did it decide to download something that's older? Did mirror manage tell that the cache metadata are not "current"?
Here's a fresh reproducer. First it fetched the newer metadata, then it refreshed to something older:
# dnf update --refresh Adobe Systems Incorporated 21 kB/s | 1.8 kB 00:00 Fedora - Rawhide - Developmental packages for t 1.5 MB/s | 43 MB 00:29 Last metadata expiration check performed 0:00:11 ago on Sat Aug 15 19:21:15 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 4.2.0-0.rc6.git1.1.fc24 rawhide 72 k kernel-core x86_64 4.2.0-0.rc6.git1.1.fc24 rawhide 20 M kernel-modules x86_64 4.2.0-0.rc6.git1.1.fc24 rawhide 18 M ncurses-compat-libs x86_64 6.0-1.20150810.fc24 rawhide 305 k Upgrading: NetworkManager x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 2.0 M NetworkManager-adsl x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 110 k NetworkManager-bluetooth x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 133 k NetworkManager-config-connectivity-fedora x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 100 k NetworkManager-glib x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 366 k NetworkManager-libnm x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 476 k NetworkManager-team x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 112 k NetworkManager-wifi x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 140 k NetworkManager-wwan x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 133 k PackageKit x86_64 1.0.7-3.fc24 rawhide 575 k PackageKit-cached-metadata x86_64 1.0.7-3.fc24 rawhide 73 M PackageKit-command-not-found x86_64 1.0.7-3.fc24 rawhide 27 k PackageKit-glib x86_64 1.0.7-3.fc24 rawhide 131 k PackageKit-gstreamer-plugin x86_64 1.0.7-3.fc24 rawhide 19 k PackageKit-gtk3-module x86_64 1.0.7-3.fc24 rawhide 19 k acl x86_64 2.2.52-10.fc24 rawhide 76 k attr x86_64 2.4.47-13.fc24 rawhide 64 k automake noarch 1.15-5.fc24 rawhide 694 k boost x86_64 1.58.0-6.fc24 rawhide 43 k boost-atomic x86_64 1.58.0-6.fc24 rawhide 45 k boost-chrono x86_64 1.58.0-6.fc24 rawhide 52 k boost-container x86_64 1.58.0-6.fc24 rawhide 66 k boost-context x86_64 1.58.0-6.fc24 rawhide 58 k boost-coroutine x86_64 1.58.0-6.fc24 rawhide 59 k boost-date-time x86_64 1.58.0-6.fc24 rawhide 58 k boost-devel x86_64 1.58.0-6.fc24 rawhide 8.1 M boost-filesystem x86_64 1.58.0-6.fc24 rawhide 73 k boost-graph x86_64 1.58.0-6.fc24 rawhide 137 k boost-iostreams x86_64 1.58.0-6.fc24 rawhide 67 k boost-locale x86_64 1.58.0-6.fc24 rawhide 278 k boost-log x86_64 1.58.0-6.fc24 rawhide 478 k boost-math x86_64 1.58.0-6.fc24 rawhide 312 k boost-program-options x86_64 1.58.0-6.fc24 rawhide 165 k boost-python x86_64 1.58.0-6.fc24 rawhide 133 k boost-random x86_64 1.58.0-6.fc24 rawhide 51 k boost-regex x86_64 1.58.0-6.fc24 rawhide 296 k boost-serialization x86_64 1.58.0-6.fc24 rawhide 156 k boost-signals x86_64 1.58.0-6.fc24 rawhide 70 k boost-system x86_64 1.58.0-6.fc24 rawhide 48 k boost-test x86_64 1.58.0-6.fc24 rawhide 220 k boost-thread x86_64 1.58.0-6.fc24 rawhide 88 k boost-timer x86_64 1.58.0-6.fc24 rawhide 50 k boost-wave x86_64 1.58.0-6.fc24 rawhide 234 k bzip2 x86_64 1.0.6-17.fc24 rawhide 57 k bzip2-libs x86_64 1.0.6-17.fc24 rawhide 43 k ca-certificates noarch 2015.2.5-2.fc24 rawhide 441 k cmake x86_64 3.3.1-1.fc24 rawhide 7.3 M crda x86_64 3.18_2015.04.06-3.fc24 rawhide 42 k crontabs noarch 1.11-11.20150630git.fc24 rawhide 23 k cups x86_64 1:2.1-0.3rc1.fc24 rawhide 1.3 M cups-client x86_64 1:2.1-0.3rc1.fc24 rawhide 153 k cups-filesystem noarch 1:2.1-0.3rc1.fc24 rawhide 99 k cups-libs x86_64 1:2.1-0.3rc1.fc24 rawhide 394 k curl x86_64 7.44.0-1.fc24 rawhide 284 k dbus x86_64 1:1.9.20-2.fc24 rawhide 240 k dbus-devel x86_64 1:1.9.20-2.fc24 rawhide 58 k dbus-libs x86_64 1:1.9.20-2.fc24 rawhide 172 k dbus-x11 x86_64 1:1.9.20-2.fc24 rawhide 51 k desktop-file-utils x86_64 0.22-6.fc24 rawhide 75 k device-mapper-multipath x86_64 0.4.9-78.fc24 rawhide 119 k device-mapper-multipath-libs x86_64 0.4.9-78.fc24 rawhide 219 k device-mapper-persistent-data x86_64 0.5.5-1.fc24 rawhide 407 k dhcp-client x86_64 12:4.3.3-0.2b1.fc24 rawhide 297 k dhcp-common noarch 12:4.3.3-0.2b1.fc24 rawhide 192 k dhcp-libs x86_64 12:4.3.3-0.2b1.fc24 rawhide 136 k dracut x86_64 043-60.git20150811.fc24 rawhide 322 k dracut-config-rescue x86_64 043-60.git20150811.fc24 rawhide 44 k dracut-network x86_64 043-60.git20150811.fc24 rawhide 82 k firefox x86_64 40.0-4.fc24 rawhide 71 M fontconfig x86_64 2.11.94-4.fc24 rawhide 240 k fontconfig-devel x86_64 2.11.94-4.fc24 rawhide 136 k fwupd x86_64 0.1.5-1.fc24 rawhide 112 k gedit x86_64 2:3.17.2-2.fc24 rawhide 2.5 M giflib x86_64 4.1.6-14.fc24 rawhide 43 k glib2 x86_64 2.45.4-2.fc24 rawhide 2.3 M glib2-devel x86_64 2.45.4-2.fc24 rawhide 435 k glibc x86_64 2.22.90-2.fc24 rawhide 3.7 M glibc-common x86_64 2.22.90-2.fc24 rawhide 11 M glibc-devel x86_64 2.22.90-2.fc24 rawhide 908 k glibc-headers x86_64 2.22.90-2.fc24 rawhide 492 k gnome-software x86_64 3.17.3-1.fc24 rawhide 1.9 M gnupg2 x86_64 2.1.7-1.fc24 rawhide 1.8 M gtk-update-icon-cache x86_64 3.17.6-3.fc24 rawhide 34 k gtk3 x86_64 3.17.6-3.fc24 rawhide 4.3 M gtk3-devel x86_64 3.17.6-3.fc24 rawhide 4.0 M hplip x86_64 3.15.7-4.fc24 rawhide 12 M hplip-common x86_64 3.15.7-4.fc24 rawhide 96 k hplip-compat-libs x86_64 3.15.7-4.fc24 rawhide 76 k hplip-libs x86_64 3.15.7-4.fc24 rawhide 185 k java-1.8.0-openjdk-headless x86_64 1:1.8.0.60-11.b24.fc24 rawhide 31 M jsoncpp x86_64 0.6.0-0.18.rc2.fc24 rawhide 62 k kernel-headers x86_64 4.2.0-0.rc6.git1.1.fc24 rawhide 1.0 M keyutils x86_64 1.5.9-7.fc24 rawhide 59 k keyutils-libs x86_64 1.5.9-7.fc24 rawhide 44 k keyutils-libs-devel x86_64 1.5.9-7.fc24 rawhide 44 k kpartx x86_64 0.4.9-78.fc24 rawhide 61 k libacl x86_64 2.2.52-10.fc24 rawhide 30 k libappstream-glib x86_64 0.5.0-1.fc24 rawhide 179 k libattr x86_64 2.4.47-13.fc24 rawhide 23 k libblkid x86_64 2.27-0.3.fc24 rawhide 178 k libcacard x86_64 2:2.4.0-1.fc24 rawhide 74 k libcurl x86_64 7.44.0-1.fc24 rawhide 256 k libcurl-devel x86_64 7.44.0-1.fc24 rawhide 596 k liberation-fonts-common noarch 1:1.07.4-6.fc24 rawhide 31 k liberation-mono-fonts noarch 1:1.07.4-6.fc24 rawhide 232 k liberation-sans-fonts noarch 1:1.07.4-6.fc24 rawhide 284 k liberation-serif-fonts noarch 1:1.07.4-6.fc24 rawhide 304 k libfdisk x86_64 2.27-0.3.fc24 rawhide 219 k libgxps x86_64 0.2.3-1.fc24 rawhide 80 k libmount x86_64 2.27-0.3.fc24 rawhide 195 k libsane-hpaio x86_64 3.15.7-4.fc24 rawhide 112 k libselinux x86_64 2.4-2.fc24 rawhide 145 k libselinux-devel x86_64 2.4-2.fc24 rawhide 181 k libselinux-python x86_64 2.4-2.fc24 rawhide 301 k libselinux-python3 x86_64 2.4-2.fc24 rawhide 302 k libselinux-utils x86_64 2.4-2.fc24 rawhide 142 k libsemanage x86_64 2.4-3.fc24 rawhide 146 k libsemanage-python x86_64 2.4-3.fc24 rawhide 108 k libsemanage-python3 x86_64 2.4-3.fc24 rawhide 111 k libsepol x86_64 2.4-2.fc24 rawhide 256 k libsepol-devel x86_64 2.4-2.fc24 rawhide 76 k libsidplayfp x86_64 1.8.1-1.fc24 rawhide 155 k libsidplayfp-devel x86_64 1.8.1-1.fc24 rawhide 25 k libsmartcols x86_64 2.27-0.3.fc24 rawhide 138 k libuuid x86_64 2.27-0.3.fc24 rawhide 78 k libwmf x86_64 0.2.8.4-46.fc24 rawhide 139 k libwmf-lite x86_64 0.2.8.4-46.fc24 rawhide 71 k lzo x86_64 2.08-5.fc24 rawhide 64 k ncurses x86_64 6.0-1.20150810.fc24 rawhide 334 k ncurses-base noarch 6.0-1.20150810.fc24 rawhide 75 k ncurses-devel x86_64 6.0-1.20150810.fc24 rawhide 500 k ncurses-libs x86_64 6.0-1.20150810.fc24 rawhide 326 k netpbm x86_64 10.71.02-1.fc24 rawhide 184 k openssh x86_64 7.0p1-1.fc24 rawhide 441 k openssh-askpass x86_64 7.0p1-1.fc24 rawhide 76 k openssh-clients x86_64 7.0p1-1.fc24 rawhide 630 k openssh-server x86_64 7.0p1-1.fc24 rawhide 456 k openssl x86_64 1:1.0.2d-2.fc24 rawhide 510 k openssl-devel x86_64 1:1.0.2d-2.fc24 rawhide 1.5 M openssl-libs x86_64 1:1.0.2d-2.fc24 rawhide 1.2 M oxygen-icon-theme noarch 15.04.3-2.fc24 rawhide 28 M pam x86_64 1.2.1-2.fc24 rawhide 729 k policycoreutils x86_64 2.4-9.fc24 rawhide 920 k policycoreutils-python-utils x86_64 2.4-9.fc24 rawhide 212 k policycoreutils-python3 x86_64 2.4-9.fc24 rawhide 1.8 M procps-ng x86_64 3.3.10-9.fc24 rawhide 391 k python-cryptography x86_64 1.0-1.fc24 rawhide 439 k python-idna noarch 2.0-1.fc24 rawhide 96 k python-slip noarch 0.6.2-1.fc24 rawhide 34 k python-slip-dbus noarch 0.6.2-1.fc24 rawhide 35 k python3 x86_64 3.4.3-5.fc24 rawhide 53 k python3-cups x86_64 1.9.72-3.fc24 rawhide 81 k python3-libs x86_64 3.4.3-5.fc24 rawhide 6.7 M python3-slip noarch 0.6.2-1.fc24 rawhide 34 k python3-slip-dbus noarch 0.6.2-1.fc24 rawhide 36 k qemu-common x86_64 2:2.4.0-1.fc24 rawhide 291 k qemu-guest-agent x86_64 2:2.4.0-1.fc24 rawhide 173 k qemu-img x86_64 2:2.4.0-1.fc24 rawhide 652 k qemu-kvm x86_64 2:2.4.0-1.fc24 rawhide 55 k qemu-system-x86 x86_64 2:2.4.0-1.fc24 rawhide 4.1 M readline x86_64 6.3-7.fc24 rawhide 202 k shared-mime-info x86_64 1.4-7.fc24 rawhide 292 k tzdata noarch 2015f-1.fc24 rawhide 406 k tzdata-java noarch 2015f-1.fc24 rawhide 176 k util-linux x86_64 2.27-0.3.fc24 rawhide 2.1 M vinagre x86_64 3.17.2-3.fc24 rawhide 697 k zlib x86_64 1.2.8-9.fc24 rawhide 94 k zlib-devel x86_64 1.2.8-9.fc24 rawhide 54 k Removing: kernel x86_64 4.2.0-0.rc5.git2.1.fc24 @System 0 kernel-core x86_64 4.2.0-0.rc5.git2.1.fc24 @System 51 M kernel-modules x86_64 4.2.0-0.rc5.git2.1.fc24 @System 17 M
Transaction Summary ================================================================================ Install 4 Packages Upgrade 168 Packages Remove 3 Packages
Total download size: 350 M Is this ok [y/N]: n Operation aborted.
# dnf update --refresh Adobe Systems Incorporated 13 kB/s | 1.8 kB 00:00 Fedora - Rawhide - Developmental packages for t 1.4 MB/s | 43 MB 00:29 Last metadata expiration check performed 0:00:39 ago on Sat Aug 15 19:22:31 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 72 k kernel-core x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 20 M kernel-modules x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 18 M ncurses-compat-libs x86_64 6.0-1.20150810.fc24 rawhide 305 k Upgrading: NetworkManager x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 2.0 M NetworkManager-adsl x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 110 k NetworkManager-bluetooth x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 133 k NetworkManager-config-connectivity-fedora x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 100 k NetworkManager-glib x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 366 k NetworkManager-libnm x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 476 k NetworkManager-team x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 112 k NetworkManager-wifi x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 140 k NetworkManager-wwan x86_64 1:1.0.6-0.1.20150813git7e2caa2.fc24 rawhide 133 k automake noarch 1.15-5.fc24 rawhide 694 k boost x86_64 1.58.0-6.fc24 rawhide 43 k boost-atomic x86_64 1.58.0-6.fc24 rawhide 45 k boost-chrono x86_64 1.58.0-6.fc24 rawhide 52 k boost-container x86_64 1.58.0-6.fc24 rawhide 66 k boost-context x86_64 1.58.0-6.fc24 rawhide 58 k boost-coroutine x86_64 1.58.0-6.fc24 rawhide 59 k boost-date-time x86_64 1.58.0-6.fc24 rawhide 58 k boost-devel x86_64 1.58.0-6.fc24 rawhide 8.1 M boost-filesystem x86_64 1.58.0-6.fc24 rawhide 73 k boost-graph x86_64 1.58.0-6.fc24 rawhide 137 k boost-iostreams x86_64 1.58.0-6.fc24 rawhide 67 k boost-locale x86_64 1.58.0-6.fc24 rawhide 278 k boost-log x86_64 1.58.0-6.fc24 rawhide 478 k boost-math x86_64 1.58.0-6.fc24 rawhide 312 k boost-program-options x86_64 1.58.0-6.fc24 rawhide 165 k boost-python x86_64 1.58.0-6.fc24 rawhide 133 k boost-random x86_64 1.58.0-6.fc24 rawhide 51 k boost-regex x86_64 1.58.0-6.fc24 rawhide 296 k boost-serialization x86_64 1.58.0-6.fc24 rawhide 156 k boost-signals x86_64 1.58.0-6.fc24 rawhide 70 k boost-system x86_64 1.58.0-6.fc24 rawhide 48 k boost-test x86_64 1.58.0-6.fc24 rawhide 220 k boost-thread x86_64 1.58.0-6.fc24 rawhide 88 k boost-timer x86_64 1.58.0-6.fc24 rawhide 50 k boost-wave x86_64 1.58.0-6.fc24 rawhide 234 k ca-certificates noarch 2015.2.5-2.fc24 rawhide 441 k cmake x86_64 3.3.1-1.fc24 rawhide 7.3 M crontabs noarch 1.11-11.20150630git.fc24 rawhide 23 k cups x86_64 1:2.1-0.3rc1.fc24 rawhide 1.3 M cups-client x86_64 1:2.1-0.3rc1.fc24 rawhide 153 k cups-filesystem noarch 1:2.1-0.3rc1.fc24 rawhide 99 k cups-libs x86_64 1:2.1-0.3rc1.fc24 rawhide 394 k curl x86_64 7.44.0-1.fc24 rawhide 284 k dbus x86_64 1:1.9.20-1.fc24 rawhide 240 k dbus-devel x86_64 1:1.9.20-1.fc24 rawhide 57 k dbus-libs x86_64 1:1.9.20-1.fc24 rawhide 171 k dbus-x11 x86_64 1:1.9.20-1.fc24 rawhide 51 k device-mapper-multipath x86_64 0.4.9-78.fc24 rawhide 119 k device-mapper-multipath-libs x86_64 0.4.9-78.fc24 rawhide 219 k device-mapper-persistent-data x86_64 0.5.5-1.fc24 rawhide 407 k dhcp-client x86_64 12:4.3.3-0.2b1.fc24 rawhide 297 k dhcp-common noarch 12:4.3.3-0.2b1.fc24 rawhide 192 k dhcp-libs x86_64 12:4.3.3-0.2b1.fc24 rawhide 136 k dracut x86_64 043-60.git20150811.fc24 rawhide 322 k dracut-config-rescue x86_64 043-60.git20150811.fc24 rawhide 44 k dracut-network x86_64 043-60.git20150811.fc24 rawhide 82 k firefox x86_64 40.0-4.fc24 rawhide 71 M fontconfig x86_64 2.11.94-3.fc24 rawhide 241 k fontconfig-devel x86_64 2.11.94-3.fc24 rawhide 136 k gnupg2 x86_64 2.1.7-1.fc24 rawhide 1.8 M hplip x86_64 3.15.7-4.fc24 rawhide 12 M hplip-common x86_64 3.15.7-4.fc24 rawhide 96 k hplip-compat-libs x86_64 3.15.7-4.fc24 rawhide 76 k hplip-libs x86_64 3.15.7-4.fc24 rawhide 185 k java-1.8.0-openjdk-headless x86_64 1:1.8.0.60-11.b24.fc24 rawhide 31 M kernel-headers x86_64 4.2.0-0.rc6.git0.2.fc24 rawhide 1.0 M kpartx x86_64 0.4.9-78.fc24 rawhide 61 k libblkid x86_64 2.27-0.3.fc24 rawhide 178 k libcacard x86_64 2:2.4.0-1.fc24 rawhide 74 k libcurl x86_64 7.44.0-1.fc24 rawhide 256 k libcurl-devel x86_64 7.44.0-1.fc24 rawhide 596 k liberation-fonts-common noarch 1:1.07.4-6.fc24 rawhide 31 k liberation-mono-fonts noarch 1:1.07.4-6.fc24 rawhide 232 k liberation-sans-fonts noarch 1:1.07.4-6.fc24 rawhide 284 k liberation-serif-fonts noarch 1:1.07.4-6.fc24 rawhide 304 k libfdisk x86_64 2.27-0.3.fc24 rawhide 219 k libgxps x86_64 0.2.3-1.fc24 rawhide 80 k libmount x86_64 2.27-0.3.fc24 rawhide 195 k libsane-hpaio x86_64 3.15.7-4.fc24 rawhide 112 k libsmartcols x86_64 2.27-0.3.fc24 rawhide 138 k libuuid x86_64 2.27-0.3.fc24 rawhide 78 k ncurses x86_64 6.0-1.20150810.fc24 rawhide 334 k ncurses-base noarch 6.0-1.20150810.fc24 rawhide 75 k ncurses-devel x86_64 6.0-1.20150810.fc24 rawhide 500 k ncurses-libs x86_64 6.0-1.20150810.fc24 rawhide 326 k netpbm x86_64 10.71.02-1.fc24 rawhide 184 k openssh x86_64 7.0p1-1.fc24 rawhide 441 k openssh-askpass x86_64 7.0p1-1.fc24 rawhide 76 k openssh-clients x86_64 7.0p1-1.fc24 rawhide 630 k openssh-server x86_64 7.0p1-1.fc24 rawhide 456 k openssl x86_64 1:1.0.2d-2.fc24 rawhide 510 k openssl-devel x86_64 1:1.0.2d-2.fc24 rawhide 1.5 M openssl-libs x86_64 1:1.0.2d-2.fc24 rawhide 1.2 M pam x86_64 1.2.1-2.fc24 rawhide 729 k policycoreutils x86_64 2.4-9.fc24 rawhide 920 k policycoreutils-python-utils x86_64 2.4-9.fc24 rawhide 212 k policycoreutils-python3 x86_64 2.4-9.fc24 rawhide 1.8 M python-cryptography x86_64 1.0-1.fc24 rawhide 439 k python-idna noarch 2.0-1.fc24 rawhide 96 k python3 x86_64 3.4.3-5.fc24 rawhide 53 k python3-cups x86_64 1.9.72-3.fc24 rawhide 81 k python3-libs x86_64 3.4.3-5.fc24 rawhide 6.7 M qemu-common x86_64 2:2.4.0-1.fc24 rawhide 291 k qemu-guest-agent x86_64 2:2.4.0-1.fc24 rawhide 173 k qemu-img x86_64 2:2.4.0-1.fc24 rawhide 652 k qemu-kvm x86_64 2:2.4.0-1.fc24 rawhide 55 k qemu-system-x86 x86_64 2:2.4.0-1.fc24 rawhide 4.1 M readline x86_64 6.3-7.fc24 rawhide 202 k tzdata noarch 2015f-1.fc24 rawhide 406 k tzdata-java noarch 2015f-1.fc24 rawhide 176 k util-linux x86_64 2.27-0.3.fc24 rawhide 2.1 M Removing: kernel x86_64 4.2.0-0.rc5.git2.1.fc24 @System 0 kernel-core x86_64 4.2.0-0.rc5.git2.1.fc24 @System 51 M kernel-modules x86_64 4.2.0-0.rc5.git2.1.fc24 @System 17 M Skipping packages with broken dependencies: fwupd x86_64 0.1.5-1.fc24 rawhide 112 k gnome-software x86_64 3.17.3-1.fc24 rawhide 1.9 M libappstream-glib x86_64 0.5.0-1.fc24 rawhide 179 k
Transaction Summary ================================================================================ Install 4 Packages Upgrade 111 Packages Remove 3 Packages
Total download size: 211 M Is this ok [y/N]: n Operation aborted.
-
Andreas M. Kirchwitz -
Bob Marcan -
dcw -
Ed Greshko -
Gordon Messmer -
Heinz Diehl -
Jan Zelený -
Javier Perez -
JD -
Joe Zeff -
Martin Cigorraga -
Matthew Miller -
Maurizio Marini -
Michael Schwendt -
Patrick O'Callaghan -
Pete Travis -
Radek Holy -
Rahul Sundaram -
Ralf Corsepius -
Rick Stevens -
Ron Yorston -
Suvayu Ali