pkg not in sync db (problem solved)

lilsirecho · 2004-05-28 17:46:10

What does the subject statement indicate to the user attempting to download a given pkg?

Is it that the pkg is not available for download from arch ?

Is it that the users package base does not include the requested package type?

I have attempted to download the latest kdelibs pkg and received the subject reply.

sarah31 · 2004-05-29 00:06:01

it usually means that you have not synced with the archlinux package database for some time. long enough that what package info you have does not compare to what is now in the DB. note that pacman -S does not always do the trick. take a look at the pacman manpage if you want to know the proper way to sync with the so that your local DB is refreshed.

lilsirecho · 2004-05-29 01:16:00

Sarah;

Pleased to hear from someone on this subject.

Be aware that the time you refer to .."some time" is very indefinite.

I have maintained arch via -Syu daily for all of recent months, at least three.

I have received information from two others experiencing the same problem.

The package in question, at least the two I have identified, are resident in my pacman cache.

I seldom use -S for anything certainly not for upgrades!

I have had two kernel upgrades with no problem. I have cloned my HDD to another with partimage. It contains the same problem with kde.

I have installed all upgrades for ...pacman...

From what you state the DB is the pkgs in my /var/cache/pacman/pkgs. These contain the upgrade kde pkg and...the previous package as well. This indicates a problem with pacman since attempts to download the subject pkgs separately produces the error ..not in sync database...

Where in the man pacman does it define a time limit as you suggest?

If the answer is not well defined ...such as "some time"..it isn't something to hang my hat on.

Next question...since the pkg is indeed in my computer..was it really loaded into the operating system by pacman? If not, why not?

lilsirecho · 2004-05-29 01:24:14

Additionally, if I should try to upgrade again, the packages aren't abvailable.

I propose that I have to remove kde with ....Rd... and reinstall with -Sy kde...

The original question is thus avoided but the reason why it occured is not discovered...not a good thing. Pacman -Syu failed for the first time for me.

lilsirecho · 2004-05-29 02:44:00

one error message :: root@n6re root]# k3b
k3b: relocation error: /opt/kde/lib/libartskde.so.1: undefined symbol: _ZTv0_n28_N4Arts16SynthModule_stub11autoSuspendEv
[root@n6re root]#

Another error:: SIGSEGV Signal11......... at log-in........................

Pacman -Q ..... lists the latest pkg for the kde system.

The SIGSEGV message is a bug msg.!!!

lilsirecho · 2004-05-29 02:45:01

A further error message states .....Kcminit failed........

lilsirecho · 2004-05-29 02:48:22

Another error: KDEinit could not launch "kaboodle"....

That's one that rhymes with noodle!!!!

Stinky · 2004-05-29 04:04:45

roll back to the previous version of kdelibs and kdemultimedia and that will fix the kcminit error and the kaboodle error you are getting. You should be able to find those packages in
/var/cache/pacman/pkgs

lilsirecho · 2004-05-29 04:43:20

stinky;

I have been trying to address the pkgs affected in the DB /var/cache/pacman/pkg for some two hours( as well as earlier in the day).

As the title states for this post, pkgs named kdelibs-3.2.2-3.pkg.tar.gz are declared by pacman as not in the DB. However, they are listed in that location.

I have tried pacman -Rd on both of them and the same answer...not in the DB.

I think the only way it is going to work is to force the earlier versions into the computer...this is not recommended in pacman.

I maintain pacman should recognize its own DB and perform the Rd maneuver!!!!!

The error signals received suggests a bug and no way can I eliminate a bug without removing the carrier.

This ain't per pacman and it ain't kosher either.!!

Xentac · 2004-05-29 04:51:18

pacman -S takes package name only.

pacman -R takes package name only.

pacman -A takes filename.

pacman -U takes filename.

If you try to pacman -R <filename> it will look for a package with the name of <filename>. You have to pacman -R <package name>.

Get your usage straight.

lilsirecho · 2004-05-29 04:54:43

I just ran pacman -Syu and it downloaded 4 new pkgs and installed them.

Why can't it remove the packages it has in DB.

Perhaps a virus?????

lilsirecho · 2004-05-29 05:12:07

Xentac;

I am pleased to have the differences explained to me.

I am aware that Linux is an open source computer system but that some of the open source doesn't fit everywhere.

My experience with Linux in general requires that files having extensions, especially those with compression extensions, require correct handling in Linux.

I have recently encountered exactly that in partimage activities using .gz compression.

It is surprising that pacman doesn't use the Linux extensions in pacman except--they do when its downloaded and filed.

Much ado has resulted from lilo requirements to run lilo...it would seem possible that pacman instructions could be made extremely plain such that the Linux operations requiring the extension are not part of the -R parameter since such practice is nearly mandatory.

