8:32 p.m.
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(a)gmail.com
~~~~ Javier Perez
~~~~ While the night runs
~~~~ toward the day...
m m Pepebuho watches
from his high perch.
8:39 p.m.
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(a)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(a)gmail.com
~~~~ Javier Perez
~~~~ While the night runs
~~~~ toward the day...
m m Pepebuho watches
from his high perch.
--
------------------------------
/\_/\
|O O| pepebuho(a)gmail.com
~~~~ Javier Perez
~~~~ While the night runs
~~~~ toward the day...
m m Pepebuho watches
from his high perch.
2 a.m.
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(a)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
2:43 a.m.
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(a)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?
--
Suvayu
Open source is the future. It sets us free.
3:44 a.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(a)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
4:02 a.m.
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(a)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,
--
Suvayu
Open source is the future. It sets us free.
3:01 a.m.
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
3:36 a.m.
On Mon, 20 Jul 2015 10:01:37 +0200
Michael Schwendt <mschwendt(a)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
3:58 a.m.
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(a)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.
10:40 a.m.
----- Original Message -----
From: "Suvayu Ali" <fatkasuvayu+linux(a)gmail.com>
To: users(a)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(a)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.
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
2:36 p.m.
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.
7:10 p.m.
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?
--
Suvayu
Open source is the future. It sets us free.
7:33 p.m.
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(a)fedoraproject.org>
Fedora Project Leader
9:20 p.m.
Suvayu, Matthew, you rock guys, thanks!
On Tue, Jul 21, 2015, 21:33 Matthew Miller <mattdm(a)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(a)fedoraproject.org>
Fedora Project Leader
--
users mailing list
users(a)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
2:26 a.m.
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
12:38 p.m.
On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller <mattdm(a)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
12:52 p.m.
On 07/22/2015 10:38 AM, Maurizio Marini wrote:
On Tue, 21 Jul 2015 20:33:27 -0400
Matthew Miller <mattdm(a)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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- The problem with being poor is that it takes up all of your time -
----------------------------------------------------------------------
12:57 p.m.
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(a)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.
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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Death is nature's way of dropping carrier -
----------------------------------------------------------------------
1:16 p.m.
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?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:30 a.m.
----- Original Message -----
From: "Rick Stevens" <ricks(a)alldigital.com>
To: "Community support for Fedora users" <users(a)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(a)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(a)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(a)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
4:20 a.m.
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
5:35 a.m.
----- Original Message -----
From: "Ed Greshko" <ed.greshko(a)greshko.com>
To: "Community support for Fedora users" <users(a)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 :)
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
10:41 a.m.
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...
11:01 a.m.
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
11:01 a.m.
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,
--
Suvayu
Open source is the future. It sets us free.
11:58 a.m.
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
12:39 p.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?
9:12 p.m.
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
9:21 p.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?
Well.... improving what is not broken :)
1:28 a.m.
----- Original Message -----
From: "Ralf Corsepius" <rc040203(a)freenet.de>
To: users(a)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
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
11:47 p.m.
On 07/23/2015 08:28 AM, Radek Holy wrote:
----- Original Message -----
> From: "Ralf Corsepius" <rc040203(a)freenet.de>
> To: users(a)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
1:20 p.m.
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
2:03 p.m.
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(a)fedoraproject.org>
Fedora Project Leader
2:32 p.m.
Matthew Miller <mattdm(a)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
9:41 p.m.
On 07/22/2015 09:32 PM, Ron Yorston wrote:
Matthew Miller <mattdm(a)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
9:55 p.m.
On 07/22/2015 09:41 PM, Ralf Corsepius wrote:
On 07/22/2015 09:32 PM, Ron Yorston wrote:
> Matthew Miller <mattdm(a)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
5:11 a.m.
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.
1:25 a.m.
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
2:21 a.m.
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
5:22 p.m.
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
Open source is the future. It sets us free.
5:42 p.m.
On Wed, Jul 22, 2015 at 5:22 PM, Suvayu Ali <fatkasuvayu+linux(a)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
6:07 p.m.
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
Open source is the future. It sets us free.
6:52 p.m.
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.
6:57 p.m.
On Jul 22, 2015 6:52 PM, "Gordon Messmer" <gordon.messmer(a)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
7:12 p.m.
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
...
1:32 a.m.
----- Original Message -----
From: "Suvayu Ali" <fatkasuvayu+linux(a)gmail.com>
To: users(a)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
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
2:36 p.m.
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,
--
Suvayu
Open source is the future. It sets us free.
2:01 a.m.
----- Original Message -----
From: "Ron Yorston" <rmy(a)frippery.org>
To: users(a)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(a)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
2:07 a.m.
----- Original Message -----
From: "Radek Holy" <rholy(a)redhat.com>
To: "Community support for Fedora users" <users(a)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(a)frippery.org>
> To: users(a)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(a)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
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
2:13 a.m.
----- Original Message -----
From: "Radek Holy" <rholy(a)redhat.com>
To: "Community support for Fedora users" <users(a)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(a)frippery.org>
> To: users(a)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(a)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
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
9:23 p.m.
Suvayu Ali <fatkasuvayu+linux(a)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
9:38 p.m.
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
2:53 a.m.
On Fri, 7 Aug 2015 22:38:22 -0400
Rahul Sundaram <metherid(a)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
2:43 p.m.
Rahul Sundaram <metherid(a)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
3:02 p.m.
On Thu, Aug 13, 2015 at 07:43:49PM +0000, Andreas M. Kirchwitz wrote:
Rahul Sundaram <metherid(a)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
Open source is the future. It sets us free.
10:05 p.m.
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
5:47 a.m.
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.
5:59 a.m.
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
6:06 a.m.
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.
5:55 a.m.
New subject: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)
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
6:21 a.m.
New subject: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)
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?
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
6:34 a.m.
New subject: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)
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.
7:40 a.m.
New subject: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)
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
12:30 p.m.
New subject: dnf --refresh reverts to older metadata (was: Re: dnf update vs Software Udpates)
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.
4:40 a.m.
On Sat, Aug 08, 2015 at 02:23:34AM +0000, Andreas M. Kirchwitz wrote:
Suvayu Ali <fatkasuvayu+linux(a)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.
--
Suvayu
Open source is the future. It sets us free.
3:49 p.m.
Suvayu Ali <fatkasuvayu+linux(a)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
6:34 p.m.
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
3175
days inactive
3201
days old
70 comments
22 participants
participants (22)
-
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