4:49 a.m.
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
4:58 a.m.
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.
5:20 a.m.
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 RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg(a)chrome.pl Your routes will be aggreggated. -- Alex Yuriev
6:04 a.m.
Tomasz Torcz <tomek(a)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.
--
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
6:32 a.m.
On Wed, May 26, 2010 at 01:04:31PM +0200, Andreas Schwab wrote:
Tomasz Torcz <tomek(a)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
8:06 a.m.
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
10:43 a.m.
On 26 May 2010 14:06, Seth Vidal <skvidal(a)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.
11:27 a.m.
On 27 May 2010 16:43, Jonathan Underwood <jonathan.underwood(a)gmail.com> wrote:
On 26 May 2010 14:06, Seth Vidal <skvidal(a)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
2:03 p.m.
On Thu, 2010-05-27 at 17:27 +0100, Jonathan Underwood wrote:
On 27 May 2010 16:43, Jonathan Underwood
<jonathan.underwood(a)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".
2:37 p.m.
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(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:43 p.m.
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?
--
Matt
3:07 p.m.
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
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:58 p.m.
New subject: nvr issues, yum distro-sync
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.
--
Matt
3:07 p.m.
New subject: nvr issues, yum distro-sync
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
3:10 p.m.
New subject: nvr issues, yum distro-sync
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?)
--
Matt
3:16 p.m.
New subject: nvr issues, yum distro-sync
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.
--
Matt
3:19 p.m.
New subject: nvr issues, yum distro-sync
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
3:32 p.m.
New subject: nvr issues, yum distro-sync
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.
--
Matt
3:39 p.m.
New subject: nvr issues, yum distro-sync
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
2:39 a.m.
New subject: nvr issues, yum distro-sync
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
3:35 p.m.
New subject: nvr issues, yum distro-sync
On 27 May 2010 20:58, Matt McCutchen <matt(a)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.
3:53 p.m.
New subject: nvr issues, yum distro-sync
On Thu, 2010-05-27 at 21:35 +0100, Jonathan Underwood wrote:
On 27 May 2010 20:58, Matt McCutchen <matt(a)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.
--
Matt
4:35 p.m.
New subject: nvr issues, yum distro-sync
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
6:41 p.m.
New subject: nvr issues, yum distro-sync
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!
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
6:43 p.m.
New subject: nvr issues, yum distro-sync
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
6:44 p.m.
New subject: nvr issues, yum distro-sync
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. :)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
6:53 p.m.
New subject: nvr issues, yum distro-sync
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
7 p.m.
New subject: nvr issues, yum distro-sync
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
7:07 p.m.
New subject: nvr issues, yum distro-sync
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".
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
9:24 a.m.
New subject: nvr issues, yum distro-sync
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
12:08 p.m.
New subject: nvr issues, yum distro-sync
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
7:04 p.m.
New subject: nvr issues, yum distro-sync
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. :)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:05 a.m.
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
5118
days inactive
5120
days old
32 comments
12 participants
participants (12)
-
Adam Williamson -
Andreas Schwab -
Frank Murphy -
Jakub Jelinek -
James Antill -
Jonathan Underwood -
Klaus Grue -
Matt McCutchen -
Matthew Miller -
Rahul Sundaram -
Seth Vidal -
Tomasz Torcz