An example of what you mean by the name of the package would have completed this discussion already....where do I stop ....kdemultimedia... or kdemultimedia-3.2.2-2...or kdemultimedia-3.2.2-2.pkg....or kdemultimedia-3.2.2-3.pkg.tar???????

Please do give me an example to go by

lilsirecho · 2004-05-29 05:13:21

The example you give would fit nicely in the pacman -R description in man pacman.

lilsirecho · 2004-05-29 05:20:37

Xentac;

After reading your post, you say get your usage straight.

To get it straight you could have stated with an example just what is straight.

I feel talked down to with the result you now experience in reading this post.

Xentac · 2004-05-29 05:55:22

A package name does not include version or release.

"kdelibs" is a package name.

A package file is the full filename.

"kdelibs-3.2.2-3.pkg.tar.gz" is a filename.

These are all valid commands:

pacman -S kdelibs

pacman -R kdelibs

pacman -U kdelibs-3.2.2-3.pkg.tar.gz

pacman -A kdelibs-3.2.2-3.pkg.tar.gz

These are not valid commands:

pacman -S kdelibs-3.2.2-3.pkg.tar.gz

pacman -R kdelibs-3.2.2-3.pkg.tar.gz

pacman -U kdelibs

pacman -A kdelibs

I don't understand how this is confusing.

lilsirecho · 2004-05-29 06:24:03

Xentac,

I utilized the file name as you described it in all of my linux activities. That is the reason why it is so confusing to find the removal of a pkg differently addressed when re-installing it with a different name.

I have corrected the difficulty in one of my HDD. The other has a bug statement when trying to open juk..I will attempt to run the sequence again to correct that since it worked correctly on the other drive.

I used the command....pacman -RD kdelibs... to remove the offending pkg the -3 version

I then used command ....pacman -Af kdelibs-3.2.2-2.pkg.tar.gz to install that version.

This action corrected the problem(s) encountered with kdelibs version-3 in one drive.

I have to mention one factor which is not included in the description of how to use the various commands. The command -Af followed by one space before the filename will not be recognized..two spaces are required.

Thank you for printing the whole shebang...it will help others too!!

The real culprit here is kdelibs version-3 which needs a bug report.

Thank you for your replies and have a good night.

lilsirecho · 2004-05-29 06:55:00

I was able to restore the full operation of the system by replacing the two kde pkgs involved using the procedures you outlined.

The use of pacman -Af (package filename) required two spaces after -Af to respond.

Both packages need to be replaced with the former version to eliminate the bug.

lilsirecho · 2004-05-29 07:16:34

My last word on this subject:

To perform the install of the older version,.....pacman -Af filename .....must be run in......... /var/cache/pacman/pkg ......directory with two spaces between ...-Af .. and filename.

lilsirecho · 2004-05-29 07:19:18

My last word on this subject:

To perform the install of the older version,.....pacman -Af filename .....must be run in......... /var/cache/pacman/pkg ......directory with two spaces between ...-Af .. and filename.

Arch Linux

#1 2004-05-28 17:46:10

pkg not in sync db (problem solved)

#2 2004-05-29 00:06:01

Re: pkg not in sync db (problem solved)

#3 2004-05-29 01:16:00

Re: pkg not in sync db (problem solved)

#4 2004-05-29 01:24:14

Re: pkg not in sync db (problem solved)

#5 2004-05-29 02:44:00

Re: pkg not in sync db (problem solved)

#6 2004-05-29 02:45:01

Re: pkg not in sync db (problem solved)

#7 2004-05-29 02:48:22

Re: pkg not in sync db (problem solved)

#8 2004-05-29 04:04:45

Re: pkg not in sync db (problem solved)

#9 2004-05-29 04:43:20

Re: pkg not in sync db (problem solved)

#10 2004-05-29 04:51:18

Re: pkg not in sync db (problem solved)

#11 2004-05-29 04:54:43

Re: pkg not in sync db (problem solved)

#12 2004-05-29 05:12:07

Re: pkg not in sync db (problem solved)

#13 2004-05-29 05:13:21

Re: pkg not in sync db (problem solved)

#14 2004-05-29 05:20:37

Re: pkg not in sync db (problem solved)

#15 2004-05-29 05:55:22

Re: pkg not in sync db (problem solved)

#16 2004-05-29 06:24:03

Re: pkg not in sync db (problem solved)

#17 2004-05-29 06:55:00

Re: pkg not in sync db (problem solved)

#18 2004-05-29 07:16:34

Re: pkg not in sync db (problem solved)

#19 2004-05-29 07:19:18

Re: pkg not in sync db (problem solved)

Board footer