5:34 p.m.
An update has been running on my system for the last 3-1/2 hours. It
hasn't crashed or died, but it's been very slow. Here are the stats:
$ date; ps u 9145
Sat Sep 12 15:28:49 PDT 2015
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
jonrysh 9145 0.4 0.7 496432 63340 ? S 11:56 0:56
/bin/apper
Everything else is running fine. Good connection to my ISP. Is there
some kind of trouble with the server? Heavy load?
Thanks - jon
6:55 p.m.
Hi all.
I'm new on fedora but not in Linux (More than 15 years using debian) and I
have the same problem.
Of course there are a lot of things going wrong (from my point of view)
that needs to be solved but I can't find the answer. What I need is time.
In Debian there is a tool named apt-spy that finds for the fastest mirrors.
I'd like to know if a such tool does exist on fedora?
Please take note that I have a lot of things trying to understand, again I
need time.
Another thing, please excuse my english; I'm a spanish speaking guy so
please take note of this.
Thanks and regards
​​
2015-09-12 18:26 GMT-04:30 Joe Zeff <joe(a)zeff.us>:
On 09/12/2015 03:34 PM, Jonathan Ryshpan wrote:
> Is there some kind of trouble with the server?
>
Unless we knew just which mirror your system was using there's no way to
tell. You might try using iotop, if it's already installed.
--
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
--
Juan Lavieri
Errar es de humanos, pero es mas humano culpar a los demás.
10:16 p.m.
Found this answer at https://ask.fedoraproject.org :
"dnf includes fastestmirror functionality in standard package (no plugin
needed). You just need to enable it in /etc/dnf/dnf.conf by setting
fastestmirror=1. It is disabled by default (man dnf.conf
<http://linuxmanpages.net/manpages/fedora21/man8/dnf.conf.8.html>).
blaztinn <https://ask.fedoraproject.org/en/users/15986/blaztinn/> (Aug 28
'15)"
Hope that helps.
On Sat, Sep 12, 2015 at 4:55 PM, Juan Lavieri <jlavieri(a)gmail.com> wrote:
Hi all.
I'm new on fedora but not in Linux (More than 15 years using debian) and I
have the same problem.
Of course there are a lot of things going wrong (from my point of view)
that needs to be solved but I can't find the answer. What I need is time.
In Debian there is a tool named apt-spy that finds for the fastest mirrors.
I'd like to know if a such tool does exist on fedora?
Please take note that I have a lot of things trying to understand, again
I need time.
Another thing, please excuse my english; I'm a spanish speaking guy so
please take note of this.
Thanks and regards
​​
2015-09-12 18:26 GMT-04:30 Joe Zeff <joe(a)zeff.us>:
> On 09/12/2015 03:34 PM, Jonathan Ryshpan wrote:
>
>> Is there some kind of trouble with the server?
>>
>
> Unless we knew just which mirror your system was using there's no way to
> tell. You might try using iotop, if it's already installed.
> --
> 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
>
--
Juan Lavieri
Errar es de humanos, pero es mas humano culpar a los demás.
--
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
12:55 a.m.
Just curious: what is the thinking behind setting fastestmirror=0 by default? Is it to get
around the overhead for calculating the fastest mirror each time.
Ranjan
On Sat, 12 Sep 2015 20:16:32 -0700 Kam Leo <kam.leo(a)gmail.com> wrote:
Found this answer at https://ask.fedoraproject.org :
"dnf includes fastestmirror functionality in standard package (no plugin
needed). You just need to enable it in /etc/dnf/dnf.conf by setting
fastestmirror=1. It is disabled by default (man dnf.conf
<http://linuxmanpages.net/manpages/fedora21/man8/dnf.conf.8.html>).
blaztinn <https://ask.fedoraproject.org/en/users/15986/blaztinn/> (Aug 28
'15)"
Hope that helps.
On Sat, Sep 12, 2015 at 4:55 PM, Juan Lavieri <jlavieri(a)gmail.com> wrote:
> Hi all.
>
> I'm new on fedora but not in Linux (More than 15 years using debian) and I
> have the same problem.
>
> Of course there are a lot of things going wrong (from my point of view)
> that needs to be solved but I can't find the answer. What I need is time.
>
> In Debian there is a tool named apt-spy that finds for the fastest mirrors.
>
> I'd like to know if a such tool does exist on fedora?
>
> Please take note that I have a lot of things trying to understand, again
> I need time.
>
> Another thing, please excuse my english; I'm a spanish speaking guy so
> please take note of this.
>
> Thanks and regards
>
> ​​
>
> 2015-09-12 18:26 GMT-04:30 Joe Zeff <joe(a)zeff.us>:
>
>> On 09/12/2015 03:34 PM, Jonathan Ryshpan wrote:
>>
>>> Is there some kind of trouble with the server?
>>>
>>
>> Unless we knew just which mirror your system was using there's no way to
>> tell. You might try using iotop, if it's already installed.
>> --
>> 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
>>
>
>
>
> --
>
> Juan Lavieri
>
> Errar es de humanos, pero es mas humano culpar a los demás.
>
> --
> 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
>
>
--
Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt.
Please respond to the mailing list if appropriate. For those needing to send personal or
professional e-mail, please use appropriate addresses.
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
8:18 a.m.
On Sun, Sep 13, 2015 at 12:55:36AM -0500, Ranjan Maitra wrote:
Just curious: what is the thinking behind setting fastestmirror=0 by
default? Is it to get around the overhead for calculating the fastest mirror each time.
Historicall, when it was available with yum, fastestmirror was the
source of some other related problems.
--
Suvayu
Open source is the future. It sets us free.
11:14 p.m.
On 13 September 2015 at 07:55, Ranjan Maitra <maitra.mbox.ignored(a)inbox.com>
wrote:
Just curious: what is the thinking behind setting fastestmirror=0 by
default? Is it to get around the overhead for calculating the fastest
mirror each time.
Ranjan
Have a look at: https://bugzilla.redhat.com/show_bug.cgi?id=1051554
--
Ahmad Samir
2:12 a.m.
On 09/13/15 11:16, Kam Leo wrote:
"dnf includes fastestmirror functionality in standard package
(no plugin needed). You just need to enable it in |/etc/dnf/dnf.conf| by setting
|fastestmirror=1|. It is disabled by default (man dnf.conf
<http://linuxmanpages.net/manpages/fedora21/man8/dnf.conf.8.html>).
I think a little reflection is necessary.
The OP mentioned the process running on his system to be /bin/apper. This is a KDE
interface to PackageKit. AFAIK, it doesn't use the configuration information of dnf.
--
It seems most people that say they are "done talking about it" never really are
until given the last word.
9:07 a.m.
New subject: What is broken with software update?
I'm getting to the point where I never want to use the graphical
software update facility, since it is ALWAYS wrong.
I just logged in, pulled up software update, and knowing that it
routinely messes up and says that there is nothing to update, I asked
it to recheck for updates. It came back again with no updates.
Then (since I'm developing a deep distrust of software update), I did a
CLI dnf update. There were 27 updates pending. Clearly, software
update is broken.
Its possible that it is configured out-of-the-box wrong. Is there
anything that I can set to make it actually work, or should I just stop
using it because it is too broken to fix?
Example where software update has totally failed:
[prodadm@production ~]$ sudo dnf update
[sudo] password for prodadm:
Fedora 22 - x86_64 - Updates 2.3 MB/s | 14 MB
00:06
Last metadata expiration check performed 0:00:14 ago on Sun Sep 13
09:55:47 2015.
Dependencies resolved.
=======================================================================
=========
Package Arch Version
Repository
Size
=======================================================================
=========
Upgrading:
epson-inkjet-printer-escpr x86_64 1.5.0-1.1lsb3.2.fc22 updates
2.0 M
libxml2 i686 2.9.2-4.fc22 updates
684 k
libxml2 x86_64 2.9.2-4.fc22 updates
677 k
libxml2-devel x86_64 2.9.2-4.fc22 updates
1.1 M
libxml2-python x86_64 2.9.2-4.fc22 updates
248 k
mesa-dri-drivers i686 10.6.3-2.20150729.fc22 updates
8.5 M
mesa-dri-drivers x86_64 10.6.3-2.20150729.fc22 updates
8.2 M
mesa-filesystem i686 10.6.3-2.20150729.fc22 updates
35 k
mesa-filesystem x86_64 10.6.3-2.20150729.fc22 updates
35 k
mesa-libEGL i686 10.6.3-2.20150729.fc22 updates
97 k
mesa-libEGL x86_64 10.6.3-2.20150729.fc22 updates
96 k
mesa-libEGL-devel i686 10.6.3-2.20150729.fc22 updates
40 k
mesa-libEGL-devel x86_64 10.6.3-2.20150729.fc22 updates
40 k
mesa-libGL i686 10.6.3-2.20150729.fc22 updates
213 k
mesa-libGL x86_64 10.6.3-2.20150729.fc22 updates
191 k
mesa-libGL-devel x86_64 10.6.3-2.20150729.fc22 updates
160 k
mesa-libGLES x86_64 10.6.3-2.20150729.fc22 updates
41 k
mesa-libOSMesa i686 10.6.3-2.20150729.fc22 updates
1.3 M
mesa-libOSMesa x86_64 10.6.3-2.20150729.fc22 updates
1.2 M
mesa-libgbm i686 10.6.3-2.20150729.fc22 updates
55 k
mesa-libgbm x86_64 10.6.3-2.20150729.fc22 updates
55 k
mesa-libgbm-devel x86_64 10.6.3-2.20150729.fc22 updates
28 k
mesa-libglapi i686 10.6.3-2.20150729.fc22 updates
70 k
mesa-libglapi x86_64 10.6.3-2.20150729.fc22 updates
52 k
mesa-libwayland-egl x86_64 10.6.3-2.20150729.fc22 updates
37 k
mesa-libwayland-egl-devel x86_64 10.6.3-2.20150729.fc22 updates
25 k
mesa-libxatracker x86_64 10.6.3-2.20150729.fc22 updates
1.2 M
Transaction Summary
=======================================================================
=========
Upgrade 27 Packages
Total download size: 26 M
Is this ok [y/N]:
9:33 a.m.
New subject: What is broken with software update?
what graphical interface are you using? I NORMALLY use CLI & dnf update,
but sometimes if I want to look for a package I use the graphical
interface:
$ yumex-dnf
I HATE using it. even if I have just done a $ dnf update, it takes
FOREVER to refresh the Repository Metadata... FOREVER...
after a google search I see there is a bugzilla bug for this issue..
https://bugzilla.redhat.com/show_bug.cgi?id=1220776
09/13/2015 10:07 AM, John Mellor wrote:
I'm getting to the point where I never want to use the graphical
software update facility, since it is ALWAYS wrong.
I just logged in, pulled up software update, and knowing that it
routinely messes up and says that there is nothing to update, I asked
it to recheck for updates. It came back again with no updates.
Then (since I'm developing a deep distrust of software update), I did a
CLI dnf update. There were 27 updates pending. Clearly, software
update is broken.
Its possible that it is configured out-of-the-box wrong. Is there
anything that I can set to make it actually work, or should I just stop
using it because it is too broken to fix?
Example where software update has totally failed:
[prodadm@production ~]$ sudo dnf update
[sudo] password for prodadm:
Fedora 22 - x86_64 - Updates 2.3 MB/s | 14 MB
00:06
Last metadata expiration check performed 0:00:14 ago on Sun Sep 13
09:55:47 2015.
Dependencies resolved.
=======================================================================
=========
Package Arch Version
Repository
Size
=======================================================================
=========
Upgrading:
epson-inkjet-printer-escpr x86_64 1.5.0-1.1lsb3.2.fc22 updates
2.0 M
libxml2 i686 2.9.2-4.fc22 updates
684 k
libxml2 x86_64 2.9.2-4.fc22 updates
677 k
libxml2-devel x86_64 2.9.2-4.fc22 updates
1.1 M
libxml2-python x86_64 2.9.2-4.fc22 updates
248 k
mesa-dri-drivers i686 10.6.3-2.20150729.fc22 updates
8.5 M
mesa-dri-drivers x86_64 10.6.3-2.20150729.fc22 updates
8.2 M
mesa-filesystem i686 10.6.3-2.20150729.fc22 updates
35 k
mesa-filesystem x86_64 10.6.3-2.20150729.fc22 updates
35 k
mesa-libEGL i686 10.6.3-2.20150729.fc22 updates
97 k
mesa-libEGL x86_64 10.6.3-2.20150729.fc22 updates
96 k
mesa-libEGL-devel i686 10.6.3-2.20150729.fc22 updates
40 k
mesa-libEGL-devel x86_64 10.6.3-2.20150729.fc22 updates
40 k
mesa-libGL i686 10.6.3-2.20150729.fc22 updates
213 k
mesa-libGL x86_64 10.6.3-2.20150729.fc22 updates
191 k
mesa-libGL-devel x86_64 10.6.3-2.20150729.fc22 updates
160 k
mesa-libGLES x86_64 10.6.3-2.20150729.fc22 updates
41 k
mesa-libOSMesa i686 10.6.3-2.20150729.fc22 updates
1.3 M
mesa-libOSMesa x86_64 10.6.3-2.20150729.fc22 updates
1.2 M
mesa-libgbm i686 10.6.3-2.20150729.fc22 updates
55 k
mesa-libgbm x86_64 10.6.3-2.20150729.fc22 updates
55 k
mesa-libgbm-devel x86_64 10.6.3-2.20150729.fc22 updates
28 k
mesa-libglapi i686 10.6.3-2.20150729.fc22 updates
70 k
mesa-libglapi x86_64 10.6.3-2.20150729.fc22 updates
52 k
mesa-libwayland-egl x86_64 10.6.3-2.20150729.fc22 updates
37 k
mesa-libwayland-egl-devel x86_64 10.6.3-2.20150729.fc22 updates
25 k
mesa-libxatracker x86_64 10.6.3-2.20150729.fc22 updates
1.2 M
Transaction Summary
=======================================================================
=========
Upgrade 27 Packages
Total download size: 26 M
Is this ok [y/N]:
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
11:19 a.m.
New subject: What is broken with software update?
I'm not using yumes-dnf. I'm having the problems with the GUI Gnome
software center application, whatever that is called.
On Sun, 2015-09-13 at 10:33 -0400, Paul Cartwright wrote:
what graphical interface are you using? I NORMALLY use CLI & dnf
update,
but sometimes if I want to look for a package I use the graphical
interface:
$ yumex-dnf
I HATE using it. even if I have just done a $ dnf update, it takes
FOREVER to refresh the Repository Metadata... FOREVER...
after a google search I see there is a bugzilla bug for this issue..
https://bugzilla.redhat.com/show_bug.cgi?id=1220776
09/13/2015 10:07 AM, John Mellor wrote:
> I'm getting to the point where I never want to use the graphical
> software update facility, since it is ALWAYS wrong.
>
> I just logged in, pulled up software update, and knowing that it
> routinely messes up and says that there is nothing to update, I
> asked
> it to recheck for updates. It came back again with no updates.
>
> Then (since I'm developing a deep distrust of software update), I
> did a
> CLI dnf update. There were 27 updates pending. Clearly, software
> update is broken.
>
> Its possible that it is configured out-of-the-box wrong. Is there
> anything that I can set to make it actually work, or should I just
> stop
> using it because it is too broken to fix?
>
> Example where software update has totally failed:
>
> [prodadm@production ~]$ sudo dnf update
> [sudo] password for prodadm:
> Fedora 22 - x86_64 - Updates 2.3 MB/s | 14 MB
>
> 00:06
> Last metadata expiration check performed 0:00:14 ago on Sun Sep 13
> 09:55:47 2015.
> Dependencies resolved.
> ===================================================================
> ====
> =========
> Package Arch Version
> Repository
>
>
> Size
> ===================================================================
> ====
> =========
> Upgrading:
> epson-inkjet-printer-escpr x86_64 1.5.0-1.1lsb3.2.fc22
> updates
> 2.0 M
> libxml2 i686 2.9.2-4.fc22
> updates
> 684 k
> libxml2 x86_64 2.9.2-4.fc22
> updates
> 677 k
> libxml2-devel x86_64 2.9.2-4.fc22
> updates
> 1.1 M
> libxml2-python x86_64 2.9.2-4.fc22
> updates
> 248 k
> mesa-dri-drivers i686 10.6.3-2.20150729.fc22
> updates
> 8.5 M
> mesa-dri-drivers x86_64 10.6.3-2.20150729.fc22
> updates
> 8.2 M
> mesa-filesystem i686 10.6.3-2.20150729.fc22
> updates
> 35 k
> mesa-filesystem x86_64 10.6.3-2.20150729.fc22
> updates
> 35 k
> mesa-libEGL i686 10.6.3-2.20150729.fc22
> updates
> 97 k
> mesa-libEGL x86_64 10.6.3-2.20150729.fc22
> updates
> 96 k
> mesa-libEGL-devel i686 10.6.3-2.20150729.fc22
> updates
> 40 k
> mesa-libEGL-devel x86_64 10.6.3-2.20150729.fc22
> updates
> 40 k
> mesa-libGL i686 10.6.3-2.20150729.fc22
> updates
> 213 k
> mesa-libGL x86_64 10.6.3-2.20150729.fc22
> updates
> 191 k
> mesa-libGL-devel x86_64 10.6.3-2.20150729.fc22
> updates
> 160 k
> mesa-libGLES x86_64 10.6.3-2.20150729.fc22
> updates
> 41 k
> mesa-libOSMesa i686 10.6.3-2.20150729.fc22
> updates
> 1.3 M
> mesa-libOSMesa x86_64 10.6.3-2.20150729.fc22
> updates
> 1.2 M
> mesa-libgbm i686 10.6.3-2.20150729.fc22
> updates
> 55 k
> mesa-libgbm x86_64 10.6.3-2.20150729.fc22
> updates
> 55 k
> mesa-libgbm-devel x86_64 10.6.3-2.20150729.fc22
> updates
> 28 k
> mesa-libglapi i686 10.6.3-2.20150729.fc22
> updates
> 70 k
> mesa-libglapi x86_64 10.6.3-2.20150729.fc22
> updates
> 52 k
> mesa-libwayland-egl x86_64 10.6.3-2.20150729.fc22
> updates
> 37 k
> mesa-libwayland-egl-devel x86_64 10.6.3-2.20150729.fc22
> updates
> 25 k
> mesa-libxatracker x86_64 10.6.3-2.20150729.fc22
> updates
> 1.2 M
>
> Transaction Summary
> ===================================================================
> ====
> =========
> Upgrade 27 Packages
>
> Total download size: 26 M
> Is this ok [y/N]:
>
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
11:36 a.m.
New subject: What is broken with software update?
On Sun, 2015-09-13 at 10:07 -0400, John Mellor wrote:
I'm getting to the point where I never want to use the graphical
software update facility, since it is ALWAYS wrong.
I just logged in, pulled up software update, and knowing that it
routinely messes up and says that there is nothing to update, I asked
it to recheck for updates. It came back again with no updates.
Then (since I'm developing a deep distrust of software update), I did
a
CLI dnf update. There were 27 updates pending. Clearly, software
update is broken.
Its possible that it is configured out-of-the-box wrong. Is there
anything that I can set to make it actually work, or should I just
stop
using it because it is too broken to fix?
Example where software update has totally failed:
[prodadm@production ~]$ sudo dnf update
[sudo] password for prodadm:
Fedora 22 - x86_64 - Updates 2.3 MB/s | 14 MB
00:06
Last metadata expiration check performed 0:00:14 ago on Sun Sep 13
09:55:47 2015.
Dependencies resolved.
=====================================================================
==
=========
Package Arch Version
Repository
Size
=====================================================================
==
=========
Upgrading:
epson-inkjet-printer-escpr x86_64 1.5.0-1.1lsb3.2.fc22
updates
2.0 M
libxml2 i686 2.9.2-4.fc22
updates
684 k
libxml2 x86_64 2.9.2-4.fc22
updates
677 k
libxml2-devel x86_64 2.9.2-4.fc22
updates
1.1 M
libxml2-python x86_64 2.9.2-4.fc22
updates
248 k
mesa-dri-drivers i686 10.6.3-2.20150729.fc22
updates
8.5 M
mesa-dri-drivers x86_64 10.6.3-2.20150729.fc22
updates
8.2 M
mesa-filesystem i686 10.6.3-2.20150729.fc22
updates
35 k
mesa-filesystem x86_64 10.6.3-2.20150729.fc22
updates
35 k
mesa-libEGL i686 10.6.3-2.20150729.fc22
updates
97 k
mesa-libEGL x86_64 10.6.3-2.20150729.fc22
updates
96 k
mesa-libEGL-devel i686 10.6.3-2.20150729.fc22
updates
40 k
mesa-libEGL-devel x86_64 10.6.3-2.20150729.fc22
updates
40 k
mesa-libGL i686 10.6.3-2.20150729.fc22
updates
213 k
mesa-libGL x86_64 10.6.3-2.20150729.fc22
updates
191 k
mesa-libGL-devel x86_64 10.6.3-2.20150729.fc22
updates
160 k
mesa-libGLES x86_64 10.6.3-2.20150729.fc22
updates
41 k
mesa-libOSMesa i686 10.6.3-2.20150729.fc22
updates
1.3 M
mesa-libOSMesa x86_64 10.6.3-2.20150729.fc22
updates
1.2 M
mesa-libgbm i686 10.6.3-2.20150729.fc22
updates
55 k
mesa-libgbm x86_64 10.6.3-2.20150729.fc22
updates
55 k
mesa-libgbm-devel x86_64 10.6.3-2.20150729.fc22
updates
28 k
mesa-libglapi i686 10.6.3-2.20150729.fc22
updates
70 k
mesa-libglapi x86_64 10.6.3-2.20150729.fc22
updates
52 k
mesa-libwayland-egl x86_64 10.6.3-2.20150729.fc22
updates
37 k
mesa-libwayland-egl-devel x86_64 10.6.3-2.20150729.fc22
updates
25 k
mesa-libxatracker x86_64 10.6.3-2.20150729.fc22
updates
1.2 M
Transaction Summary
=====================================================================
==
=========
Upgrade 27 Packages
Total download size: 26 M
Is this ok [y/N]:
It looks like Gnome bug 739666 (
https://bugzilla.gnome.org/show_bug.cgi?id=739666) describes the
problem, and its been around since last November. However, nobody is
working on it. Gnome Bugzilla seems to be missing the required actions
. How do you get it confirmed and dramatically raised up in priority?
8:36 p.m.
New subject: What is broken with software update?
On 09/13/2015 07:07 AM, John Mellor wrote:
Then (since I'm developing a deep distrust of software update), I
did a
CLI dnf update. There were 27 updates pending. Clearly, software
update is broken.
Nothing is clearly broken.
yum/dnf repositories are not synchronized. No mechanism nor mandate
exists for keeping them in sync. This has been discussed to death on
this list, but no example has been provided that can't be explained
simply as "dnf checked a repository with older data and then, later,
checked a different repository with data that is more up to date."
That's the way distributed mirror systems work, and it's nothing to
worry about. You *will* get updates, when the mirrors pull data.
If you're concerned about getting updates immediately, don't rely on dnf
at all. Subscribe to the RSS feed:
http://fedoraplanet.org/infofeed/
There's a perfectly good, centralized source of information about
updates available to everyone.
8:44 p.m.
New subject: What is broken with software update?
On Sun, 2015-09-13 at 18:36 -0700, Gordon Messmer wrote:
On 09/13/2015 07:07 AM, John Mellor wrote:
> Then (since I'm developing a deep distrust of software update), I
> did a
> CLI dnf update. There were 27 updates pending. Clearly, software
> update is broken.
Nothing is clearly broken.
yum/dnf repositories are not synchronized. No mechanism nor mandate
exists for keeping them in sync. This has been discussed to death on
this list, but no example has been provided that can't be explained
simply as "dnf checked a repository with older data and then, later,
checked a different repository with data that is more up to date."
That's the way distributed mirror systems work, and it's nothing to
worry about. You *will* get updates, when the mirrors pull data.
If you're concerned about getting updates immediately, don't rely on
dnf
at all. Subscribe to the RSS feed:
http://fedoraplanet.org/infofeed/
There's a perfectly good, centralized source of information about
updates available to everyone.
Gordon stated:
Nothing is clearly broken.
Ok, its remotely possible. My recalled experience has been that the
Gnome updater is not finding even 5-day-old updates, but assuming that
some weird preferred repo out there is totally broken, I'm willing to
test that thesis.
I checked the dnf log and dnf is configured to select some
indeterminate Fedora mirrors site. I'm willing to bet that the
unselected mirrors are no more than a couple of hours out-of-date at
worst, and there is actually a software error at work here. So, how to
I preconfigure my system to get the two updaters to select the same
repo?
P.S, just out of curiosity, why is the software updater not sharing the
same dnf and yum metadata backend that clearly works better?
12:46 p.m.
New subject: What is broken with software update?
On 09/15/2015 06:44 PM, John Mellor wrote:
I checked the dnf log and dnf is configured to select some
indeterminate Fedora mirrors site. I'm willing to bet that the
unselected mirrors are no more than a couple of hours out-of-date at
worst, and there is actually a software error at work here. So, how to
I preconfigure my system to get the two updaters to select the same
repo?
Pick a mirror for each of your enabled repositories, edit the files
under /etc/yum.repos.d, disable metalink and enable baseurl with your
preferred mirror.
P.S, just out of curiosity, why is the software updater not sharing
the
same dnf and yum metadata backend that clearly works better?
It does use the same backend. It keeps a separate copy of the metadata,
though. Never was sure why; I thought that's what packagekitd was *for*.
7:33 p.m.
New subject: What is broken with software update?
On Wed, 2015-09-16 at 10:46 -0700, Gordon Messmer wrote:
On 09/15/2015 06:44 PM, John Mellor wrote:
> I checked the dnf log and dnf is configured to select some
> indeterminate Fedora mirrors site. I'm willing to bet that the
> unselected mirrors are no more than a couple of hours out-of-date
> at
> worst, and there is actually a software error at work here. So,
> how to
> I preconfigure my system to get the two updaters to select the same
> repo?
Pick a mirror for each of your enabled repositories, edit the files
under /etc/yum.repos.d, disable metalink and enable baseurl with your
preferred mirror.
> P.S, just out of curiosity, why is the software updater not sharing
> the
> same dnf and yum metadata backend that clearly works better?
It does use the same backend. It keeps a separate copy of the
metadata,
though. Never was sure why; I thought that's what packagekitd was
*for*.
Interesting test. Forcing both to use the same repo results in the
same data. The metadata separation problem seems to explain the
observed issue nicely.
3:33 a.m.
New subject: What is broken with software update?
On 16 September 2015 at 18:46, Gordon Messmer <gordon.messmer(a)gmail.com> wrote:
Never was sure why; I thought that's what packagekitd was *for*.
PackageKit needs to offer clients results with guaranteed latencies;
it's no good if the command-not-found handler takes 700ms to return
results, or gnome-software takes 15 seconds to show the first overview
screen. This is why some of the fancier stuff was turned off with the
yum backend. The problem with sharing a cache is that PackageKit
downloads an entire set of repository files at the same time, all
coherent to each other. It then atomically swaps the link in the cache
so that at any time you can query PackageKit for results and get
something sane in a small amount of time.
What dnf does, and yum did, is download only the files that it needs.
This is great for command line use where you might just want to check
for updates, but means that we have metadata from different
repositories with different ages, and most importantly different
metadata files in the same repo with different ages (repo files
reference each other internally). This means using dnf that you can do
something like a search with no additional downloads, but when you
come to install something it could be that half way through the
depsolve it works out that the filelists isn't new enough and starts
downloading a new metadata file, so it can re-depsolve and continue on
to install.
PackageKit can't do this, as we only promise network access during
certain method calls, and we have strict latency requirements for some
requests, where downloading at random points would shatter both
promises.
If PK and DNF could agree to download all metadata at a set time for
all repositories and do an atomic switch that would be great, and we
could certainly share a cache. Until then, it makes sense to have
separate locations.
What we can fix is downloading the same file twice in some cases, and
in that case either squid helps, or CAShe can fix that in the longer
term.
Richard.
6:47 a.m.
New subject: What is broken with software update?
On Tue, 15 Sep 2015 21:44:39 -0400, John Mellor wrote:
My recalled experience has been that the
Gnome updater is not finding even 5-day-old updates, but assuming that
some weird preferred repo out there is totally broken, I'm willing to
test that thesis.
A fundamental problem is that everything is focused on the master repo
only, which is not supposed to be the primary place from where to download
the updates. Announcements of updates are sent as soon as stuff has been
published in the master repo. Update system ticket state details reflect
whether an update has been published in that repo, but _not_ whether it is
available to everyone via the world-wide mirrors.
You read about an update, but the package updater tools don't "see" the
update yet, because they examine nearby mirrors and may only get access to
older repo contents that way. It can take hours (or days even) for mirrors
to sync with the master repo *and* end up in a usable state (i.e. not
cause 404 Not Found errors for packages that have not been mirrored yet,
for example).
https://fedorahosted.org/fedora-infrastructure/ticket/4866
is only the tip of the iceberg. The burden of choosing a mirror from the
list of advertised mirrors has been put onto the shoulders of the
developers of repo metadata downloaders. They need to decide themselves
whether to do "expensive" mirror crawling, for example, in search of a
nearby mirror that is up-to-date, complete and usable, too.
8:06 a.m.
Jonathan Ryshpan wrote:
An update has been running on my system for the last 3-1/2 hours.
It
hasn't crashed or died, but it's been very slo
If it's the apper update transaction, you can run in a terminal:
pkmon
to observe the status of the PackageKit daemon, could give a clue what it is
doing.
-- rex
3142
days inactive
3153
days old
19 comments
14 participants
participants (14)
-
Ahmad Samir -
Ed Greshko -
Gordon Messmer -
Joe Zeff -
John Mellor -
Jonathan Ryshpan -
Juan Lavieri -
Kam Leo -
Michael Schwendt -
Paul Cartwright -
Ranjan Maitra -
Rex Dieter -
Richard Hughes -
Suvayu Ali