Updates Missing Due to Repository Naming?

I subscribe to the RSS feed for Mandriva security advisories,
but for some time (weeks, not days) I have received notice of
updates for my 2007.1/X86_64 system that MCC could not find
or retrieve from the mirrors I had selected.

If I would delete all (with urpmi.removemedia -a) and reselect
all mirrors in MCC, the updates would be retrieved and installed.
Today, for example, I had several pending RSS feed messages on
security updates, dating back a few days, but using urpmi or mcc
for the update would yield nothing. I deleted all mirrors,
added all anew, and mcc found and installed 18 packages.

Looking at the sources listed by mcc, it appears that each directory/
repository name includes a terminating number such as -4 in the
name (Official 2007.1-4), that I speculate is used to keep track of
what updates have been included in the directory (the final -n may
vary considerably from mirror to mirror), and that mcc is looking
or an exact match including the final -n and not finding it. Hence,
no updates found.

Anyone else having the same problem?

Hint, if you have not had a recent update to a bunch of gtk and
kde packages you might take a look at the following and see if you
are missing something. Some are 64-bit specific, but not all,
by any means. In all three cases (1, 4, and 5 July), I had to
delete all mirrors and re-add them before getting any updates.

Jul 1 10:34:23 lib64gdk_pixbuf2.0_0-2.10.11-2.1mdv2007.1 installed
Jul 1 10:34:32 libgdk_pixbuf2.0_0-2.10.11-2.1mdv2007.1 installed
Jul 1 10:34:36 gtk+2.0-2.10.11-2.1mdv2007.1 installed
Jul 1 10:34:47 nss-3.11.5-5.1mdv2007.1 installed
Jul 1 10:34:47 lib64amarok0-1.4.6-1mdv2007.1 installed
Jul 1 10:34:50 lib64nss3-3.11.5-5.1mdv2007.1 installed
Jul 1 10:34:52 lib64gtk+-x11-2.0_0-2.10.11-2.1mdv2007.1 installed
Jul 1 10:34:53 lib64gtk+2.0_0-2.10.11-2.1mdv2007.1 installed
Jul 1 10:34:54 libnss3-3.11.5-5.1mdv2007.1 installed
Jul 1 10:34:55 libgtk+-x11-2.0_0-2.10.11-2.1mdv2007.1 installed
Jul 1 10:35:03 amarok-1.4.6-1mdv2007.1 installed
Jul 1 10:35:07 amarok-engine-xine-1.4.6-1mdv2007.1 installed
Jul 1 10:35:08 amarok-scripts-1.4.6-1mdv2007.1 installed
Jul 1 10:35:08 lib64amarok0-scripts-1.4.6-1mdv2007.1 installed
Jul 4 10:19:52 beryl-settings-0.2.0-1.1mdv2007.1 installed
Jul 4 10:19:56 lib64openal0-0.0.8-2.1mdv2007.1 installed
Jul 5 19:50:12 lib64kdebase4-kate-3.5.6-34.1mdv2007.1 installed
Jul 5 19:50:20 kdebase-session-plugins-3.5.6-34.1mdv2007.1 installed
Jul 5 19:50:27 lib64kdebase4-3.5.6-34.1mdv2007.1 installed
Jul 5 19:50:43 kdebase-common-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:01 kdebase-progs-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:05 lib64kdebase4-kmenuedit-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:05 lib64console0-0.2.3-61.2mdv2007.1 installed
Jul 5 19:51:06 lib64kdebase4-konsole-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:07 kdebase-konsole-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:11 console-tools-0.2.3-61.2mdv2007.1 installed
Jul 5 19:51:12 kdebase-kmenuedit-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:13 kdebase-kdeprintfax-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:14 kdebase-nsplugins-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:15 kdebase-kate-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:17 kdebase-kdm-3.5.6-34.1mdv2007.1 installed
Jul 5 19:51:17 rdesktop-1.5.0-1.1mdv2007.1 installed
Jul 5 19:51:18 lib64mysql15-5.0.37-2.1mdv2007.1 installed
Jul 5 19:51:21 rpmdrake-3.69.1-1.1mdv2007.1 installed

jim beard

--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

On Thu, 05 Jul 2007 20:32:30 -0400, Jim Beard <jim.beard@verizon.net> wrote:
[color=blue]
> Looking at the sources listed by mcc, it appears that each directory/
> repository name includes a terminating number such as -4 in the
> name (Official 2007.1-4), that I speculate is used to keep track of
> what updates have been included in the directory (the final -n may
> vary considerably from mirror to mirror), and that mcc is looking
> or an exact match including the final -n and not finding it. Hence,
> no updates found.[/color]

