1:32 p.m.
Hi, everyone,
I have been trying to upgrade my system from f24 to f25 using
the cli in the terminal.
814 dnf system-upgrade download --releasever=25
815 dnf system-upgrade download --releasever=25 --allowerasing
816 dnf system-upgrade download --releasever=25 --allowerasing --
nogpgcheck
all run from superuser.
error:
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/bin from install of google-earth-stable-6.0.3.2197-0.x86_64
conflicts with file from package filesystem-3.2-37.fc24.x86_64
# dnf --system-upgrade reboot
will not run due to same error.
I have obtained the google key and installed it using pgp install, but
no change. Here are some of the other things I have tried:
dnf distrosync
dnf help
dnf upgrade google_Earth
dnf upgrade google-earth
dnf system-upgrade --nogpgcheck reboot
dnf erase googleearth
The erase google earth I have tried also with the full name
dnf erase google-earth-stable-6.0.3.2197-0.x86_64
No match for argument: google-earth-stable-6.0.3.2197-0.x86_64
Error: No packages marked for removal.
Given that I cannot erase the offending package, I tried:
dnf system-upgrade reboot --allowerasing
Error: system is not ready for upgrade
Yet again with nogpgcheck
dnf system-upgrade reboot --nogpgcheck
Error: system is not ready for upgrade
A straight reboot will bring the system back to f24. But no upgrade.
A bugzilla check was no less frustrating with no help for the issue.
Any ideas out there?
Regards,
Les H
1:41 p.m.
On Thu, 2016-12-01 at 11:32 -0800, Howard Howell wrote:
Hi, everyone,
I have been trying to upgrade my system from f24 to f25 using
the cli in the terminal.
814 dnf system-upgrade download --releasever=25
815 dnf system-upgrade download --releasever=25 --allowerasing
816 dnf system-upgrade download --releasever=25 --allowerasing --
nogpgcheck
all run from superuser.
error:
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/bin from install of google-earth-stable-6.0.3.2197-0.x86_64
conflicts with file from package filesystem-3.2-37.fc24.x86_64
# dnf --system-upgrade reboot
will not run due to same error.
I have obtained the google key and installed it using pgp install, but
no change. Here are some of the other things I have tried:
dnf distrosync
dnf help
dnf upgrade google_Earth
dnf upgrade google-earth
dnf system-upgrade --nogpgcheck reboot
dnf erase googleearth
The erase google earth I have tried also with the full name
dnf erase google-earth-stable-6.0.3.2197-0.x86_64
No match for argument: google-earth-stable-6.0.3.2197-0.x86_64
Error: No packages marked for removal.
Given that I cannot erase the offending package, I tried:
dnf system-upgrade reboot --allowerasing
Error: system is not ready for upgrade
Yet again with nogpgcheck
dnf system-upgrade reboot --nogpgcheck
Error: system is not ready for upgrade
A straight reboot will bring the system back to f24. But no upgrade.
A bugzilla check was no less frustrating with no help for the issue.
Any ideas out there?
Well, that Google Earth package is clearly bad. There's no reason it
should own /usr/bin . It looks like the problem is that it sets a
different mode on it than the `filesystem` package does, which dnf/rpm
will see as a conflict: two packages can contain the same file or
directory without conflict only so long as the file or directory is
identical and has identical properties in both. If they diverge at all,
it becomes a package conflict.
The obvious thing you can do for now is simply remove the google-earth
package; after that the upgrade should work fine. You can then look at
ways to reinstall Google Earth on the upgraded system.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:05 p.m.
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 11:41:23 -0800
On Thu, 2016-12-01 at 11:32 -0800, Howard Howell wrote:
Hi, everyone,
I have been trying to upgrade my system from f24 to f25 using
the cli in the terminal.
814 dnf system-upgrade download --releasever=25
815 dnf system-upgrade download --releasever=25 --allowerasing
816 dnf system-upgrade download --releasever=25 --allowerasing --
nogpgcheck
all run from superuser.
error:
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/bin from install of google-earth-stable-6.0.3.2197-
0.x86_64
conflicts with file from package filesystem-3.2-37.fc24.x86_64
# dnf --system-upgrade reboot
will not run due to same error.
I have obtained the google key and installed it using pgp install,
but
no change. Here are some of the other things I have tried:
dnf distrosync
dnf help
dnf upgrade google_Earth
dnf upgrade google-earth
dnf system-upgrade --nogpgcheck reboot
dnf erase googleearth
The erase google earth I have tried also with the full name
dnf erase google-earth-stable-6.0.3.2197-0.x86_64
No match for argument: google-earth-stable-6.0.3.2197-0.x86_64
Error: No packages marked for removal.
Given that I cannot erase the offending package, I tried:
dnf system-upgrade reboot --allowerasing
Error: system is not ready for upgrade
Yet again with nogpgcheck
dnf system-upgrade reboot --nogpgcheck
Error: system is not ready for upgrade
A straight reboot will bring the system back to f24. But no upgrade.
A bugzilla check was no less frustrating with no help for the issue.
Any ideas out there?
Well, that Google Earth package is clearly bad. There's no reason it
should own /usr/bin . It looks like the problem is that it sets a
different mode on it than the `filesystem` package does, which dnf/rpm
will see as a conflict: two packages can contain the same file or
directory without conflict only so long as the file or directory is
identical and has identical properties in both. If they diverge at all,
it becomes a package conflict.
The obvious thing you can do for now is simply remove the google-earth
package; after that the upgrade should work fine. You can then look at
ways to reinstall Google Earth on the upgraded system.
Since the dnf erase command doesn't work, or tries to remove over 211M
of files, do you mean just to remove the directory tree for the
offending package using the rm command?
Regards,
Les H
2:11 p.m.
On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
Since the dnf erase command doesn't work, or tries to remove over 211M
of files, do you mean just to remove the directory tree for the
offending package using the rm command?
Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a pretty
big app. What exactly is the output from 'dnf remove google-earth'?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:15 p.m.
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:11:29 -0800
On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
Since the dnf erase command doesn't work, or tries to remove over
211M
of files, do you mean just to remove the directory tree for the
offending package using the rm command?
Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a pretty
big app. What exactly is the output from 'dnf remove google-earth'?
Dependencies resolved.
=======================================================================
=========
Package Arch Version Repository
Size
=======================================================================
=========
Removing:
esmtp x86_64 1.2-
4.fc24 @updates 97 k
google-earth-stable x86_64 7.1.7.2606-
0 @@commandline 189 M
liblockfile x86_64 1.09-
4.fc24 @fedora 44 k
libpng12 x86_64 1.2.56-
2.fc24 @fedora 442 k
mailx x86_64 12.5-
19.fc24 @fedora 479 k
ncurses-compat-libs x86_64 6.0-
6.20160709.fc24 @updates 946 k
patch x86_64 2.7.5-
3.fc24 @fedora 231 k
perl-Algorithm-Diff noarch 1.1903-
4.fc24 @fedora 108 k
perl-Archive-Tar noarch 2.06-
2.fc24 @updates 149 k
perl-Archive-Zip noarch 1.58-
1.fc24 @updates 252 k
perl-B-Lint noarch 1.20-
6.fc24 @fedora 30 k
perl-CGI noarch 4.28-
2.fc24 @fedora 533 k
perl-CPAN noarch 2.11-
349.fc24 (a)fedora 1.7 M
perl-Class-ISA noarch 0.36-
1017.fc24 @fedora 13 k
perl-Compress-Bzip2 x86_64 2.25-
1.fc24 @updates 142 k
perl-Data-Section noarch 0.200006-
6.fc24 @fedora 40 k
perl-Devel-Size x86_64 0.80-
4.fc24 @fedora 78 k
perl-Env noarch 1.04-
347.fc24 @fedora 26 k
perl-ExtUtils-CBuilder noarch 1:0.280224-
2.fc24 @fedora 96 k
perl-ExtUtils-MM-Utils noarch 7.10-
5.fc24 (a)updates 3.1 k
perl-File-CheckTree noarch 4.42-
296.fc24 @fedora 28 k
perl-IO-Zlib noarch 1:1.10-
364.fc24 @updates 19 k
perl-IPC-Cmd noarch 1:0.96-
1.fc24 @updates 83 k
perl-IPC-System-Simple noarch 1.25-
8.fc24 @fedora 69 k
perl-Locale-Codes noarch 3.40-
1.fc24 (a)updates 2.2 M
perl-Locale-Maketext noarch 1.26-
349.fc24 @updates 166 k
perl-Locale-Maketext-Simple noarch 1:0.21-
364.fc24 @updates 14 k
perl-MRO-Compat noarch 0.12-
10.fc24 @fedora 26 k
perl-Module-Build noarch 2:0.42.18-
1.fc24 @fedora 654 k
perl-Module-CoreList noarch 1:5.20161020-
1.fc24 @updates 719 k
perl-Module-Load-Conditional noarch 0.68-
1.fc24 @updates 29 k
perl-Module-Metadata noarch 1.000027-
4.fc24 @fedora 61 k
perl-Net-Ping noarch 2.43-
364.fc24 @updates 67 k
perl-Params-Check noarch 1:0.38-
347.fc24 @fedora 28 k
perl-Perl-OSType noarch 1.009-
2.fc24 @fedora 33 k
perl-Pod-Checker noarch 4:1.71-
6.fc24 @fedora 45 k
perl-Pod-Html noarch 1.22-
364.fc24 @updates 36 k
perl-Pod-LaTeX noarch 0.61-
297.fc24 @fedora 84 k
perl-Pod-Parser noarch 1.63-
348.fc24 @fedora 263 k
perl-Pod-Plainer noarch 1.04-
2.fc24 (a)fedora 5.1 k
perl-Software-License noarch 0.103012-
1.fc24 @fedora 417 k
perl-Sys-Syslog x86_64 0.35-
1.fc24 @updates 95 k
perl-Test-Simple noarch 1.001014-
347.fc24 @fedora 448 k
perl-Text-Diff noarch 1.44-
1.fc24 @fedora 83 k
perl-Text-Glob noarch 0.09-
15.fc24 (a)fedora 7.8 k
perl-Text-Soundex x86_64 3.05-
2.fc24 @fedora 47 k
perl-Text-Template noarch 1.46-
4.fc24 @fedora 122 k
perl-autodie noarch 2.29-
2.fc24 @fedora 211 k
perl-inc-latest noarch 2:0.500-
4.fc24 @fedora 35 k
perl-local-lib noarch 2.000018-
2.fc24 @fedora 115 k
qt3 x86_64 3.3.8b-
67.fc24 @fedora 11 M
redhat-lsb x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-core x86_64 4.1-
33.fc24 @updates 45 k
redhat-lsb-cxx x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-desktop x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-languages x86_64 4.1-
33.fc24 @updates 814
redhat-lsb-printing x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-submod-multimedia x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-submod-security x86_64 4.1-
33.fc24 @updates 0
spax x86_64 1.5.3-
6.fc24 @fedora 395 k
util-linux-user x86_64 2.28.2-
1.fc24 @updates 50 k
Transaction Summary
=======================================================================
=========
Remove 61 Packages
Installed size: 211 M
I am really cautious about the remove and erase commands because I have
really mucked up my system in the past..
Regards,
Les H
2:22 p.m.
On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:11:29 -0800
On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
>
>
> Since the dnf erase command doesn't work, or tries to remove over
> 211M
> of files, do you mean just to remove the directory tree for the
> offending package using the rm command?
Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a pretty
big app. What exactly is the output from 'dnf remove google-earth'?
Dependencies resolved.
=======================================================================
=========
Package Arch Version Repository
Size
=======================================================================
=========
Transaction Summary
=======================================================================
=========
Remove 61 Packages
Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:26 p.m.
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:22:31 -0800
On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora
<de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:11:29 -0800
On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
>
>
>
> Since the dnf erase command doesn't work, or tries to remove over
> 211M
> of files, do you mean just to remove the directory tree for the
> offending package using the rm command?
Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a
pretty
big app. What exactly is the output from 'dnf remove google-earth'?
Dependencies resolved.
=====================================================================
==
=========
Package Arch Version Repositor
y
Size
=====================================================================
==
=========
Transaction Summary
=====================================================================
==
=========
Remove 61 Packages
Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?
Now it gets really weird...
# rpm -q --provides google-earth
package google-earth is not installed
2:40 p.m.
-----Original Message-----
From: Josh Stone <jistone(a)redhat.com>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill(a)fedoraproject.o
rg>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800
On 12/01/2016 12:26 PM, Howard Howell wrote:
Now it gets really weird...
# rpm -q --provides google-earth
package google-earth is not installed
Should be google-earth-stable, no?
*********************
Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0
But not the one with the issue???
Regards,
Les H
2:54 p.m.
On Thursday, 01 December 2016 at 21:40, Howard Howell wrote:
-----Original Message-----
From: Josh Stone <jistone(a)redhat.com>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill(a)fedoraproject.o
rg>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800
> On 12/01/2016 12:26 PM, Howard Howell wrote:
> >
> > Now it gets really weird...
> > # rpm -q --provides google-earth
> > package google-earth is not installed
>
> Should be google-earth-stable, no?
> *********************
Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0
But not the one with the issue???
Yes, because dnf complains about issues with the updated
google-earth-stable package, not the current one.
Try `rpm -e google-earth-stable'.
Regards,
Dominik
PS. Your quoting is bad (no indentation, so it misattributes quotes)
and this is really not a topic for the developers list.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
3:09 p.m.
-----Original Message-----
From: Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net>
Reply-to: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
To: devel(a)lists.fedoraproject.org
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 21:54:13 +0100
On Thursday, 01 December 2016 at 21:40, Howard Howell wrote:
-----Original Message-----
From: Josh Stone <jistone(a)redhat.com>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora
<de
vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill@fedoraproject
.o
rg>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800
>
> On 12/01/2016 12:26 PM, Howard Howell wrote:
> >
> >
> > Now it gets really weird...
> > # rpm -q --provides google-earth
> > package google-earth is not installed
>
> Should be google-earth-stable, no?
> *********************
Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0
But not the one with the issue???
Yes, because dnf complains about issues with the updated
google-earth-stable package, not the current one.
Try `rpm -e google-earth-stable'.
Regards,
Dominik
PS. Your quoting is bad (no indentation, so it misattributes quotes)
and this is really not a topic for the developers list.
# rpm -e google-earth-stable
[root@school log]#
Well, I tried the users list, no reply. I did google, bugzilla, and
checked as many search terms as I could. Upgrades via dnf are
relatively new, and since it was not on bugzilla, I thought before I
submitted one I should have sufficient supporting information on what
exactly is the bug. A non conforming package is going to happen on the
cutting edge, so this is something that bears investigation by the
developers, I would think.
Also if investigation proves that I caused it then providing people
with information to avoid the issue would be good, wouldn't it?
However installing a non supported package should not prevent an
upgrade, should it?
Regards,
Les H
3:14 p.m.
On Thu, 2016-12-01 at 21:54 +0100, Dominik 'Rathann' Mierzejewski
wrote:
On Thursday, 01 December 2016 at 21:40, Howard Howell wrote:
>
> -----Original Message-----
> From: Josh Stone <jistone(a)redhat.com>
> To: hlhowell(a)pacbell.net, Development discussions related to Fedora
> <de
> vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill@fedoraproje
> ct.o
> rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
>
> >
> > On 12/01/2016 12:26 PM, Howard Howell wrote:
> > >
> > >
> > > Now it gets really weird...
> > > # rpm -q --provides google-earth
> > > package google-earth is not installed
> >
> > Should be google-earth-stable, no?
> > *********************
>
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0
>
> But not the one with the issue???
Yes, because dnf complains about issues with the updated
google-earth-stable package, not the current one.
Try `rpm -e google-earth-stable'.
Regards,
Dominik
PS. Your quoting is bad (no indentation, so it misattributes quotes)
and this is really not a topic for the developers list.
As you can see, I did
change the quoting preferences. I didn't notice
that it had changed. I have vision issues, and touch issues, so
occasionally I change things I do not intend to.
Thanks for bringing it to my attention.
Regards,
Les H
2:54 p.m.
On Thu, 2016-12-01 at 12:40 -0800, Howard Howell wrote:
-----Original Message-----
From: Josh Stone <jistone(a)redhat.com>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill(a)fedoraproject.o
rg>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800
On 12/01/2016 12:26 PM, Howard Howell wrote:
>
> Now it gets really weird...
> # rpm -q --provides google-earth
> package google-earth is not installed
Should be google-earth-stable, no?
*********************
Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0
But not the one with the issue???
It's a file, I just wanted to see the package provides. Can we also get:
rpm -ql google-earth-stable ?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:03 p.m.
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Josh Stone <jistone(a)redhat.com>, Development
discussions related to Fedora <devel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:54:44 -0800
On Thu, 2016-12-01 at 12:40 -0800, Howard Howell wrote:
-----Original Message-----
From: Josh Stone <jistone(a)redhat.com>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora
<de
vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill@fedoraproject
.o
rg>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800
On 12/01/2016 12:26 PM, Howard Howell wrote:
>
>
> Now it gets really weird...
> # rpm -q --provides google-earth
> package google-earth is not installed
Should be google-earth-stable, no?
*********************
Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0
But not the one with the issue???
It's a file, I just wanted to see the package provides. Can we also
get:
rpm -ql google-earth-stable ?
***************************
# rpm -ql google-earth-stable
/etc/cron.daily
/etc/cron.daily/google-earth
/opt/google/earth/free
/opt/google/earth/free/ImporterGlobalSettings.ini
/opt/google/earth/free/ImporterUISettings.ini
/opt/google/earth/free/PCOptimizations.ini
/opt/google/earth/free/drivers.ini
/opt/google/earth/free/google-earth
/opt/google/earth/free/google-earth.desktop
/opt/google/earth/free/googleearth
/opt/google/earth/free/googleearth-bin
/opt/google/earth/free/gpl.txt
/opt/google/earth/free/gpsbabel
/opt/google/earth/free/kh20
/opt/google/earth/free/lang
/opt/google/earth/free/lang/ar.qm
/opt/google/earth/free/lang/bg.qm
/opt/google/earth/free/lang/ca.qm
/opt/google/earth/free/lang/cs.qm
/opt/google/earth/free/lang/da.qm
/opt/google/earth/free/lang/de.qm
/opt/google/earth/free/lang/el.qm
/opt/google/earth/free/lang/en.qm
/opt/google/earth/free/lang/es-419.qm
/opt/google/earth/free/lang/es.qm
/opt/google/earth/free/lang/fa.qm
/opt/google/earth/free/lang/fi.qm
/opt/google/earth/free/lang/fil.qm
/opt/google/earth/free/lang/fr.qm
/opt/google/earth/free/lang/he.qm
/opt/google/earth/free/lang/hi.qm
/opt/google/earth/free/lang/hr.qm
/opt/google/earth/free/lang/hu.qm
/opt/google/earth/free/lang/id.qm
/opt/google/earth/free/lang/it.qm
/opt/google/earth/free/lang/ja.qm
/opt/google/earth/free/lang/ko.qm
/opt/google/earth/free/lang/lt.qm
/opt/google/earth/free/lang/lv.qm
/opt/google/earth/free/lang/nl.qm
/opt/google/earth/free/lang/no.qm
/opt/google/earth/free/lang/pl.qm
/opt/google/earth/free/lang/pt-PT.qm
/opt/google/earth/free/lang/pt.qm
/opt/google/earth/free/lang/ro.qm
/opt/google/earth/free/lang/ru.qm
/opt/google/earth/free/lang/sk.qm
/opt/google/earth/free/lang/sl.qm
/opt/google/earth/free/lang/sr.qm
/opt/google/earth/free/lang/sv.qm
/opt/google/earth/free/lang/th.qm
/opt/google/earth/free/lang/tr.qm
/opt/google/earth/free/lang/uk.qm
/opt/google/earth/free/lang/vi.qm
/opt/google/earth/free/lang/zh-Hans.qm
/opt/google/earth/free/lang/zh-Hant-HK.qm
/opt/google/earth/free/lang/zh-Hant.qm
/opt/google/earth/free/libIGAttrs.so
/opt/google/earth/free/libIGCore.so
/opt/google/earth/free/libIGExportCommon.so
/opt/google/earth/free/libIGGfx.so
/opt/google/earth/free/libIGMath.so
/opt/google/earth/free/libIGOpt.so
/opt/google/earth/free/libIGSg.so
/opt/google/earth/free/libIGUtils.so
/opt/google/earth/free/libLeap.so
/opt/google/earth/free/libQtCore.so.4
/opt/google/earth/free/libQtGui.so.4
/opt/google/earth/free/libQtNetwork.so.4
/opt/google/earth/free/libQtWebKit.so.4
/opt/google/earth/free/libaction.so
/opt/google/earth/free/libalchemyext.so
/opt/google/earth/free/libapiloader.so
/opt/google/earth/free/libauth.so
/opt/google/earth/free/libbase.so
/opt/google/earth/free/libbasicingest.so
/opt/google/earth/free/libcollada.so
/opt/google/earth/free/libcommon.so
/opt/google/earth/free/libcommon_gui.so
/opt/google/earth/free/libcommon_platform.so
/opt/google/earth/free/libcommon_webbrowser.so
/opt/google/earth/free/libcomponentframework.so
/opt/google/earth/free/libevll.so
/opt/google/earth/free/libexpat.so.1
/opt/google/earth/free/libfilmstrip.so
/opt/google/earth/free/libflightsim.so
/opt/google/earth/free/libfreebl3.so
/opt/google/earth/free/libfusioncommon.so
/opt/google/earth/free/libgdal.so.1
/opt/google/earth/free/libgdata.so
/opt/google/earth/free/libge_cache.so
/opt/google/earth/free/libge_chrome_net.so
/opt/google/earth/free/libge_net.so
/opt/google/earth/free/libgeobase.so
/opt/google/earth/free/libgeobaseutils.so
/opt/google/earth/free/libglobalnew.so
/opt/google/earth/free/libgoogleapi.so
/opt/google/earth/free/libgoogleearth_free.so
/opt/google/earth/free/libgooglesearch.so
/opt/google/earth/free/libgps.so
/opt/google/earth/free/libicudata.so.50
/opt/google/earth/free/libicuuc.so.50
/opt/google/earth/free/libinput_plugin.so
/opt/google/earth/free/liblayer.so
/opt/google/earth/free/liblayout.so
/opt/google/earth/free/libmaps.so
/opt/google/earth/free/libmath.so
/opt/google/earth/free/libmeasure.so
/opt/google/earth/free/libmoduleframework.so
/opt/google/earth/free/libnavigate.so
/opt/google/earth/free/libnspr4.so
/opt/google/earth/free/libnss3.so
/opt/google/earth/free/libnssckbi.so
/opt/google/earth/free/libnssdbm3.so
/opt/google/earth/free/libnsssysinit.so
/opt/google/earth/free/libnssutil3.so
/opt/google/earth/free/libplc4.so
/opt/google/earth/free/libplds4.so
/opt/google/earth/free/libport.so
/opt/google/earth/free/libprintmodule.so
/opt/google/earth/free/libprofile.so
/opt/google/earth/free/libproj.so.0
/opt/google/earth/free/librender.so
/opt/google/earth/free/libreporting.so
/opt/google/earth/free/libsearch.so
/opt/google/earth/free/libsearchmodule.so
/opt/google/earth/free/libsgutil.so
/opt/google/earth/free/libsmime3.so
/opt/google/earth/free/libsoftokn3.so
/opt/google/earth/free/libspatial.so
/opt/google/earth/free/libsqlite3.so
/opt/google/earth/free/libssl3.so
/opt/google/earth/free/libviewsync.so
/opt/google/earth/free/libwebbrowser.so
/opt/google/earth/free/libwmsbase.so
/opt/google/earth/free/libxsltransform.so
/opt/google/earth/free/plugins
/opt/google/earth/free/plugins/imageformats
/opt/google/earth/free/plugins/imageformats/libqgif.so
/opt/google/earth/free/plugins/imageformats/libqjpeg.so
/opt/google/earth/free/plugins/libnpgeinprocessplugin.so
/opt/google/earth/free/product_logo_128.png
/opt/google/earth/free/product_logo_16.png
/opt/google/earth/free/product_logo_22.png
/opt/google/earth/free/product_logo_24.png
/opt/google/earth/free/product_logo_256.png
/opt/google/earth/free/product_logo_32.png
/opt/google/earth/free/product_logo_32.xpm
/opt/google/earth/free/product_logo_48.png
/opt/google/earth/free/product_logo_64.png
/opt/google/earth/free/resources
/opt/google/earth/free/resources/application.rcc
/opt/google/earth/free/resources/balloons.rcc
/opt/google/earth/free/resources/builtin_webdata.rcc
/opt/google/earth/free/resources/cursor_crosshair_inverse.png
/opt/google/earth/free/resources/cursor_crosshair_thick.png
/opt/google/earth/free/resources/default_myplaces.rcc
/opt/google/earth/free/resources/doppler.txt
/opt/google/earth/free/resources/effects.rcc
/opt/google/earth/free/resources/filmstrip.rcc
/opt/google/earth/free/resources/flightsim
/opt/google/earth/free/resources/flightsim/aircraft
/opt/google/earth/free/resources/flightsim/aircraft/f16.acf
/opt/google/earth/free/resources/flightsim/aircraft/sr22.acf
/opt/google/earth/free/resources/flightsim/controller
/opt/google/earth/free/resources/flightsim/controller/generic.ini
/opt/google/earth/free/resources/flightsim/controller/genius_maxfighter
_f16u.ini
/opt/google/earth/free/resources/flightsim/controller/logitech_attack3.
ini
/opt/google/earth/free/resources/flightsim/controller/logitech_extreme_
3d.ini
/opt/google/earth/free/resources/flightsim/controller/logitech_force_3d
.ini
/opt/google/earth/free/resources/flightsim/controller/logitech_freedom.
ini
/opt/google/earth/free/resources/flightsim/controller/saitek_cyborg_evo
.ini
/opt/google/earth/free/resources/flightsim/controller/saitek_x52.ini
/opt/google/earth/free/resources/flightsim/controller/speed_link_black_
hawk.ini
/opt/google/earth/free/resources/flightsim/controller/speed_link_black_
widow.ini
/opt/google/earth/free/resources/flightsim/controller/speed_link_cougar
_flightstick.ini
/opt/google/earth/free/resources/flightsim/controller/speed_link_dark_t
ornado.ini
/opt/google/earth/free/resources/flightsim/controller/xbox_360.ini
/opt/google/earth/free/resources/flightsim/flightsim.ini
/opt/google/earth/free/resources/flightsim/hud
/opt/google/earth/free/resources/flightsim/hud/generic.ini
/opt/google/earth/free/resources/flightsim/hud/sr22.ini
/opt/google/earth/free/resources/flightsim/keyboard
/opt/google/earth/free/resources/flightsim/keyboard/generic.ini
/opt/google/earth/free/resources/flightsim/keyboard/sr22.ini
/opt/google/earth/free/resources/flightsim/planet
/opt/google/earth/free/resources/flightsim/planet/earth.ini
/opt/google/earth/free/resources/leftpanel-common.rcc
/opt/google/earth/free/resources/leftpanel-layer.rcc
/opt/google/earth/free/resources/localshapes.rcc
/opt/google/earth/free/resources/mouse3dgui.rcc
/opt/google/earth/free/resources/navcontrols.rcc
/opt/google/earth/free/resources/notifications.rcc
/opt/google/earth/free/resources/print.rcc
/opt/google/earth/free/resources/progress.rcc
/opt/google/earth/free/resources/renderui.rcc
/opt/google/earth/free/resources/search.rcc
/opt/google/earth/free/resources/spin_icon.png
/opt/google/earth/free/resources/startinglocations-nonmac.rcc
/opt/google/earth/free/resources/startinglocations.rcc
/opt/google/earth/free/resources/statusbar.rcc
/opt/google/earth/free/resources/terrainmgr.rcc
/opt/google/earth/free/resources/tmcontrols.rcc
/opt/google/earth/free/resources/toolbar.rcc
/opt/google/earth/free/resources/tourcontrols.rcc
/opt/google/earth/free/resources/unknown_plugin.png
/opt/google/earth/free/resources/userpalette.kml
/opt/google/earth/free/resources/webbrowser.rcc
/opt/google/earth/free/shaders
/opt/google/earth/free/shaders/atmosphere.glslesf
/opt/google/earth/free/shaders/atmosphere.glslesv
/opt/google/earth/free/shaders/atmosphere.glsllib
/opt/google/earth/free/shaders/color.h
/opt/google/earth/free/shaders/glsles.h
/opt/google/earth/free/shaders/hammer_aitoff.glslesf
/opt/google/earth/free/shaders/hammer_aitoff.glslesv
/opt/google/earth/free/shaders/lighting.h
/opt/google/earth/free/shaders/precipitation_double_cone.glslesf
/opt/google/earth/free/shaders/precipitation_double_cone.glslesv
/opt/google/earth/free/shaders/speedtree_configuration_glsles.h
/opt/google/earth/free/shaders/speedtree_utils_glsles.h
/opt/google/earth/free/shaders/stars.glslesf
/opt/google/earth/free/shaders/stars.glslesv
/opt/google/earth/free/shaders/stbillboard.arbfp1
/opt/google/earth/free/shaders/stbillboard.arbvp1
/opt/google/earth/free/shaders/stbillboard.asd
/opt/google/earth/free/shaders/stbillboard.cfg
/opt/google/earth/free/shaders/stbillboard.glslesf
/opt/google/earth/free/shaders/stbillboard.glslesv
/opt/google/earth/free/shaders/stbillboard.ps_2_0
/opt/google/earth/free/shaders/stbillboard.vs_2_0
/opt/google/earth/free/shaders/stbranch.arbfp1
/opt/google/earth/free/shaders/stbranch.arbvp1
/opt/google/earth/free/shaders/stbranch.asd
/opt/google/earth/free/shaders/stbranch.cfg
/opt/google/earth/free/shaders/stbranch.glslesf
/opt/google/earth/free/shaders/stbranch.glslesv
/opt/google/earth/free/shaders/stbranch.ps_2_0
/opt/google/earth/free/shaders/stbranch.vs_2_0
/opt/google/earth/free/shaders/stcommonobjects.ini
/opt/google/earth/free/shaders/stfrond.arbfp1
/opt/google/earth/free/shaders/stfrond.arbvp1
/opt/google/earth/free/shaders/stfrond.asd
/opt/google/earth/free/shaders/stfrond.cfg
/opt/google/earth/free/shaders/stfrond.glslesf
/opt/google/earth/free/shaders/stfrond.glslesv
/opt/google/earth/free/shaders/stfrond.ps_2_0
/opt/google/earth/free/shaders/stfrond.vs_2_0
/opt/google/earth/free/shaders/stleafcard.arbfp1
/opt/google/earth/free/shaders/stleafcard.arbvp1
/opt/google/earth/free/shaders/stleafcard.asd
/opt/google/earth/free/shaders/stleafcard.cfg
/opt/google/earth/free/shaders/stleafcard.glslesf
/opt/google/earth/free/shaders/stleafcard.glslesv
/opt/google/earth/free/shaders/stleafcard.ps_2_0
/opt/google/earth/free/shaders/stleafcard.vs_2_0
/opt/google/earth/free/shaders/stleafmesh.arbfp1
/opt/google/earth/free/shaders/stleafmesh.arbvp1
/opt/google/earth/free/shaders/stleafmesh.asd
/opt/google/earth/free/shaders/stleafmesh.cfg
/opt/google/earth/free/shaders/stleafmesh.glslesf
/opt/google/earth/free/shaders/stleafmesh.glslesv
/opt/google/earth/free/shaders/stleafmesh.ps_2_0
/opt/google/earth/free/shaders/stleafmesh.vs_2_0
/opt/google/earth/free/shaders/viewshed.h
/opt/google/earth/free/shaders/water.glsllib
/opt/google/earth/free/shaders/watersurface.glslesf
/opt/google/earth/free/shaders/watersurface.glslesv
/opt/google/earth/free/xdg-mime
/opt/google/earth/free/xdg-settings
/usr/bin/google-earth
3:21 p.m.
On 12/01/2016 12:40 PM, Howard Howell wrote:
-----Original Message-----
From: Josh Stone <jistone(a)redhat.com>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill(a)fedoraproject.o
rg>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 1 Dec 2016 12:37:04 -0800
On 12/01/2016 12:26 PM, Howard Howell wrote:
>
> Now it gets really weird...
> # rpm -q --provides google-earth
> package google-earth is not installed
Should be google-earth-stable, no?
*********************
Different results:
rpm -q --provides google-earth-stable
google-earth = 7.1.7.2606
google-earth-stable = 7.1.7.2606-0
google-earth-stable(x86-64) = 7.1.7.2606-0
There's also something weird that this is 7.1...
but your original mail quoted problems with 6.0.
3:28 p.m.
On Thu, 2016-12-01 at 13:21 -0800, Josh Stone wrote:
On 12/01/2016 12:40 PM, Howard Howell wrote:
>
> -----Original Message-----
> From: Josh Stone <jistone(a)redhat.com>
> To: hlhowell(a)pacbell.net, Development discussions related to Fedora
> <de
> vel(a)lists.fedoraproject.org>, Adam Williamson <adamwill@fedoraproje
> ct.o
> rg>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 1 Dec 2016 12:37:04 -0800
>
> On 12/01/2016 12:26 PM, Howard Howell wrote:
> >
> >
> > Now it gets really weird...
> > # rpm -q --provides google-earth
> > package google-earth is not installed
>
> Should be google-earth-stable, no?
> *********************
>
> Different results:
> rpm -q --provides google-earth-stable
> google-earth = 7.1.7.2606
> google-earth-stable = 7.1.7.2606-0
> google-earth-stable(x86-64) = 7.1.7.2606-0
There's also something weird that this is 7.1...
but your original mail quoted problems with 6.0.
New stuff, however the commands are affecting the system, when I now go
to /opt/google/earth, the directory is now empty.
and google earth is no longer in the list of applications.
regards,
Les H
2:34 p.m.
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:22:31 -0800
On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
-----Original Message-----
From: Adam Williamson <adamwill(a)fedoraproject.org>
To: hlhowell(a)pacbell.net, Development discussions related to Fedora
<de
vel(a)lists.fedoraproject.org>
Subject: Re: failure of f24 to f25 upgrade
Date: Thu, 01 Dec 2016 12:11:29 -0800
On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
>
>
>
> Since the dnf erase command doesn't work, or tries to remove over
> 211M
> of files, do you mean just to remove the directory tree for the
> offending package using the rm command?
Sorry, I missed that part. I use 'dnf remove', but I don't know if
there's any difference between that and 'dnf erase'. But when you say
'211M of files', that could just be Google Earth itself; it's a
pretty
big app. What exactly is the output from 'dnf remove google-earth'?
Dependencies resolved.
=====================================================================
==
=========
Package Arch Version Repositor
y
Size
=====================================================================
==
=========
Transaction Summary
=====================================================================
==
=========
Remove 61 Packages
Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?
sorry for the second reply... but, google earth still works. I don't
remember when exactly I installed it, or from where. I was deep into a
bit of friends code he is using on robotics, which uses the google
earth api for its mapping. I get one track minded when chasing
software, and that package is 4 or 5 languages, deep directory stuff,
lots of indirect and text parsing in the web interface, so my mind was
in a different space when it asked for google earth. I normally load
such things just using dnf install, but I seem to remember that I
couldn't find google earth with dns (probably typos or text inversion),
so I may have downloaded it from google. Speed kills!
2:35 p.m.
On 12/01/2016 12:22 PM, Adam Williamson wrote:
On Thu, 2016-12-01 at 12:15 -0800, Howard Howell wrote:
> -----Original Message-----
> From: Adam Williamson <adamwill(a)fedoraproject.org>
> To: hlhowell(a)pacbell.net, Development discussions related to Fedora <de
> vel(a)lists.fedoraproject.org>
> Subject: Re: failure of f24 to f25 upgrade
> Date: Thu, 01 Dec 2016 12:11:29 -0800
>
> On Thu, 2016-12-01 at 12:05 -0800, Howard Howell wrote:
>>
>>
>> Since the dnf erase command doesn't work, or tries to remove over
>> 211M
>> of files, do you mean just to remove the directory tree for the
>> offending package using the rm command?
>
> Sorry, I missed that part. I use 'dnf remove', but I don't know if
> there's any difference between that and 'dnf erase'. But when you say
> '211M of files', that could just be Google Earth itself; it's a pretty
> big app. What exactly is the output from 'dnf remove google-earth'?
>
> Dependencies resolved.
> =======================================================================
> =========
> Package Arch Version Repository
> Size
> =======================================================================
> =========
>
> Transaction Summary
> =======================================================================
> =========
> Remove 61 Packages
Wow, yeah. There is something weird going on there. It looks a lot like
the google-earth stuff is providing some kind of core stuff which
should usually come from a Fedora package, so that package isn't
installed. But I dunno how you got in that state in the *first* place.
What does `rpm -q --provides google-earth` show?
Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?
2:55 p.m.
On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?
Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:03 p.m.
On Thu, Dec 1, 2016 at 3:55 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
>
> Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
> So removing it is tearing the rug out from under all those others?
Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.
Perhaps it's a side effect of DNF's "clean_requirements_on_remove"
feature[1]?
Rich
[1] http://dnf.readthedocs.io/en/latest/conf_ref.html#main-options
9:31 p.m.
Rich Mattes wrote:
Perhaps it's a side effect of DNF's
"clean_requirements_on_remove"
feature[1]?
[1] http://dnf.readthedocs.io/en/latest/conf_ref.html#main-options
Yes, it's clearly that misfeature, and it's not a "side effect", it is
exactly what that "feature" is expected to do.
As you can see, it is clearly not what our users want.
Kevin Kofler
3:25 p.m.
On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:
On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?
Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.
That's a good point. What does `rpm -V filesystem` show?
3:32 p.m.
On Thu, 2016-12-01 at 21:25 +0000, John Florian wrote:
On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:
> On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
> >
> > > > > Perhaps dnf thinks google-earth is now the authority on
%{_bindir} ?
> > > > > So removing it is tearing the rug out from
under all those
others?
>
> Well, I don't think so, as I'd expect that to rip out much *more*
> > > stuff. I think it must be something a bit more odd than /usr/bin .
The
> 'filesystem' package provides /usr/bin too, and that
ought to be
> installed.
>
That's a good point. What does `rpm -V filesystem` show?
_______________________________________________
Nothing!# rpm -V filesystem
#
3:35 p.m.
On Thu, 2016-12-01 at 13:32 -0800, Howard Howell wrote:
On Thu, 2016-12-01 at 21:25 +0000, John Florian wrote:
On Thu, 2016-12-01 at 12:55 -0800, Adam Williamson wrote:
On Thu, 2016-12-01 at 12:35 -0800, Josh Stone wrote:
Perhaps dnf thinks google-earth is now the authority on %{_bindir} ?
So removing it is tearing the rug out from under all those others?
Well, I don't think so, as I'd expect that to rip out much *more*
stuff. I think it must be something a bit more odd than /usr/bin . The
'filesystem' package provides /usr/bin too, and that ought to be
installed.
That's a good point. What does `rpm -V filesystem` show?
_______________________________________________
Nothing!# rpm -V filesystem
#
I think you're in good shape then. It sounds like the `rpm -e` did what was needed
and you're now back to a more normal Fedora. I suspect your upgrade will go smoothly
now.
8:25 a.m.
Dependencies resolved.
=======================================================================
=========
Package Arch Version Repository
Size
=======================================================================
=========
Removing:
esmtp x86_64 1.2-
4.fc24 @updates 97 k
google-earth-stable x86_64 7.1.7.2606-
0 @@commandline 189 M
liblockfile x86_64 1.09-
4.fc24 @fedora 44 k
libpng12 x86_64 1.2.56-
2.fc24 @fedora 442 k
mailx x86_64 12.5-
19.fc24 @fedora 479 k
ncurses-compat-libs x86_64 6.0-
6.20160709.fc24 @updates 946 k
patch x86_64 2.7.5-
3.fc24 @fedora 231 k
perl-Algorithm-Diff noarch 1.1903-
4.fc24 @fedora 108 k
perl-Archive-Tar noarch 2.06-
2.fc24 @updates 149 k
perl-Archive-Zip noarch 1.58-
1.fc24 @updates 252 k
perl-B-Lint noarch 1.20-
6.fc24 @fedora 30 k
perl-CGI noarch 4.28-
2.fc24 @fedora 533 k
perl-CPAN noarch 2.11-
349.fc24 (a)fedora 1.7 M
perl-Class-ISA noarch 0.36-
1017.fc24 @fedora 13 k
perl-Compress-Bzip2 x86_64 2.25-
1.fc24 @updates 142 k
perl-Data-Section noarch 0.200006-
6.fc24 @fedora 40 k
perl-Devel-Size x86_64 0.80-
4.fc24 @fedora 78 k
perl-Env noarch 1.04-
347.fc24 @fedora 26 k
perl-ExtUtils-CBuilder noarch 1:0.280224-
2.fc24 @fedora 96 k
perl-ExtUtils-MM-Utils noarch 7.10-
5.fc24 (a)updates 3.1 k
perl-File-CheckTree noarch 4.42-
296.fc24 @fedora 28 k
perl-IO-Zlib noarch 1:1.10-
364.fc24 @updates 19 k
perl-IPC-Cmd noarch 1:0.96-
1.fc24 @updates 83 k
perl-IPC-System-Simple noarch 1.25-
8.fc24 @fedora 69 k
perl-Locale-Codes noarch 3.40-
1.fc24 (a)updates 2.2 M
perl-Locale-Maketext noarch 1.26-
349.fc24 @updates 166 k
perl-Locale-Maketext-Simple noarch 1:0.21-
364.fc24 @updates 14 k
perl-MRO-Compat noarch 0.12-
10.fc24 @fedora 26 k
perl-Module-Build noarch 2:0.42.18-
1.fc24 @fedora 654 k
perl-Module-CoreList noarch 1:5.20161020-
1.fc24 @updates 719 k
perl-Module-Load-Conditional noarch 0.68-
1.fc24 @updates 29 k
perl-Module-Metadata noarch 1.000027-
4.fc24 @fedora 61 k
perl-Net-Ping noarch 2.43-
364.fc24 @updates 67 k
perl-Params-Check noarch 1:0.38-
347.fc24 @fedora 28 k
perl-Perl-OSType noarch 1.009-
2.fc24 @fedora 33 k
perl-Pod-Checker noarch 4:1.71-
6.fc24 @fedora 45 k
perl-Pod-Html noarch 1.22-
364.fc24 @updates 36 k
perl-Pod-LaTeX noarch 0.61-
297.fc24 @fedora 84 k
perl-Pod-Parser noarch 1.63-
348.fc24 @fedora 263 k
perl-Pod-Plainer noarch 1.04-
2.fc24 (a)fedora 5.1 k
perl-Software-License noarch 0.103012-
1.fc24 @fedora 417 k
perl-Sys-Syslog x86_64 0.35-
1.fc24 @updates 95 k
perl-Test-Simple noarch 1.001014-
347.fc24 @fedora 448 k
perl-Text-Diff noarch 1.44-
1.fc24 @fedora 83 k
perl-Text-Glob noarch 0.09-
15.fc24 (a)fedora 7.8 k
perl-Text-Soundex x86_64 3.05-
2.fc24 @fedora 47 k
perl-Text-Template noarch 1.46-
4.fc24 @fedora 122 k
perl-autodie noarch 2.29-
2.fc24 @fedora 211 k
perl-inc-latest noarch 2:0.500-
4.fc24 @fedora 35 k
perl-local-lib noarch 2.000018-
2.fc24 @fedora 115 k
qt3 x86_64 3.3.8b-
67.fc24 @fedora 11 M
redhat-lsb x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-core x86_64 4.1-
33.fc24 @updates 45 k
redhat-lsb-cxx x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-desktop x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-languages x86_64 4.1-
33.fc24 @updates 814
redhat-lsb-printing x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-submod-multimedia x86_64 4.1-
33.fc24 @updates 0
redhat-lsb-submod-security x86_64 4.1-
33.fc24 @updates 0
spax x86_64 1.5.3-
6.fc24 @fedora 395 k
util-linux-user x86_64 2.28.2-
1.fc24 @updates 50 k
Transaction Summary
=======================================================================
=========
Remove 61 Packages
Installed size: 211 M
I am really cautious about the remove and erase commands because I have
really mucked up my system in the past..
This is just automatic dependency removal kicking in. See
"clean_requirements_on_remove" in "man dnf.conf".
If you want to keep the dependencies for any reason, or if you want to figure out if this
is really the automatic dependency removal or not, you can run:
$ sudo dnf remove google-earth-stable --setopt clean_requirements_on_remove=false
and compare the outputs.
3:32 p.m.
On Thu, 01 Dec 2016 11:32:33 -0800
Howard Howell <hlhowell(a)pacbell.net> wrote:
Hi, everyone,
I have been trying to upgrade my system from f24 to f25 using
the cli in the terminal.
814 dnf system-upgrade download --releasever=25
815 dnf system-upgrade download --releasever=25 --allowerasing
816 dnf system-upgrade download --releasever=25 --allowerasing --
nogpgcheck
all run from superuser.
error:
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/bin from install of
google-earth-stable-6.0.3.2197-0.x86_64 conflicts with file from
package filesystem-3.2-37.fc24.x86_64 # dnf --system-upgrade reboot
will not run due to same error.
This is a well known error in the spec file for the google earth file.
It tries to own /usr/bin, which it can't own, and so fails.
Here's a web reference to it.
http://forums.fedoraforum.org/showthread.php?t=302767
and here
https://ask.fedoraproject.org/en/question/85979/transaction-check-error-d...
A long time ago I installed google earth, and used a work around on the
spec file. I don't remember it now, but it worked with the rebuilt rpm
file.
The way to fix this so you can upgrade is by removing only google
earth using rpm directly, instead of through dnf.
rpm --erase --nodeps --test [google-earth-stable?]
This will test the command without doing anything. When it does what
you want, remove the --test option.
After the upgrade, you can look for ways to re-install google earth.
3:39 p.m.
On Thu, 2016-12-01 at 14:32 -0700, stan wrote:
On Thu, 01 Dec 2016 11:32:33 -0800
Howard Howell <hlhowell(a)pacbell.net> wrote:
>
> Hi, everyone,
> I have been trying to upgrade my system from f24 to f25 using
> the cli in the terminal.
>
> 814 dnf system-upgrade download --releasever=25
> 815 dnf system-upgrade download --releasever=25 --allowerasing
> 816 dnf system-upgrade download --releasever=25 --allowerasing
> --
> nogpgcheck
>
> all run from superuser.
>
> error:
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> The downloaded packages were saved in cache until the next
> successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: Transaction check error:
> file /usr/bin from install of
> google-earth-stable-6.0.3.2197-0.x86_64 conflicts with file from
> package filesystem-3.2-37.fc24.x86_64 # dnf --system-upgrade reboot
> will not run due to same error.
This is a well known error in the spec file for the google earth
file.
It tries to own /usr/bin, which it can't own, and so fails.
Here's a web reference to it.
http://forums.fedoraforum.org/showthread.php?t=302767
and here
https://ask.fedoraproject.org/en/question/85979/transaction-check-err
or-during-google-earth-install/
A long time ago I installed google earth, and used a work around on
the
spec file. I don't remember it now, but it worked with the rebuilt
rpm
file.
The way to fix this so you can upgrade is by removing only google
earth using rpm directly, instead of through dnf.
rpm --erase --nodeps --test [google-earth-stable?]
This will test the command without doing anything. When it does what
you want, remove the --test option.
After the upgrade, you can look for ways to re-install google earth.
Thanks, Rich,
Dominik, Adam, Josh and John. It appears that both
versions are now gone.
It looks like probably Dominik's suggestion of the -e cleared the
program. So somehow, rpm -e packagename seemed to be the magic bullet.
I will start overwith the update to make sure all the packages
downloaded, and let you know if success happens.
Thank you all for your support.
Regards,
Les H
4:03 p.m.
On 12/01/2016 04:39 PM, Howard Howell wrote:
It looks like probably Dominik's suggestion of the -e cleared
the
program. So somehow, rpm -e packagename seemed to be the magic bullet.
I will start overwith the update to make sure all the packages
downloaded, and let you know if success happens.
FWIW, I had several file conflicts
resulting from standard F24 packages
that blocked the upgrade to F25.
https://bugzilla.redhat.com/show_bug.cgi?id=1396848
https://bugzilla.redhat.com/show_bug.cgi?id=1396849
https://bugzilla.redhat.com/show_bug.cgi?id=1396319
that required dnf erase <offendingpackage>. Sometimes these erasures
had a slightly worrying amount of dependencies (a dozen, not hundreds,
though), and in each case they reinstalled smoothly after the OS
upgrade. Two of those have been promptly fixed by the packagers, and
apparently are no longer an isssue.
This got me thinking if there's a common root cause that could be
checked automatically? I didn't quite understand what exactly happened
in the affected packages to cause it.
4:36 p.m.
On Thu, 1 Dec 2016 17:03:30 -0500
Przemek Klosowski <przemek.klosowski(a)nist.gov> wrote:
On 12/01/2016 04:39 PM, Howard Howell wrote:
> It looks like probably Dominik's suggestion of the -e cleared the
> program. So somehow, rpm -e packagename seemed to be the magic
> bullet. I will start overwith the update to make sure all the
> packages downloaded, and let you know if success happens.
FWIW, I had several file conflicts resulting from standard F24
packages that blocked the upgrade to F25.
https://bugzilla.redhat.com/show_bug.cgi?id=1396848
https://bugzilla.redhat.com/show_bug.cgi?id=1396849
https://bugzilla.redhat.com/show_bug.cgi?id=1396319
that required dnf erase <offendingpackage>. Sometimes these
erasures had a slightly worrying amount of dependencies (a dozen, not
hundreds, though), and in each case they reinstalled smoothly after
the OS upgrade. Two of those have been promptly fixed by the
packagers, and apparently are no longer an isssue.
This got me thinking if there's a common root cause that could be
checked automatically? I didn't quite understand what exactly
happened in the affected packages to cause it.
Usually this is because of library version conflicts. The F24 package
was compiled with an earlier library, but your upgrade is going to
replace that library with a new version, and there is no F25 package
(yet) that uses the new library version. =><=
I think this is due to the freeze, as packages accumulate in updates
and updates testing during the freeze before release. That's why they
updated so smoothly after the upgrade.
There was a discussion on this list recently about this very issue, and
my take away from that discussion was that this is a consequence of the
release process itself, and would be non-trivial to fix.
4:52 p.m.
On Thu, 2016-12-01 at 17:03 -0500, Przemek Klosowski wrote:
This got me thinking if there's a common root cause that could be
checked automatically? I didn't quite understand what exactly happened
in the affected packages to cause it.
No, they're usually all different little awkward packaging corner
cases.
For instance, one common one in the F24 -> F25 upgrade involved the rpm
python subpackages. These were called rpm-python and rpm-python3 in
F24, but in F25 they were renamed to python2-rpm and python3-rpm . Of
course, the F25 packages got lines like:
Obsoletes: rpm-python < %{version}-%{release}
Provides: rpm-python = %{version}-%{release}
Obsoletes: rpm-python3 < %{version}-%{release}
Provides: rpm-python3 = %{version}-%{release}
Unfortunately, the F24 stable 'rpm' package actually got *ahead* of the
F25 stable rpm package for a while. So when you tried to run the
upgrade, the obsoletion didn't kick in - because the F24 package
*wasn't* "< %{version}-%{release}". But dnf couldn't keep the old
rpm-
python(3) package(s) around because then some other dependency chain
wasn't satisfied (I forget the details). So it simply had no way to
resolve the problem without removing everything that required rpm-
python or rpm-python3 ...
But that's just one possible case, there have been many others.
Packaging is hard. You can usually figure it out, if you dig into a
bit; it *does* help to file bugs so the issues can be solved for
others.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:43 p.m.
New subject: failure of f24 to f25 upgrade: SOLVED
On Thu, 2016-12-01 at 14:52 -0800, Adam Williamson wrote:
On Thu, 2016-12-01 at 17:03 -0500, Przemek Klosowski wrote:
> This got me thinking if there's a common root cause that could be
> checked automatically? I didn't quite understand what exactly
> happened
> in the affected packages to cause it.
No, they're usually all different little awkward packaging corner
cases.
For instance, one common one in the F24 -> F25 upgrade involved the
rpm
python subpackages. These were called rpm-python and rpm-python3 in
F24, but in F25 they were renamed to python2-rpm and python3-rpm . Of
course, the F25 packages got lines like:
Obsoletes: rpm-python < %{version}-%{release}
Provides: rpm-python = %{version}-%{release}
Obsoletes: rpm-python3 < %{version}-%{release}
Provides: rpm-python3 = %{version}-%{release}
Unfortunately, the F24 stable 'rpm' package actually got *ahead* of
the
F25 stable rpm package for a while. So when you tried to run the
upgrade, the obsoletion didn't kick in - because the F24 package
*wasn't* "< %{version}-%{release}". But dnf couldn't keep the old
rpm-
python(3) package(s) around because then some other dependency chain
wasn't satisfied (I forget the details). So it simply had no way to
resolve the problem without removing everything that required rpm-
python or rpm-python3 ...
But that's just one possible case, there have been many others.
Packaging is hard. You can usually figure it out, if you dig into a
bit; it *does* help to file bugs so the issues can be solved for
others.
The rpm -e did in fact fix the issue. The completeness solution posted
by John (I think that was who posted it) was a good idea. However as
was pointed out, the package for Google-earth still has some issues. I
need it to continue the development of the friends program, so I re-
installed it using dnf, and got the following error:
# dnf install google-earth
Last metadata expiration check: 0:46:41 ago on Thu Dec 1 15:46:43
2016.
Dependencies resolved.
=======================================================================
=========
Package Arch Version Repository
Size
=======================================================================
=========
Installing:
google-earth-stable x86_64 6.0.3.2197-0 google-
earth 30 M
Transaction Summary
=======================================================================
=========
Install 1 Package
Total download size: 30 M
Installed size: 92 M
Is this ok [y/N]: y
Downloading Packages:
google-earth-stable-6.0.3.2197-0.x86_64.rpm 356 kB/s | 30
MB 01:27
---------------------------------------------------------------------
-----------
Total 356 kB/s | 30
MB 01:27
warning: /var/cache/dnf/google-earth-17f28a61f303b7a2/packages/google-
earth-stable-6.0.3.2197-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key
ID 7fac5991: NOKEY
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Public key for google-earth-stable-6.0.3.2197-0.x86_64.rpm is
not installed
Still some work to do. Is there any thing specific you believe I
should say in the bugzilla post?
Regards,
Les H
7:05 p.m.
New subject: failure of f24 to f25 upgrade: SOLVED
I think you might be missing Google's key:
https://www.google.com/linuxrepositories/
12:16 a.m.
New subject: failure of f24 to f25 upgrade: SOLVED
On Fri, 2016-12-02 at 03:05 +0200, Alexander Ploumistos wrote:
I think you might be missing Google's key:
https://www.google.com/linuxrepositories/
Thanks, got it.
Regards,
Les H
7:23 p.m.
New subject: failure of f24 to f25 upgrade: SOLVED
On Thu, 01 Dec 2016 16:43:13 -0800
Howard Howell <hlhowell(a)pacbell.net> wrote:
warning:
/var/cache/dnf/google-earth-17f28a61f303b7a2/packages/google-
earth-stable-6.0.3.2197-0.x86_64.rpm: Header V4 DSA/SHA1 Signature,
key ID 7fac5991: NOKEY
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Public key for google-earth-stable-6.0.3.2197-0.x86_64.rpm is
not installed
Still some work to do. Is there any thing specific you believe I
should say in the bugzilla post?
You shouldn't open a bugzilla against Fedora, since Fedora doesn't
sponsor the google-earth repository. If you open a ticket at
google-earth, you should just quote the errors above in the ticket.
But you could just follow the advice that Max Pyziur wrote:
Once the upgrade completed, and everything seemed to be functioning
correctly, I then did a
dnf install <Path/And/Name/Of/google-earth-stable> package that I
downloaded from the Google Earth page.
That is, he disabled the repository and installed from a downloaded
package instead. It doesn't fix the issue of the keys, it bypasses it.
9:17 a.m.
On 12/01/2016 05:52 PM, Adam Williamson wrote:
On Thu, 2016-12-01 at 17:03 -0500, Przemek Klosowski wrote:
> >This got me thinking if there's a common root cause that could be
> >checked automatically? I didn't quite understand what exactly happened
> >in the affected packages to cause it.
No, they're usually all different little awkward packaging corner
cases.
Right, that's what I thought. Still, completely blocking the upgrade
seems rude. Yum had an option --skip-broken that would just leave such
packages alone, but DNF claims it's an incorrect approach and drops it (
http://dnf.readthedocs.io/en/latest/cli_vs_yum.html ) . They seem to
suggest that --best might help: I haven't tried it but I doubt it would
solve the problems we discussed.
Maybe we need a new option : dnf update
--skip-broken-yes-I-know-something-might-be-left-not-updated-but-I-need-to-update-this-system-and-will-mop-up-the-spills-later
9:34 p.m.
Przemek Klosowski wrote:
Right, that's what I thought. Still, completely blocking the
upgrade
seems rude. Yum had an option --skip-broken that would just leave such
packages alone,
I don't think keeping an old version of the filesystem package (because the
conflict is between google-earth-stable and the new version of filesystem)
installed instead of the current one is a good idea.
Kevin Kofler
11:05 a.m.
On 12/02/2016 10:34 PM, Kevin Kofler wrote:
Przemek Klosowski wrote:
> Right, that's what I thought. Still, completely blocking the upgrade
> seems rude. Yum had an option --skip-broken that would just leave such
> packages alone,
I don't think keeping an old version of the filesystem package (because the
conflict is between google-earth-stable and the new version of filesystem)
installed instead of the current one is a good idea.
You're right in this case,
but the three cases I encountered (see below)
were not that serious. The error messages weren't very helpful: they
just stated the conflict. I am not sure what is the best recommendation
we should give; I could think of four:
- report this problem in Bugzilla, wait until the problem is fixed in
Fedora repos and try again
- consider ignoring the conflict if appropriate (equivalent of
--skip-broken, would require changes in DNF)
- delete the offending packages and try again, and then reinstall
- downgrade the offending package (to what?) and try again
I did the delete/upgrade/reinstall, and also reported the problems; two
are apparently already fixed by packages
https://bugzilla.redhat.com/show_bug.cgi?id=1396848
https://bugzilla.redhat.com/show_bug.cgi?id=1396849
https://bugzilla.redhat.com/show_bug.cgi?id=1396319
2703
days inactive
2708
days old
36 comments
11 participants
participants (11)
-
Adam Williamson -
Alexander Ploumistos -
Dominik 'Rathann' Mierzejewski -
Howard Howell -
John Florian -
Josh Stone -
Kamil Paral -
Kevin Kofler -
Przemek Klosowski -
Rich Mattes -
stan