Hi,
I just upgraded to F13. It's nice. But look at this:
http://fedoraproject.org/wiki/PreUpgrade says
Common post-upgrade tasks ... Some packages may no longer be supported by the new release ... These can be identified with the following command: package-cleanup --orphans
So I did this:
package-cleanup --orphans
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 ...
yum remove nss-softokn-freebl
... Remove 1507 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Is this ok [y/N]: N
1507 packages is about all I have.
Is there a problem in wiki/PreUpgrade or package-cleanup or dependencies?
Cheers, Klaus
On 26/05/10 10:49, Klaus Grue wrote:
Hi,
I just upgraded to F13. It's nice. But look at this:
http://fedoraproject.org/wiki/PreUpgrade says
Common post-upgrade tasks ... Some packages may no longer be supported by the new release ... These can be identified with the following command: package-cleanup --orphans
So I did this:
package-cleanup --orphans
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 ...
have you run "yum update" on the system first?
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote:
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer
.6 > .4
Tomasz Torcz tomek@pipebreaker.pl writes:
On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote:
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer
.6 > .4
In F11 nss-softokn-freebl is a subpackage of nss, thus always updated together with it. In F12+ nss-softokn-freebl is a subpackage of nss-softokn, which stayed at 3.12.4.
Andreas.
On Wed, May 26, 2010 at 01:04:31PM +0200, Andreas Schwab wrote:
Tomasz Torcz tomek@pipebreaker.pl writes:
On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote:
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer
.6 > .4
In F11 nss-softokn-freebl is a subpackage of nss, thus always updated together with it. In F12+ nss-softokn-freebl is a subpackage of nss-softokn, which stayed at 3.12.4.
Even subpackages can have different version and/or release from the src.rpm, but the nss-softokn maintainers unfortunately haven't done that.
Jakub
On Wed, 26 May 2010, Tomasz Torcz wrote:
On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote:
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer
.6 > .4
you're absolutely right.
Try doing a yum downgrade to the nss-softokn-freebl in f13.
And then file a bug on it.
-sv
On 26 May 2010 14:06, Seth Vidal skvidal@fedoraproject.org wrote:
On Wed, 26 May 2010, Tomasz Torcz wrote:
On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote:
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer
.6 > .4
you're absolutely right.
Try doing a yum downgrade to the nss-softokn-freebl in f13.
And then file a bug on it.
I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=596840
As Seth suggested, this resolved the issue for me:
yum downgrade nss-softokn-freebl nss-softokn
I wonder if it should be added to the common problems wiki page.
J.
On 27 May 2010 16:43, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 26 May 2010 14:06, Seth Vidal skvidal@fedoraproject.org wrote:
On Wed, 26 May 2010, Tomasz Torcz wrote:
On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote:
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64
my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box.
That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer
.6 > .4
you're absolutely right.
Try doing a yum downgrade to the nss-softokn-freebl in f13.
And then file a bug on it.
I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=596840
As Seth suggested, this resolved the issue for me:
yum downgrade nss-softokn-freebl nss-softokn
I wonder if it should be added to the common problems wiki page.
Ugh. Actually I see this problem with a lot of packages where the F-12 nvr is greater than the F-13 version:
ibus-chewing: https://bugzilla.redhat.com/show_bug.cgi?id=596844
groff: https://bugzilla.redhat.com/show_bug.cgi?id=596846
libotf: https://bugzilla.redhat.com/show_bug.cgi?id=596848
java-1.6.0-openjdk: https://bugzilla.redhat.com/show_bug.cgi?id=596850
lftp: https://bugzilla.redhat.com/show_bug.cgi?id=596851
preupgrade: https://bugzilla.redhat.com/show_bug.cgi?id=596852
squashfs-tools: https://bugzilla.redhat.com/show_bug.cgi?id=596855
On Thu, 2010-05-27 at 17:27 +0100, Jonathan Underwood wrote:
On 27 May 2010 16:43, Jonathan Underwood jonathan.underwood@gmail.com wrote:
I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=596840
As Seth suggested, this resolved the issue for me:
yum downgrade nss-softokn-freebl nss-softokn
I wonder if it should be added to the common problems wiki page.
Ugh. Actually I see this problem with a lot of packages where the F-12 nvr is greater than the F-13 version:
While it's not good packaging, most of the time these bad versions don't cause any problems. If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
On Thu, 2010-05-27 at 17:27 +0100, Jonathan Underwood wrote:
On 27 May 2010 16:43, Jonathan Underwood jonathan.underwood@gmail.com wrote:
I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=596840
As Seth suggested, this resolved the issue for me:
yum downgrade nss-softokn-freebl nss-softokn
I wonder if it should be added to the common problems wiki page.
Ugh. Actually I see this problem with a lot of packages where the F-12 nvr is greater than the F-13 version:
While it's not good packaging, most of the time these bad versions don't cause any problems. If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
It does seem to cause problems with Deluge, according to a forum thread.
On Thu, 2010-05-27 at 12:37 -0700, Adam Williamson wrote:
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems. If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
It does seem to cause problems with Deluge, according to a forum thread.
Link?
On Thu, 2010-05-27 at 15:43 -0400, Matt McCutchen wrote:
On Thu, 2010-05-27 at 12:37 -0700, Adam Williamson wrote:
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems. If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
It does seem to cause problems with Deluge, according to a forum thread.
Link?
http://forums.fedoraforum.org/showthread.php?t=245655
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems.
It's better to have the packages that are supported (to the extent that the community provides support) for the distribution version being used and won't appear in "package-cleanup --orphans". AIUI, there is no correspondence between the release numbers of a package in different Fedora versions, so the higher-release F12 package may lack fixes that the lower-release F13 package has.
If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
I'm looking forward to using "distro-sync". Will PackageKit change to do "distro-sync" instead of "update"? I think it should.
On Thu, 2010-05-27 at 15:58 -0400, Matt McCutchen wrote:
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems.
It's better to have the packages that are supported (to the extent that the community provides support) for the distribution version being used and won't appear in "package-cleanup --orphans". AIUI, there is no correspondence between the release numbers of a package in different Fedora versions, so the higher-release F12 package may lack fixes that the lower-release F13 package has.
If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
I'm looking forward to using "distro-sync". Will PackageKit change to do "distro-sync" instead of "update"? I think it should.
that's going to be up to the pk maintainer(s).
but I don't think moving to distro-sync necessarily makes sense there.
distro-sync is mostly valuable for folks playing between two releases.
-sv
On Thu, 2010-05-27 at 16:07 -0400, seth vidal wrote:
On Thu, 2010-05-27 at 15:58 -0400, Matt McCutchen wrote:
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems.
It's better to have the packages that are supported (to the extent that the community provides support) for the distribution version being used and won't appear in "package-cleanup --orphans". AIUI, there is no correspondence between the release numbers of a package in different Fedora versions, so the higher-release F12 package may lack fixes that the lower-release F13 package has.
If you want to get rid of them "easily" though, feel free to install the yum from rawhide and run "distro-sync".
I'm looking forward to using "distro-sync". Will PackageKit change to do "distro-sync" instead of "update"? I think it should.
that's going to be up to the pk maintainer(s).
but I don't think moving to distro-sync necessarily makes sense there.
distro-sync is mostly valuable for folks playing between two releases.
For users who don't downgrade releases, it makes no difference most of the time. But in the cases where it does, I think "distro-sync" is the right thing to do. Do you disagree? Does it have other drawbacks? (Performance?)
On Thu, 2010-05-27 at 16:10 -0400, Matt McCutchen wrote:
distro-sync is mostly valuable for folks playing between two releases.
For users who don't downgrade releases, [...]
"Releases" there means distribution versions (i.e., collections in the Package DB). Ugh, confusing terminology. Packages have versions and releases; the distribution version appears as the version of the fedora-release package, and yum calls it the $releasever.
On Thu, 2010-05-27 at 16:16 -0400, Matt McCutchen wrote:
On Thu, 2010-05-27 at 16:10 -0400, Matt McCutchen wrote:
distro-sync is mostly valuable for folks playing between two releases.
For users who don't downgrade releases, [...]
"Releases" there means distribution versions (i.e., collections in the Package DB). Ugh, confusing terminology. Packages have versions and releases; the distribution version appears as the version of the fedora-release package, and yum calls it the $releasever.
yum calls it that b/c it is the VERSION of the DISTRIBUTION RELEASE
or specifically the VERSION from the package which provides 'redhat-release'
which includes: fedora-release, redhat-release, centos-release, etc, etc
yes, it is confusing - you can thank 8yrs of slowly evolving terminology.
I'm sorry.
-sv
On Thu, 2010-05-27 at 16:19 -0400, seth vidal wrote:
On Thu, 2010-05-27 at 16:16 -0400, Matt McCutchen wrote:
On Thu, 2010-05-27 at 16:10 -0400, Matt McCutchen wrote:
distro-sync is mostly valuable for folks playing between two releases.
For users who don't downgrade releases, [...]
"Releases" there means distribution versions (i.e., collections in the Package DB). Ugh, confusing terminology. Packages have versions and releases; the distribution version appears as the version of the fedora-release package, and yum calls it the $releasever.
yum calls it that b/c it is the VERSION of the DISTRIBUTION RELEASE
or specifically the VERSION from the package which provides 'redhat-release'
which includes: fedora-release, redhat-release, centos-release, etc, etc
I think the word "release" is being misused there. In the mirror layout, "releases" refers to the originally released content without updates, but the distribution version stays constant across updates.
In an ideal world, I would rename *-release to *-distribution and change the yum variable to $distver. But I can totally understand if that would cause more breakage (or mess by the time a backward compatibility layer is put in) than it's worth.
On Thu, 2010-05-27 at 16:32 -0400, Matt McCutchen wrote:
I think the word "release" is being misused there. In the mirror layout, "releases" refers to the originally released content without updates, but the distribution version stays constant across updates.
In an ideal world, I would rename *-release to *-distribution and change the yum variable to $distver. But I can totally understand if that would cause more breakage (or mess by the time a backward compatibility layer is put in) than it's worth.
well the concept is not hardcoded to a package of a certain name.
you can set it in your yum.conf
man yum.conf
distroverpkg The package used by yum to determine the "version" of the distribution. This can be any installed package. Default is ‘redhat-release’. You can see what provides this manually by using: "yum whatprovides redhat-release".
And if you want to go all crazy-pants with $variables in yum. - newest yums allow that:
As of 3.2.28, any file in /etc/yum/vars is turned into a variable named after the filename (or overrides any of the above variables).
Note that no warnings/errors are given if the files are unreadable, so creating files that only root can read may be confusing for users.
Also note that only the first line will be read and all new line char- acters are removed, as a convenience. However, no other checking is performed on the data. This means it is possible to have bad character data in any value.
-sv
On 27/05/10 21:07, seth vidal wrote: --snip--
that's going to be up to the pk maintainer(s).
but I don't think moving to distro-sync necessarily makes sense there.
distro-sync is mostly valuable for folks playing between two releases.
-sv
or someone with a local repo on a lan.
Frank
On 27 May 2010 20:58, Matt McCutchen matt@mattmccutchen.net wrote:
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems.
It's better to have the packages that are supported (to the extent that the community provides support) for the distribution version being used and won't appear in "package-cleanup --orphans".
Yes - this is rather important, because our user facing docs (on the wiki) for preupgrade recommend removing all packages identified with package-cleanup --orphans. A naive user could literally wipe out their system by blindly doing that. That's my main concern - we should not be leaving landmines for users.
On Thu, 2010-05-27 at 21:35 +0100, Jonathan Underwood wrote:
On 27 May 2010 20:58, Matt McCutchen matt@mattmccutchen.net wrote:
On Thu, 2010-05-27 at 15:03 -0400, James Antill wrote:
While it's not good packaging, most of the time these bad versions don't cause any problems.
It's better to have the packages that are supported (to the extent that the community provides support) for the distribution version being used and won't appear in "package-cleanup --orphans".
Yes - this is rather important, because our user facing docs (on the wiki) for preupgrade recommend removing all packages identified with package-cleanup --orphans. A naive user could literally wipe out their system by blindly doing that. That's my main concern - we should not be leaving landmines for users.
Sure, though I would hope the user would stop a removal of 1500 packages and complain on the list like Klaus did.
Another solution is to move away from incremental maintenance of the set of installed packages and instead solve the dependencies from scratch on each yum run, starting with a list of "wanted" packages maintained by the sysadmin. This would take some discipline to get right, but it has the major benefit that systems can no longer get stuck in an unusual or "wrong" state. I believe aptitude remembers which of the installed packages were "wanted" and then automatically removes unwanted leaves, but the general approach is still incremental rather than from-scratch.
On Thu, 2010-05-27 at 16:53 -0400, Matt McCutchen wrote:
Sure, though I would hope the user would stop a removal of 1500 packages and complain on the list like Klaus did.
Another solution is to move away from incremental maintenance of the set of installed packages and instead solve the dependencies from scratch on each yum run, starting with a list of "wanted" packages maintained by the sysadmin. This would take some discipline to get right, but it has the major benefit that systems can no longer get stuck in an unusual or "wrong" state. I believe aptitude remembers which of the installed packages were "wanted" and then automatically removes unwanted leaves, but the general approach is still incremental rather than from-scratch.
And yum is working in that direction - we're recording things people ask for as opposed to things pulled in by dep so we can eventually take action based on the difference.
take a look at the output from yumdb sometime.
-sv
On Thu, May 27, 2010 at 09:35:18PM +0100, Jonathan Underwood wrote:
Yes - this is rather important, because our user facing docs (on the wiki) for preupgrade recommend removing all packages identified with package-cleanup --orphans. A naive user could literally wipe out their system by blindly doing that. That's my main concern - we should not be leaving landmines for users.
Oooh, ooh! (*Raises hand, jumps in chair*.) yum-protect-packages plugin!
On 05/28/2010 05:11 AM, Matthew Miller wrote:
On Thu, May 27, 2010 at 09:35:18PM +0100, Jonathan Underwood wrote:
Yes - this is rather important, because our user facing docs (on the wiki) for preupgrade recommend removing all packages identified with package-cleanup --orphans. A naive user could literally wipe out their system by blindly doing that. That's my main concern - we should not be leaving landmines for users.
Oooh, ooh! (*Raises hand, jumps in chair*.) yum-protect-packages plugin!
That functionality is merged into yum in Rawhide.
Rahul
On Fri, May 28, 2010 at 05:13:09AM +0530, Rahul Sundaram wrote:
That functionality is merged into yum in Rawhide.
Well, I *knew* it was a good idea. :)
On Thu, 2010-05-27 at 19:41 -0400, Matthew Miller wrote:
On Thu, May 27, 2010 at 09:35:18PM +0100, Jonathan Underwood wrote:
Yes - this is rather important, because our user facing docs (on the wiki) for preupgrade recommend removing all packages identified with package-cleanup --orphans. A naive user could literally wipe out their system by blindly doing that. That's my main concern - we should not be leaving landmines for users.
Oooh, ooh! (*Raises hand, jumps in chair*.) yum-protect-packages plugin!
protect packages is no-more!
we've merged the functionality into core yum to keep people from shooting themselves in the foot
-sv
On 05/28/2010 05:23 AM, seth vidal wrote:
protect packages is no-more!
we've merged the functionality into core yum to keep people from shooting themselves in the foot
There is something misleading about what it does. yum remove yum in Rawhide tells
"Error: Trying to remove "yum" which is protected You could try using --skip-broken to work around the problem You could try running : rpm -Va --nofiles --nodigest"
Neither suggestions are applicable here. The protect packages plugin suggested using a override switch if the user is sure and that seems more appropriate.
Rahul
On Fri, May 28, 2010 at 05:30:03AM +0530, Rahul Sundaram wrote:
"Error: Trying to remove "yum" which is protected You could try using --skip-broken to work around the problem You could try running : rpm -Va --nofiles --nodigest" Neither suggestions are applicable here. The protect packages plugin suggested using a override switch if the user is sure and that seems more appropriate.
I strongly believe that the switch should be "--shoot-myself-in-the-foot".
On Fri, 2010-05-28 at 05:30 +0530, Rahul Sundaram wrote:
On 05/28/2010 05:23 AM, seth vidal wrote:
protect packages is no-more!
we've merged the functionality into core yum to keep people from shooting themselves in the foot
There is something misleading about what it does. yum remove yum in Rawhide tells
"Error: Trying to remove "yum" which is protected You could try using --skip-broken to work around the problem You could try running : rpm -Va --nofiles --nodigest"
Neither suggestions are applicable here. The protect packages plugin suggested using a override switch if the user is sure and that seems more appropriate.
file it and we'll get it changed to be a more helpful msg.
-sv
On 05/28/2010 07:54 PM, seth vidal wrote:
file it and we'll get it changed to be a more helpful msg.
https://bugzilla.redhat.com/show_bug.cgi?id=597336
Rahul
On Thu, May 27, 2010 at 07:53:26PM -0400, seth vidal wrote:
Oooh, ooh! (*Raises hand, jumps in chair*.) yum-protect-packages plugin!
protect packages is no-more! we've merged the functionality into core yum to keep people from shooting themselves in the foot
I saw! It's always nice to see crazy ideas made official. :)
On Wed, 26 May 2010, Klaus Grue wrote:
Hi,
I just upgraded to F13. It's nice. But look at this:
http://fedoraproject.org/wiki/PreUpgrade says
Common post-upgrade tasks ... Some packages may no longer be supported by the new release ... These can be identified with the following command: package-cleanup --orphans
So I did this:
package-cleanup --orphans
... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 ...
yum remove nss-softokn-freebl
... Remove 1507 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) Is this ok [y/N]: N
1507 packages is about all I have.
Is there a problem in wiki/PreUpgrade or package-cleanup or dependencies?
a package orphan is any pkg you have installed which no longer appears in any repo you have.
If you had upgraded to the new repos for f13 but not upgraded all pkgs then nss-softokn-freebl might have been an orphan but also required.
if you try to update it, do you get anything?
-sv
devel@lists.stg.fedoraproject.org