As far as I know, the repository name is taken from /etc/urpmi/urpmi.cfg
only for finding the files in /var/lib/urpmi.

In /etc/urpmi/urpmi.cfg, each repositories url is specifed, as well as the
path to the (synthesis.)hdlist.cz file, and does not use the repository
name.
[color=blue]
> Anyone else having the same problem?[/color]

Not here, although I'm using a 32 bit system.

Try posting your /etc/urpmi/urpmi.cfg, and perhaps a problem there can
be spotted.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:[color=blue]
> Try posting your /etc/urpmi/urpmi.cfg, and perhaps a problem there can
> be spotted.[/color]

urpmi.cfg follows. In this listing, the -n appended to the 2007.1
goes one-up for Main through non-free backports (-1 through -14).
I do not remember this being the case for other mirrors. Of course,
this is the one that worked today. But earlier ones worked at the
time the mirrors were cleared and re-added, and did not work later.

[jim@jb ~]$ cat /etc/urpmi/urpmi.cfg
{
downloader: wget
verify-rpm: 1
}

update_source
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/updates/2007.1/x86_64/media/main/updates[/url]
{
hdlist
ignore
key-ids: 22458a98
media_info_dir: media_info
update
}

Main\ (Official2007.1-1)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/main/release[/url] {
key-ids: 70771ff3
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_main.cz
}

Main\ Updates\ (Official2007.1-2)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/main/updates[/url] {
key-ids: 22458a98
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_main_updates.cz
}

Main32\ (Official2007.1-3)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/i586/media/main/release[/url] {
synthesis
update
with_hdlist: ../../../../x86_64/media/media_info/synthesis.hdlist_main32.cz
}

Main32\ Updates\ (Official2007.1-4)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/i586/media/main/updates[/url] {
synthesis
update
with_hdlist:
.../../../../x86_64/media/media_info/synthesis.hdlist_main32_updates.cz
}

Main\ Testing\ (Official2007.1-5)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/main/testing[/url] {
ignore
synthesis
with_hdlist: ../../..//media/media_info/synthesis.hdlist_main_testing.cz
}

Main\ Backports\ (Official2007.1-6)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/main/backports[/url]
{
key-ids: 70771ff3
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_main_backports.cz
}

Contrib\ (Official2007.1-7)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/contrib/release[/url]
{
key-ids: 78d019f5
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_contrib.cz
}

Contrib\ Updates\ (Official2007.1-8)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/contrib/updates[/url]
{
key-ids: 26752624
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_contrib_updates.cz
}

Contrib\ Testing\ (Official2007.1-9)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/contrib/testing[/url]
{
ignore
synthesis
with_hdlist: ../../..//media/media_info/synthesis.hdlist_contrib_testing.cz
}

Contrib\ Backports\ (Official2007.1-10)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/contrib/backports[/url]
{
key-ids: 78d019f5
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_contrib_backports.cz
}

Non-free\ (Official2007.1-11)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/non-free/release[/url]
{
key-ids: 70771ff3
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_non-free.cz
}

Non-free\ Updates\ (Official2007.1-12)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/non-free/updates[/url]
{
key-ids: 70771ff3
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_non-free_updates.cz
}

Non-free\ Testing\ (Official2007.1-13)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/non-free/testing[/url]
{
ignore
synthesis
with_hdlist: ../../..//media/media_info/synthesis.hdlist_non-free_testing.cz
}

Non-free\ Backports\ (Official2007.1-14)
[url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/2007.1/x86_64/media/non-free/backports[/url]
{
synthesis
update
with_hdlist: ../../..//media/media_info/synthesis.hdlist_non-free_backports.cz
}



Cheers!

jim b.

--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

On Fri, 06 Jul 2007 00:32:30 GMT, Jim Beard wrote:[color=blue]
>
> I subscribe to the RSS feed for Mandriva security advisories,
> but for some time (weeks, not days) I have received notice of
> updates for my 2007.1/X86_64 system that MCC could not find
> or retrieve from the mirrors I had selected.
>
> If I would delete all (with urpmi.removemedia -a) and reselect
> all mirrors in MCC,[/color]

I suggest using urpmi.update to check if *hdlist.cz needs
updating before doing the urpmi --auto-select

You might use urpmi.update -a but I have found -a can hide one
of the updates failing. I opted for doing each mirror in /etc/urpmi/urpmi.cfg
and verifying that each mirror update passes before doing the
urpmi --wget --auto-select.

I do recommend using wget (--wget) instead of the default curl.
Some mirrors have a max number of connections per user limit. The curl
hanshake when fetching a package/hdlist.cz can exceed the user connect
limit causing failures. :(

Mirror maybe updating it's files causing you problems.

Bit Twister wrote:[color=blue]
> On Fri, 06 Jul 2007 00:32:30 GMT, Jim Beard wrote:[color=green]
>> I subscribe to the RSS feed for Mandriva security advisories,
>> but for some time (weeks, not days) I have received notice of
>> updates for my 2007.1/X86_64 system that MCC could not find
>> or retrieve from the mirrors I had selected.
>>
>> If I would delete all (with urpmi.removemedia -a) and reselect
>> all mirrors in MCC,[/color]
>
> I suggest using urpmi.update to check if *hdlist.cz needs
> updating before doing the urpmi --auto-select[/color]

MCC checks for updates to the *hdlist.cz before listing (or
not listing, as the case may be) the available updates. I have
had some (not all) of the *hdlist.cz downloaded, but still no
updates for my system. That could be, as the difference in the
list might be due to packages not installed on my system, but
when I do an urpmi.removemedia -a and then re-add the mirrors
in MCC, suddenly the updates are there.[color=blue]
>
> You might use urpmi.update -a but I have found -a can hide one
> of the updates failing. I opted for doing each mirror in /etc/urpmi/urpmi.cfg
> and verifying that each mirror update passes before doing the
> urpmi --wget --auto-select.[/color]

I generally use urpmi.removemedia -a because it is easy, but other
than that I usually use MCC for adding mirrors, displaying updates
available, and doing the installs. I like to see what I will be
getting before getting it. Only if I have a problem with MCC
(or think I have one) will I resort to urpmi.

It used to be easier to set mirrors using easyurpmi.zarb.org, but
the MCC for 2007.1 makes it very easy to select a full set of
mirrors with minimal effort so even selecting mirrors is done
in MCC.[color=blue]
>
> I do recommend using wget (--wget) instead of the default curl.
> Some mirrors have a max number of connections per user limit. The curl
> hanshake when fetching a package/hdlist.cz can exceed the user connect
> limit causing failures. :(
>
> Mirror maybe updating it's files causing you problems.[/color]

If it happened only once, or maybe twice, that could easily be.
But my problems have been happening for 2 or 3 weeks now, with
three times in a row in July. Additionally, I deliberately
waited 2 or 3 days a couple of times, to see if that would
allow finding the updates without changing mirror. It did
not. This strikes me as a bit much to put down to unfortunate
timing, so I posted.

Mirrors involved were Georgia Tech, SecSup or something like that
in nearby Reston Virginia (the mirror I have long used as my
primary, but that I have shied away from recently due to missing
updates -- or at least I thought they were missing), and today
ale.org.

One problem with using MCC to add mirrors is that I find sometimes
I will remove a mirror, and it will not appear in MCC's list of
mirrors to add. This precludes removing/immediately adding the
same mirror to see if that would clear the problem. Having to
move to another mirror does introduce uncertainty about the locale
of the problem.

Cheers!

jim b.


--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

On Thu, 05 Jul 2007 22:11:02 -0400, Jim Beard <jim.beard@verizon.net> wrote:
[color=blue]
> update_source
> [url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/updates/2007.1/x86_64/media/main/updates[/url]
> {
> hdlist
> ignore
> key-ids: 22458a98
> media_info_dir: media_info
> update
> }[/color]

Try removing the ignore from the update_source repository.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Fri, 06 Jul 2007 02:56:56 GMT, Jim Beard wrote:
[color=blue]
>
> MCC checks for updates to the *hdlist.cz before listing (or
> not listing, as the case may be) the available updates. I have
> had some (not all) of the *hdlist.cz downloaded, but still no
> updates for my system. That could be, as the difference in the
> list might be due to packages not installed on my system, but
> when I do an urpmi.removemedia -a and then re-add the mirrors
> in MCC, suddenly the updates are there.[/color]

Well, there is your proof that *.cz is not getting updated if you are
re-adding the same mirrors.
[color=blue]
> I generally use urpmi.removemedia -a because it is easy, but other
> than that I usually use MCC for adding mirrors, displaying updates
> available, and doing the installs. I like to see what I will be
> getting before getting it. Only if I have a problem with MCC
> (or think I have one) will I resort to urpmi.[/color]

Fine, next time RSS says there is an update,
I recommend doing your MCC fetch as normal to see what is there and
cancel the install. Then doing the
urpmi.update --wget -a
to see if your main_update mirrors are updated.
If *.cz main_update is pulled down, you know MCC is not doing
the *.cz updates. Your other mirrors may be updated because they do
not have a sum file to decide to download *.cz or not.

You can then get back into MCC to do your actual install if you like.

I have noticed, my USA mirror not getting the updates, until the next day.
Checking today, I get the mysql but not the apache updates.
[color=blue]
> It used to be easier to set mirrors using easyurpmi.zarb.org, but
> the MCC for 2007.1 makes it very easy to select a full set of
> mirrors with minimal effort so even selecting mirrors is done
> in MCC.[/color]

Agree, I used it to create my set_mirror script.

[color=blue]
> One problem with using MCC to add mirrors is that I find sometimes
> I will remove a mirror, and it will not appear in MCC's list of
> mirrors to add. This precludes removing/immediately adding the
> same mirror to see if that would clear the problem. Having to
> move to another mirror does introduce uncertainty about the locale
> of the problem.[/color]

Yep, using command line arguments I can pick the mirror set I want
dropped in.

On Thu, 05 Jul 2007 23:23:36 -0400, David W. Hodgins wrote:[color=blue]
> On Thu, 05 Jul 2007 22:11:02 -0400, Jim Beard <jim.beard@verizon.net> wrote:
>[color=green]
>> update_source
>> [url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/updates/2007.1/x86_64/media/main/updates[/url]
>> {
>> hdlist
>> ignore
>> key-ids: 22458a98
>> media_info_dir: media_info
>> update
>> }[/color]
>
> Try removing the ignore from the update_source repository.[/color]

Dang, nice catch, I knew Jim Beard was pretty smart and never bothered
to see if he had unchecked Enabled for his update mirror.

On Thu, 05 Jul 2007 23:35:20 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
[color=blue]
> Dang, nice catch, I knew Jim Beard was pretty smart and never bothered
> to see if he had unchecked Enabled for his update mirror.[/color]

I once reported a "dead" 3270, to the hardware support group, where I worked.
Because I was known, as one of the people they turned to, when they had a
sofware/hardware compatibility question, they didn't bother with the usual
questions, and just brought a new terminal to my desk. Turned out a cleaner
had unplugged it, to vacuum the area. Quite embarrasing. Lesson learned.
Always check the simple/obvious stuff first, no matter how unlikly you think
that will be the cause.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:[color=blue]
> On Thu, 05 Jul 2007 22:11:02 -0400, Jim Beard <jim.beard@verizon.net> wrote:
>[color=green]
>> update_source
>> [url]ftp://ftp.ale.org/pub/mirrors/mandrake/official/updates/2007.1/x86_64/media/main/updates[/url]
>> {
>> hdlist
>> ignore
>> key-ids: 22458a98
>> media_info_dir: media_info
>> update
>> }[/color]
>
> Try removing the ignore from the update_source repository.
>
> Regards, Dave Hodgins[/color]

But this is the one that worked!

Or did the "ignore" get automagically added after the first update
session was over?

I really do not know what was in the earlier versions that once
worked and then worked no more. I had never checked urpmi.cfg,
as I assumed (yes, I know what that means) that if it worked once,
it should keep working.

I will remove it, but for the life of me don't see how it would
account for the problem. Of course, I may just be blind on this
point.

jim b.


--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

On Sat, 07 Jul 2007 00:49:08 GMT, Jim Beard wrote:[color=blue]
> But this is the one that worked!
>
> Or did the "ignore" get automagically added after the first update
> session was over?[/color]

Hey, delete it and re-add it and check the Enable/Update boxes. :)

When you add a mirror, the *.cz files are downloaded.
If you have unchecked Enabled/Update boxes. MCC will not use those
mirror entries or update the *.cz files.

Bit Twister wrote:[color=blue]
> On Sat, 07 Jul 2007 00:49:08 GMT, Jim Beard wrote:[color=green]
>> But this is the one that worked!
>>
>> Or did the "ignore" get automagically added after the first update
>> session was over?[/color]
>
> Hey, delete it and re-add it and check the Enable/Update boxes. :)
>
> When you add a mirror, the *.cz files are downloaded.
> If you have unchecked Enabled/Update boxes. MCC will not use those
> mirror entries or update the *.cz files.[/color]

Interesting, as I know I checked to ensure that both enabled and
updates boxes were checked for everything except the testing
repositories, in MCC Media Manager. I did not look at the urpmi.cfg
file to see what was entered there, though. This evening, if I
add the ignore to the stanza, the check in the enabled box disappears.

I wonder if this was one of the things dealt with in the rpmdrake
update that installed in the last batch of updates.

Other odd features: I checked the kdebase updates against the
security notice, and one was missing. kdebase-3.5.6-34.1mdv2007.1
In point of fact, rpm -qa |grep kdebase |sort did not list it at all.
Either it was not installed, ever, or its entry somehow was missing
from the record. I unzipped every zipped file in /var/log and
grepped for it, and it was not there. It is now installed, but
how did kde work if its core package was missing? Or, how did the
entry for it fail to be recorded? Or get deleted?

Cheers!

jim b.

--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.

On Sat, 07 Jul 2007 01:55:36 GMT, Jim Beard wrote:
[color=blue]
>
> Other odd features: I checked the kdebase updates against the
> security notice, and one was missing. kdebase-3.5.6-34.1mdv2007.1
> In point of fact, rpm -qa |grep kdebase |sort did not list it at all.[/color]

Your rpm query matches mine, but checking my log I find

$ grep rpm /var/log/messages | grep install | grep kdebase | grep 3.5.6-34.1
Jul 4 19:17:55 wb perl: [RPM] libkdebase4-kate-3.5.6-34.1mdv2007.1 installed
Jul 4 19:18:07 wb perl: [RPM] kdebase-session-plugins-3.5.6-34.1mdv2007.1 installed
Jul 4 19:18:13 wb perl: [RPM] libkdebase4-3.5.6-34.1mdv2007.1 installed
Jul 4 19:18:32 wb perl: [RPM] kdebase-common-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:11 wb perl: [RPM] kdebase-progs-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:14 wb perl: [RPM] libkdebase4-konsole-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:15 wb perl: [RPM] libkdebase4-kmenuedit-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:25 wb perl: [RPM] libkdebase4-kate-devel-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:26 wb perl: [RPM] kdebase-kdm-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:27 wb perl: [RPM] kdebase-nsplugins-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:29 wb perl: [RPM] kdebase-kate-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:34 wb perl: [RPM] kdebase-kdeprintfax-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:37 wb perl: [RPM] kdebase-kmenuedit-3.5.6-34.1mdv2007.1 installed
Jul 4 19:19:38 wb perl: [RPM] kdebase-konsole-3.5.6-34.1mdv2007.1 installed

Bit Twister wrote:[color=blue]
> On Sat, 07 Jul 2007 01:55:36 GMT, Jim Beard wrote:
>[color=green]
>> Other odd features: I checked the kdebase updates against the
>> security notice, and one was missing. kdebase-3.5.6-34.1mdv2007.1
>> In point of fact, rpm -qa |grep kdebase |sort did not list it at all.[/color]
>
> Your rpm query matches mine, but checking my log I find
> $ grep rpm /var/log/messages | grep install | grep kdebase | grep 3.5.6-34.1
> Jul 4 19:17:55 wb perl: [RPM] libkdebase4-kate-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:18:07 wb perl: [RPM] kdebase-session-plugins-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:18:13 wb perl: [RPM] libkdebase4-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:18:32 wb perl: [RPM] kdebase-common-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:11 wb perl: [RPM] kdebase-progs-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:14 wb perl: [RPM] libkdebase4-konsole-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:15 wb perl: [RPM] libkdebase4-kmenuedit-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:25 wb perl: [RPM] libkdebase4-kate-devel-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:26 wb perl: [RPM] kdebase-kdm-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:27 wb perl: [RPM] kdebase-nsplugins-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:29 wb perl: [RPM] kdebase-kate-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:34 wb perl: [RPM] kdebase-kdeprintfax-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:37 wb perl: [RPM] kdebase-kmenuedit-3.5.6-34.1mdv2007.1 installed
> Jul 4 19:19:38 wb perl: [RPM] kdebase-konsole-3.5.6-34.1mdv2007.1 installed[/color]

Just as mine _was_. No kdebase-3.5.6-34.1mdv2007.1. But there is such a
package, and it was on the list of those updated to fix kdebase problems.

Cheers!

jim b.


--
UNIX is not user-unfriendly; it merely
expects users to be computer-friendly.